C++ Language Mapping Avatar
  1. OMG Specification

C++ Language Mapping — Open Issues

  • Acronym: CPP
  • Issues Count: 15
  • 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

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