C++ Language Mapping Avatar
  1. OMG Specification

C++ Language Mapping — Open Issues

  • Acronym: CPP
  • Issues Count: 23
  • Description: Issues not resolved
Open Closed All
Issues not resolved

Issues Descriptions

Practical problem with DII using Request Pseudo Object

  • Key: CPP13-81
  • Legacy Issue Number: 141
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: If I want to use the DII to send out multiple simultaneous requests, I don"t see a practical way to associate any client specific context that is C++ compliant to those requests.

  • Reported: CPP 1.0b1 — Tue, 1 Oct 1996 04:00 GMT
  • Updated: Wed, 11 Mar 2015 04:15 GMT

Value Box Mapping

  • Key: CPP13-12
  • Legacy Issue Number: 2285
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: This may be a naive question, but it seems like the C++ mapping
    for value boxes is incomplete. As far as I can tell, the specification
    defines the mapping for the following types:

    basic types, enum, objref, string, wstring, struct, union, sequence, array, fixed, any

    But what about the types that have not been mentioned?

    value, value box, TypeCode, Principal, native, except

    If these types aren"t allowed, does the specification say that somewhere?

  • Reported: CPP 1.0b1 — Wed, 23 Dec 1998 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

portable includes

  • Key: CPP13-11
  • Legacy Issue Number: 2253
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: We all know that the names of the C++ #include files generated from IDL are
    not standardized, and are thus the one remaining major source portability
    issue. One way to fix this would be to agree on some standard filenames,
    but we"ve tried this before and have never succeeded.

    Just thinking out loud here, but another way to fix it would be to agree on
    some standard macro names that applications could use to portably include
    the appropriate files. For example, define one macro for a client-side
    include and one macro for a server-side include, both taking the basename
    of the IDL file as an argument:

    #ifndef CORBA_CXX_CLIENT_INCLUDE
    #define CORBA_CXX_CLIENT_INCLUDE(base) <base ## Client.hh>
    #endif

    #ifndef CORBA_CXX_SERVER_INCLUDE
    #define CORBA_CXX_SERVER_INCLUDE(base) <base ## Server.hh>
    #endif

    Obviously, the exact definition of the macro would depend on the names of
    the generated files.

    I believe these could then be used portably in the client and server source
    code like this:

    #include CORBA_CXX_CLIENT_INCLUDE(file)

    With this approach, nobody has to change the names of the files they
    currently generate.

  • Reported: CPP 1.0b1 — Mon, 14 Dec 1998 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Setting the TypeCode of an Any without setting a value

  • Key: CPP13-16
  • Legacy Issue Number: 2614
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Consider the following IDL:

    ----------------------------------------------------------------------
    // IDL
    typedef long MyArray[1000000];

    interface I

    { void set_array(in MyArray array); }

    ;
    ----------------------------------------------------------------------

    Now let"s assume that I want to implement this using the DSI:

    ----------------------------------------------------------------------
    // C++
    void
    I_impl::invoke(ServerRequest_ptr request) throw()
    {
    String_var name = request -> op_name();

    if(strcmp(name, "set_array") == 0)

    { NVList_ptr list; orb -> create_list(0, list); Any* any = list -> add(ARG_IN) -> value(); XXX request -> params(list); MyArray_forany arg; *any >>= arg; ... // Do something with arg; return; }

    else

    { NVList_ptr list; orb -> create_list(0, list); request -> params(list); Any* any = new Any; *any <<= new BAD_OPERATION(); request -> exception(any); }

    }
    ----------------------------------------------------------------------

    At the line I marked with XXX, I have to set the TypeCode of the
    Any.

  • Reported: CPP 1.0 — Tue, 20 Apr 1999 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Value boxes and sensible value issue

  • Key: CPP13-15
  • Legacy Issue Number: 2497
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Value Boxes inherit from CORBA::ValueBase and
    must therefore implement get_value_def(), but
    cannot return a sensible value.

  • Reported: CPP 1.0b1 — Mon, 1 Mar 1999 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

C++ _var type widening proposal

  • Key: CPP13-3
  • Legacy Issue Number: 1418
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Michi Henning & Steve Vinoski have previously challenged people to come
    up with a modification to the C++ language mapping that would allow for
    type safe widening of object reference _var types for assignment or copy
    construction. I believe I have come up with the solution, and Michi
    agrees with me:

    Proposal:

    For object reference _var types, replace the copy and assignment
    operators:

    class T_var

    { public: ... T_var(const T_var &); T_var &operator = (const T_var &); ... }

    ;

    with:

    class T_var {
    public:
    ...
    template <class C_var>
    T_var(const C_var &cv) : ptr_(T::_duplicate(cv.in()) {
    }

    template <class C_var>
    T_var &operator = (const C_var &cv) {
    if ((void *)this != (void *)cv)

    { CORBA::release(ptr_); ptr_ = T::_duplicate(cv.in()); }

    return *this;
    }
    ...
    private:
    T_ptr ptr_;
    };

  • Reported: CPP 1.0b1 — Tue, 2 Jun 1998 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

include files

  • Key: CPP13-2
  • Legacy Issue Number: 647
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: There seems to be nothing in the spec that specifies the name of the include files for things in the CORBA module (e.g. type definitions). Add such a requirement to each language mapping

  • Reported: CPP 1.0b1 — Fri, 1 Aug 1997 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Is public _ptr member mandatory?

  • Key: CPP13-10
  • Legacy Issue Number: 2222
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: In a number of places in the sample code for the C++ binding, the symbol
    _ptr is used as a member variable in _var types. In all of these the
    actual member is shown as private, so it is clear that actual
    implementations could use something else.

    The one exception to this is in section 20.10 on the Mapping for Struct
    Types. This discusses (without sample code) the mapping for string and
    object reference members of structs.

  • Reported: CPP 1.0b1 — Thu, 19 Nov 1998 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Need more info for custom marshalled value in C++

  • Key: CPP13-9
  • Legacy Issue Number: 2207
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The current C++ chapter for custom marshalled values on p. 20-94 lacks
    information about how one implements a custom value.
    The "Value Type Semantics" chapter in "ptc/98-10-06, 15 Oct. 98[REVIEW]"
    p. 5-11 says,
    " The implementer of a custom value type shall provide an
    implementation of the CustomMarshaller operations. The manner
    in which this [sic] done shall be specified for each language mapping..."

  • Reported: CPP 1.0b1 — Thu, 12 Nov 1998 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Generic extraction of Fixed

  • Key: CPP13-8
  • Legacy Issue Number: 1984
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary:
    The C++ mapping does not permit extraction of a Fixed from an Any
    in a generic way – I must always specify matching digits and scale in
    order to call Any::to_fixed(). This is inconvenient if an application
    wants to deal with Fixed values generically (because Fixed is a generic
    type in C++ anyway).

    Proposal:

    Add an overloaded >>= operator for extraction of Fixed from an Any.
    The operator sets the Fixed value to whatever scale and digits
    are present in the type code.

    Cheers,

    Michi.

  • Reported: CPP 1.0b1 — Tue, 22 Sep 1998 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Extraction of Fixed from Any

  • Key: CPP13-7
  • Legacy Issue Number: 1983
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The mapping right now offers Any::to_fixed to get a Fixed value out of an Any:

    to_fixed(Fixed &f, UShort d, UShort s);

    The spec doesn"t state what should happen if the digits and scale do
    not match what is in the type code. I believe extraction should fail in
    this case.

  • Reported: CPP 1.0b1 — Tue, 22 Sep 1998 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

struct containing Fixed type

  • Key: CPP13-5
  • Legacy Issue Number: 1799
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Section 20.9, page 20-28 of orbos/98-07-12 describes what types are
    considered variable-length. Since the new Fixed class has non-trivial
    constructors, it should also be a considered a variable-length type. Note
    that any fixed-length struct containing one cannot be statically initialized.

  • Reported: CPP 1.0b1 — Tue, 11 Aug 1998 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section 7.3.6: PortableServer::ValueRefCountBase

  • Key: CPP13-4
  • Legacy Issue Number: 1659
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: There is no mention of PortableServer::ValueRefCountBase after this
    page. It is not clear why values that also implement interfaces
    do not use the same reference counting scheme as other values.

  • Reported: CPP 1.0b1 — Thu, 9 Jul 1998 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Valuetypes as operation arguments

  • Key: CPP13-13
  • Legacy Issue Number: 2306
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The C++ mapping document (98-09-03, p. 108) states that "... the callee
    shall receive a copy of each valuetype argument passed to it even if the
    caller and callee are collocated in the same process."

    In the collocated case, should the ORB invoke _copy_value() to produce
    the copy?

    Since the user could implement _copy_value() to return a nil value, it
    seems unlikely that the ORB could rely on this mechanism. However, a
    properly implemented _copy_value() would likely provide a significant
    speed improvement over marshalling and unmarshalling.

  • Reported: CPP 1.0b1 — Mon, 18 Jan 1999 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Memory management of recursive value

  • Key: CPP13-14
  • Legacy Issue Number: 2309
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Section 20.21, "Argument Passing Considerations," says that for valuetypes:
    "The caller shall eventually invoked _remove_ref on the valuetype
    instance it receives back as either an inout, out, or return value."

    For memory management purposes, this is not sufficient in some cases.

  • Reported: CPP 1.0b1 — Wed, 20 Jan 1999 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Extraction of strings from an Any

  • Key: CPP13-6
  • Legacy Issue Number: 1971
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: What happens if I write

    CORBA::Any a = ...;
    const char *p;

    a >>= p;

    and the type code in the Any indicates a bounded string? Does the extraction
    succeed or fail? The mapping doesn"t say.

  • Reported: CPP 1.0b1 — Thu, 17 Sep 1998 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Exceptions in servant constructors

  • Key: CPP13-22
  • Legacy Issue Number: 3150
  • Status: open  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    I think we have a defect/omission in the C++ mapping with respect
    to exception safety. Consider a servant class with a constructor:

    class FooImpl : public virtual POA_Foo

    { public: FooImpl(); // ... }

    ;

    Consider what happens if FooImpl() throws an exception for some reason.
    By the time FooImpl() runs, the base class constructor POA_Foo() has run
    already. So, when the compiler deals with the exception, it invokes
    ~POA_Foo().

    The problem arises because, in our implementation at least, ~POA_Foo()
    checks if the reference count is zero and asserts if not.

  • Reported: CPP 1.0 — Mon, 20 Dec 1999 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Abstract interface and DSI issue with C++

  • Key: CPP13-21
  • Legacy Issue Number: 3111
  • Status: open  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    There doens't appear to be any portable way to implement an object that
    inherits from an abstract interface using the DSI in C++ without compile
    time knowledge of the abstract interface. The basic problem is that I
    can create an object reference from a POA, but there is no way to
    convert the reference into an abstract interface reference so that I can
    send it out on the wire.

    We need some mechanism to coerce an object reference into an abstract
    interface reference (with a runtime check) to make this work.

  • Reported: CPP 1.0 — Fri, 10 Dec 1999 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

_default_POA

  • Key: CPP13-19
  • Legacy Issue Number: 3055
  • Status: open  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    what should _default_POA() return if no default ORB exists in the server
    (that is, ORB_init() with an empty ORB ID was never called)?

  • Reported: CPP 1.0 — Tue, 23 Nov 1999 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

ValueBase::_copy_value clarification

  • Key: CPP13-18
  • Legacy Issue Number: 2875
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The ValueBase::_copy_value() function is included in the discussion
    of the "reference counting interface" in section 1.17.5 of 99-07-41.
    Later, the description of the reference counting mix-in classes
    says:

    "Each of these classes shall be fully concrete and shall completely
    fulfill the ValueBase reference counting interface..."

    However, I do not believe that the intent was to require the mix-in
    classes to implement _copy_value().

    Therefore I suggest one of two clarifications:

    1) Move the discussion of _copy_value() out of the reference-counting
    section, or

    2) Specify which functions the mix-in classes are actually expected to
    implement, e.g.,

    "Each of these classes shall be fully concrete and shall completely
    fulfill the ValueBase reference counting interface (_add_ref,
    _remove_ref, and _refcount_value), ..."

  • Reported: CPP 1.0 — Thu, 9 Sep 1999 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Problem with AbstractBase definition

  • Key: CPP13-20
  • Legacy Issue Number: 3074
  • Status: open  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    In the CORBA 2.3 spec, section 6.2, CORBA::AbstractBase is defined as:

    module CORBA

    { native AbstractBase; }

    ;

    This implies that the C++ mapping for AbstractBase when used as a
    parameter is like this:

    class DataOutputStream

    { // from CORBA 2.3, section 5.5.2 void write_Abstract(AbstractBase value); }

    ;

    But section 1.18.1 of the CORBA 2.3 C++ mapping makes it clear that the
    signature should be:

    class DataOutputStream

    { // void write_Abstract(AbstractBase_ptr value); }

    ;

    Now I know that DataInputStream & DataOutputStream can be special cased
    to handle this, but if we need to add additional operations that use
    AbstractBase in the future, it would be nice if this could be fixed to
    behave consistently with the other native type mappings to C++.

  • Reported: CPP 1.0 — Thu, 2 Dec 1999 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

IDL that is not IDL!

  • Key: CPP13-17
  • Legacy Issue Number: 2640
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The C++ language mapping chapter contains many blocks of IDL like stuff
    with the comment

    // IDL

    in the first line, but the stuff in the block is not valid IDL for
    various reasons:

    Uses "pseudo" as an apparent keyword.

    (ii) Contains declarations like

    attribute exception exception;

    I suggest that the comment "// IDL" be replaced by "// Augmented IDL
    (see "Usage" on page x-y)" cross-referencing to section 20.23 Usage, so
    that people know for sure that this is not IDL.

    Furthermore, to make the claim in section 20.23 true, the declaration:

    attribute exception exception;

    should be fixed to be something else, or alternatively, the exceptional
    use of exception should be called out as a specific augmentation of IDL
    in section 20.23.

  • Reported: CPP 1.0 — Thu, 6 May 1999 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

_out types and nested calls

  • Key: CPP13-23
  • Legacy Issue Number: 3161
  • Status: open  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    consider:

    // IDL

    struct VariableStruct

    { ... }

    ;

    interface I

    { void foo(out VariableStruct s); void bar(out VariableStruct s); }

    ;

    Then:

    // C++
    void
    MyImplForI::foo(VariableStruct_out s)

    { bar(s); bar(s); // Leak here }

    void
    MyImplForI::bar(VariableStruct_out s)

    { s = new VariableStruct; }

    The freeing of memory for out params relies on the default conversion
    by the _out constructor from a pointer to the _out type which, as a
    side effect, frees the memory return by the previous call. However,
    in this case, and _out param is passed to another call, so the
    assignment operator runs, not the constructor:

    T_out& operator=(T* p)

    { ptr_ = p; return *this; }

    The assignment operator doesn't free the previous memory, so we get
    the leak.

    Should the assignment operator be changed?

  • Reported: CPP 1.0 — Wed, 22 Dec 1999 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT