C++ Language Mapping Avatar
  1. OMG Specification

C++ Language Mapping — Open Issues

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

Issues Summary

Key Issue Reported Fixed Disposition Status
CPP13-1 1.16.3 Extraction from any CPP 1.1 open
CPP13-67 Section: 13.6 Server mapping CPP 1.1 open
CPP13-66 Concrete ValueType _init class problem CPP 1.1 open
CPP13-62 conversion algorithm not specified CPP 1.1 open
CPP13-58 Fixed and truncation/rounding? CPP 1.1 open
CPP13-57 ServantBase needs _get_domain_managers()? CPP 1.1 open
CPP13-64 No portable way to create a OUT argument for a DII request CPP 1.1 open
CPP13-61 Prohibit extracting from any into _out type? CPP 1.1 open
CPP13-60 Add set of typedefs that would facilitate template programming CPP 1.1 open
CPP13-59 UTF-8 and IDL character types in C++ CPP 1.1 open
CPP13-53 Optional parameters for _create_request? CPP 1.1 open
CPP13-52 ORB::destroy() missing CPP 1.1 open
CPP13-54 Passing two context lists to _create_request() CPP 1.1 open
CPP13-50 CORBA::RequestSeq or CORBA::ORB::RequestSeq? CPP 1.1 open
CPP13-49 _default_POA if no default ORB? CPP 1.1 open
CPP13-51 questions to IDL - C++ mapping ( CORBA 2.3, valuebox) CPP 1.1 open
CPP13-56 Inserters/extractors for boxed strings? CPP 1.1 open
CPP13-55 publication of messaging / unchecked_narrow CPP 1.1 open
CPP13-43 Supporting typedefs for _var types? CPP 1.1 open
CPP13-42 Variable-length out params and exceptions CPP 1.1 open
CPP13-41 Read-only parameter remnants CPP 1.1 open
CPP13-40 Sequence mapping & custom marshalling CPP 1.1 open
CPP13-35 set_servant and null servant CPP 1.1 open
CPP13-34 ref counting ambiguous? CPP 1.1 open
CPP13-30 Object Reference insertion/extration to Any CPP 1.1 open
CPP13-39 DSI and implicit activation CPP 1.1 open
CPP13-38 void * operations on Any? CPP 1.1 open
CPP13-32 Valuetype "copying" semantics underspecified? (C++ issue # 1) CPP 1.1 open
CPP13-31 ValueBase::_copy_value() function is underspecified CPP 1.1 open
CPP13-33 Valuetype "copying" semantics underspecified? (C++ Issue # 2) CPP 1.1 open
CPP13-36 Issue with valuetypes & inout/out parameters CPP 1.1 open
CPP13-37 Constructor for structures? CPP 1.1 open
CPP13-45 unclear semantics for valuetype insertion into Any CPP 1.1 open
CPP13-44 Any insertion for Boolean/Octet/Char CPP 1.1 open
CPP13-47 CORBA::Environment for EH compilers CPP 1.1 open
CPP13-46 unspecified criterion for Any extraction CPP 1.1 open
CPP13-48 CORBA::release and CORBA::is_nil on POA_ptr CPP 1.1 open
CPP13-29 fixed-length _var assignment from pointer CPP 1.1 open
CPP13-28 UnknownUserException and stubs CPP 1.1 open
CPP13-27 Construction of _var types CPP 1.1 open
CPP13-26 C++ spec: Valuebase missing get_value_def CPP 1.1 open
CPP13-25 C++ ValueBox & Fixed question CPP 1.1 open
CPP13-24 Any and UnknownUserException CPP 1.1 open

Issues Descriptions

1.16.3 Extraction from any

  • Key: CPP13-1
  • Legacy Issue Number: 5854
  • Status: open  
  • Source: Connox ( Raf Schietekat)
  • Summary:

    The question is about 99-07-41.pdf, as far as I know the latest C++ mapping specification. "1.41.5 Any Class" prescribes "Boolean operator>>=(const Any&, const char*&);" for unbounded strings, and "1.16.3 Extraction from any" says that unbounded strings are extracted by value. This seems to be contradictory: I seem to remember that const char* cannot be delete'd, though I don't find it in ISO/IEC 14882:1998(E). But, regardless of anything imposed by C++, the current mapping precludes a safe technique like (safe as in exception-proof): >> String_var theString; if(!(theAny>>=theString.out()))

    { ... }

    << I therefore propose that the mapping be changed to "Boolean operator>>=(const Any&, char*&);". This seems to work all right on my implementation (RayORB), for gcc 3.2 (MS VC++ 6.0 doesn't seem to care one way or the other, but I suppose that is wrong, although I'm not entirely sure).

  • Reported: CPP 1.1 — Mon, 10 Feb 2003 05:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

Section: 13.6 Server mapping

  • Key: CPP13-67
  • Legacy Issue Number: 11403
  • Status: open  
  • Source: Alcatel-Lucent ( Ou changhua)
  • Summary:

    Althrough I report my issue as a C++ issue, actually it is a common issue for other languages also. In current CORBA standard, a activated CORBA Servant object in the POA is shared by all the clients. But in many applications, a client connects to the server and calls some CORBA object methods to create a lot of connection related CORBA objects. Normally, the client will call "destroy" method of these CORBA object to destroy them before existing. But if the client exists abnormally, these created CORBA object will never be destroyed and never be used by any client. We can call this kind of CORBA object as "floating" CORBA object. The CORBA server application runs longer, the "floating" CORBA objects becomes more. And eventually, these "floating" CORBA objects will consume all the memory resources/CPU resources, then the CORBA server crashes and has to be restarted. The "floating" CORBA objects problem at the server side is not easy to be solved. For this problem, if the CORBA standard provides a method to solve it, the CORBA server will run more robust. Actually, the underlying network connection broken can be detected very effectively and rapidly. The CORBA server just simply ignores the network connection lost event and does not pass it to activated CORBA object even if the CORBA object is connection related object because current CORBA standard thinks that all the CORBA objects in the server are shared to all clients. If the server can notify the network connection lost event to the connection related CORBA objects, the developper can do the clean job on it. A simple method can solve the "floating" CORBA object problem. It is not required to add any new interface or data structure to current orb.idl. It is just required to add some new language mapping methods at server side only. I will give an example in C++ to show this simple method. A IShared,IConnSpec and IOtherConnectionSpec interfaces are defined below: interface IOtherConnectionSpec

    { ... }

    interface IConnectionSpec

    { IOtherConnectionSpec someMethod(); }

    interface IShared

    { IConnectionSpec createConnSpec( in string param ); }

    ; These interfaces will be used in this example. 1) the IShared will be shared by all the clients, it is activated like this: SharedImpl sharedImpl( ... ); ... sharedImpl._this(); 2) add new mapping method for the "POA_IShared::createConnSpec()" like this: IConnectionSpec_ptr POA_IShared::createConnSpec( char* param, const ConnectionContext& connCtx ); In this method, a parameter named ConnectionContext that represents the connection between the client and server is added. This method has a default implementation like this: IConnectionSpec_ptr POA_IShared::createConnSpec( const char* param, const ConnectionContext& connCtx )

    { //just ignore the connCtx like the current CORBA standard defines return createConnSpec( param ); }

    3) If the user wants to create a connection related object, he/she must overload the "IConnectionSpec_ptr createConnSpec( char* param, const ConnectionContext& connCtx )" method and active the object with "this_( const ConnectionContext& connCtx )" method: IConnectionSpec_ptr POA_IShared::createConnSpec( const char* param, const ConnectionContext& connCtx )

    { ... IConnectionSpec *connSpecImpl = new IConnectionSpec( ... ); ... //use the connection related active method return connSpecImpl->this_( connCtx ); }

    in this method, the user uses the "this_( const ConnectionContext& connCtx)" method instead of the old "this()"" method to active the CORBA object. This activated CORBA object becomes a connection related object instead of shared object. Note: User can use the "this_( const ConnectionContext& connCtx)" method to active a shared object also. At this time, the ConnectionContext is a global variable "NO_CONNECTION_CONTEXT". 4) add a new mapping method named "getConnectionContext()" for every CORBA object. const ConnectionContext& IShared::getConnectionContext(); const ConnectionContext& POA_IConnectionSpec::getConnectionContext(); In this way, the IConnectionSpec can create and activate any other connection related CORBA object like this: IOtherConnectionSpec_ptr POA_IConnectionSpec::someMethod()

    { ... OtherConnectionSpecImpl *otherConnSpecImpl = new OtherConnectionSpecImpl(...); ... return otherConnSpecImpl->this_( getConnectionContext() ); //or ? //return otherConnSpecImpl->this_( this ); }

    5) add a new mapping method named "connectionLost()" for every CORBA object. When the network connection is lost, the CORBA server should find all the CORBA object associated with this network connection and call their "connectionLost()" method. The "connectionLost()" and its default implementation is listed below: void POA_IConnectionSpec::connectionLost()

    { //just delete this connection related object simply delete this; } void POA_IOtherConnectionSpec::connectionLost() { //just delete this connection related object simply delete this; }

    Because the SharedImpl object that created in the 1) step does not assicate with any connection, its "connectionLost()" method will not be called for ever.

  • Reported: CPP 1.1 — Fri, 14 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Concrete ValueType _init class problem

  • Key: CPP13-66
  • Legacy Issue Number: 6413
  • Status: open  
  • Source: AT&T ( Duncan Grisby)
  • Summary:

    The second-to-last paragraph of section 1.17.10.3 says

    "For valuetypes that have no operations or initializers, a concrete type-specific factory class is generated whose implementation of the create_for_unmarshal function simply constructs an instance of the OBV_ class for the valuetype using new and the default constructor."

    As specified, that requires the generation of invalid C++. The OBV_ class is abstract since it does not have implementations of the ValueBase reference counting functions.

    Perhaps the intention is that the OBV_ classes in such cases should derive from DefaultValueRefCountBase. However, the wording and explanation in section 1.17.6 explicitly forbids this:

    "Note that it is the application-supplied concrete valuetype classes that must derive from these mix-in classes, not the valuetype classes generated by the IDL compiler."

    One solution that avoids the problem, and avoids restricting the application's use of the OBV_ classes is to generate yet another class that derives from both the OBV_ class and DefaultValueRefCountBase, for instantiation by the _init class's create_for_unmarshal function.

  • Reported: CPP 1.1 — Mon, 3 Nov 2003 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

conversion algorithm not specified

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

    C++ programmers will often want to use strings as
    object identifiers, the C++ mapping provides several conversion
    functions that convert strings to ObjectId and vice-versa:"

    The purpose is so the programmer can pick an arbitrary natural language
    string and use it as an ObjectId, not so that the programmer can
    generate a randomly unreadable string out of a binary ObjectId.
    [...] the C++ mapping provides several conversion functions
    that convert strings to ObjectId and viceversa:
    [...]
    If conversion of an ObjectId to a string would result in
    illegal characters in the string (such as a NUL), the first two
    functions throw the CORBA::BAD_PARAM exception.

    The conversion algorithm is not specified, and the ORB is free to
    choose whatever encoding it likes for its Object IDs. (Object IDs
    in stringified form need not be moved across address spaces (or,
    at least, not across ORB boundaries), so having a proprietary
    encoding is perfectly OK.)

  • Reported: CPP 1.1 — Fri, 19 Jul 2002 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Fixed and truncation/rounding?

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

    Suppose we have:

    typedef fixed<4,3> FT;

    interface I

    { FT op(); }

    ;

    Suppose the server does:

    FT
    I_impl::
    op() throw(CORBA::SystemException)

    { double d = 1.0/3.0; return CORBA::Fixed(d); }

    There are lots more digits in the return value than what is expected by the
    client. What should be returned to the client. The rounded value? The
    truncated value?

    Similarly, what if we have:

    double d = 10000000;
    return CORBA::Fixed(d);

    Do we return 9.999 to the client (which is the best we can do in this case)?

    Of course, it is the responsibility of the programmer to make sure that
    nonsense such as the second case doesn't happen. But the spec has to say
    what happens if it does happen

    Also, the first case will be very common – what should happen in this case?

  • Reported: CPP 1.1 — Thu, 23 Aug 2001 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

ServantBase needs _get_domain_managers()?

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

    The Object::get_domain_managers() operation is a transmissible operation
    with CORBA 2.3. Does ServantBase need anything added to handle this or
    is this managed internally by the ORB/POA?

  • Reported: CPP 1.1 — Sun, 29 Apr 2001 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

No portable way to create a OUT argument for a DII request

  • Key: CPP13-64
  • Legacy Issue Number: 6245
  • Status: open  
  • Source: Memorial University of Newfoundland ( Jeffrey Parsons)
  • Summary:

    Since the Any constructor from type code, void* value and boolean release flag has been eliminated, there is no longer any portable way to create an OUT argument for a DII request, without also assigning a value to it.

    I propose either a constructor from type code or changing the behavior of the type code set method to always succeed if the Any's TCKind is tk_null.

  • Reported: CPP 1.1 — Fri, 5 Sep 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Prohibit extracting from any into _out type?

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

    Just as we prohibited direct extraction from any any into a _var type
    due to the perils of memory management problems, we ought to prohibit
    extracting into _out types of variable sized structured types for the
    same reason

  • Reported: CPP 1.1 — Tue, 25 Jun 2002 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Add set of typedefs that would facilitate template programming

  • Key: CPP13-60
  • Legacy Issue Number: 4797
  • Status: open  
  • Source: Memorial University of Newfoundland ( Jeffrey Parsons)
  • Summary:

    The addition amounts to a set of typedefs that would facilitate template
    programming, added to each C++ skeleton class created for an IDL interface,
    and analogous to the typedefs that already exist in the mapping for the stub
    side. Say we have an IDL file

    module foo
    {
    interface bar {};
    };

    Then in generated code we're talking about something like:

    namespace POA_foo
    {
    class bar

    { public: typedef foo::bar _stub_type; typedef foo::bar_ptr _stub_ptr_type; typedef foo::bar_var _stub_var_type; . . . }

    ;
    };

  • Reported: CPP 1.1 — Fri, 28 Dec 2001 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

UTF-8 and IDL character types in C++

  • Key: CPP13-59
  • Legacy Issue Number: 4539
  • Status: open  
  • Source: AdNovum Informatik ( Stefan Wengi)
  • Summary:

    implementing support for wchar/wstring I ran into some potential
    problems with the UTF-8 encoding for the IDL 'char' type.

    Lets suppose we have a C++ server with a native single-byte code set
    like ISO 8859-1.
    The Code Set Conversion specification states that UTF-8 is the fallback
    code set for 'char'.
    -> a client could decide to send characters in UTF-8 encoding.

    What happens on the server side with UTF-8 encoded characters that use
    more than 1 byte and thus don't fit into the single byte character as
    specified by the C++ mapping for IDL type 'char'?

  • Reported: CPP 1.1 — Wed, 29 Aug 2001 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Optional parameters for _create_request?

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

    On page 1-119, the spec says the following about _create_request() and
    _create_request2():

    [...] the ORB requires:

    • a target object reference
    • an operation name
    • a list of arguments (optional)
      ^^^^^^^^^^
    • a place to put the result (optional)
      ^^^^^^^^^^
    • a place to put any returned exceptions
    • a Context (optional)
      ^^^^^^^^^^
    • a list of the user-defined exceptions that can be
      thrown (optional)
      ^^^^^^^^^^
    • a list of Context strings that must be sent with the
      operation (optional)
      ^^^^^^^^^^

    Note all the "optional" remarks.

    It's not clear what "optional" actually means. We have two cases for
    these parameters:

    • Arguments, user exceptions, and IDL contexts are sequences.
    • Result and context are object references.

    Two questions:

    • What does it mean for a sequence parameter to be "optional"?
      That I can pass a null pointer or that I can pass an empty
      sequence? I assume that an empty sequence is meant, but the spec
      doesn't say that.
    • What does it mean for a reference parameter to be "optional"?
      That I can pass a nil reference or that I must pass a reference
      to some dummy object that indicates that the value really isn't
      there?

    Where this is particularly annoying is for the return value. (The
    "result" parameter to _create_request()):

    • If I can pass a nil reference, no problem. This could
      be interpreted to mean the same thing as a void
      return type.
    • If I can't pass a nil reference, what should I pass?
      Obviously, it would have to be a reference to a valid
      NamedValue object. But how do I create that NamedValue
      object?

    I can call ORB::create_named_value(), but what should
    I do then?

    CORBA::NamedValue_var result;
    orb->create_named_value(result);

    At this point, I have a NamedValue containing an Any with
    tk_null (because that's what the Any default constructor
    creates). However, to correctly indicate that the operation
    I want to call has a void return type, I have to make a
    NamedValue that contains an Any with tk_void. But, how do
    I achieve that? I can't use one of the Any inserters to
    turn the TypeCode in the Any into tk_void, and I can't
    use the type() member of the Any because I can't change the
    type of an Any if it isn't consistent with the TypeCode that's
    already there...

    Even worse, the NamedValue doesn't seem to make sense as
    the return value at all. For one, it has a name attribute.

    • What is the value of that name for a return value?
    • How would I set that string after having create the NamedValue
      by calling create_named_value()?
    • What is the value of that string once I have called
      create_named_value()?

    Second, the NamedValue contains a flags attribute.

    • What is the value of that flags attribute for a return value?
      None of ARG_IN, ARG_INOUT, or ARG_OUT make sense. (One could
      argue that ARG_OUT could be used, but I think that sucks...)
    • How would I set that flag on the NamedValue I have just created?
      The mapping for NamedValue only offers accessor but no
      modifiers, so I can't set the value of the flag.
    • What is the value of the flag once I have called
      create_named_value()?

    It seems that the easiest way to fix the problem is to state that, if a
    parameter isn't needed, this is indicated by an empty sequence for lists,
    and by a nil reference for objects.

    However, the problems around create_named_value() and appear to be more
    serious. How should we fix those?

  • Reported: CPP 1.1 — Tue, 16 Jan 2001 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

ORB::destroy() missing

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

    The June 99 version of the C++ mapping doesn't mention ORB::destroy().
    It should.

  • Reported: CPP 1.1 — Thu, 11 Jan 2001 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Passing two context lists to _create_request()

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

    The second version of _create_request() accepts two context lists:

    void Object::_create_request(
    Context_ptr ctx, // <===
    const char * operation,
    NVList_ptr arg_list,
    NamedValue_ptr result,
    ExceptionList_ptr,
    ContextList_ptr, // <===
    Request_out request,
    Flags req_flags
    );

    The spec then says:

    The ContextList differs from the Context in that the former supplies
    only the context strings whose values are to be looked up and sent
    with the request invocation (if applicable), while the latter
    is where those values are obtained.

    So, I think (but I'm not sure), this means to say that:

    • The Context parameter points at a tree of context objects.
    • The ContextList pointer points at an object that contains
      a sequence of strings.
    • The ContextList determines which context values are to be
      picked out of the tree pointed at by the Context parameter and
      to be sent with the invocation.

    If that is the intended interpretation, it's very difficult to discern
    from the words in the spec now. I think this needs clarification.

    Questions:

    • What happens if the ContextList contains the name of a context
      variable that isn't available in the context tree?
    • What happens if I have a non-empty context list but a nil
      context tree?

    Also, looking at the ContextList interface:

    pseudo interface ContextList

    { readonly attribute unsigned long count; void add(in string ctxt); string item(in unsigned long index) raises(Bounds); void remove(in unsigned long index) raises(Bounds); }

    ;

    There is no further documentation on this. Some questions:

    • As far as I can see, this interface is meant to maintain a
      simple sequence of strings. So, why not simply use a string
      sequence?
    • At what position does add() add the item? Presumably at the tail,
      but that isn't stated.
    • How can I replace the value of string at a certain position?
      It looks like I can't do that at all because there is no
      random-access modifier.

    This seems insanely complex.

    Suggestion: We should

    • add words to make it clear how the context parameters work
    • consider overloading _create_request() yet again to use
      an ordinary string sequence
    • deprecate the ContextList pseudo interface

    Or, we could drop support for IDL context altogether (but I suspect we
    can't get away with that

  • Reported: CPP 1.1 — Tue, 16 Jan 2001 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

CORBA::RequestSeq or CORBA::ORB::RequestSeq?

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

    with 2.3, we got rid of all the C/C++ pseudo code for the DII and replaced
    it with IDL. Unfortunately, this has broken something in the C++ mapping...

    In the 2.0 spec, we had:

    pseudo interface ORB

    { typedef sequence<Request> RequestSeq; // ... }

    ;

    With 2.3, we changed this to:

    module CORBA

    { // ... typedef sequence<Request> RequestSeq; // ... }

    ;

    Unfortunately, the C++ mapping still shows the (now incorrect) definition
    from CORBA 2.0 in Section 1.33.1.

    In addition, the C++ mapping shows in Section 1.33.2:

    class ORB {
    public:
    class RequestSeq

    {...}

    ;
    // ...
    };

    But then, in Section 1.41.21:

    class ORB

    { public: typedef sequence<Request_ptr> RequestSeq; // ... }

    ;

    The latter definition isn't C++...

    So, we have several issues here:

    1) How can we fix the C++ mapping to be in line with the core?

    I'm toying with the idea of saying that RequestSeq is defined
    in the CORBA namespace, with a typedef for backward compatibility
    in the ORB interface. But I'm not sure what will break with
    this kind of aliasing (repository IDs might change unexpectedly?)

    2) Section 1.41.21 should be changed to show legal C++.

    3) Depending on the resolution to this issue, both 1.33.2 and
    1.41.21 will probably need updating to reflect the resolution.

  • Reported: CPP 1.1 — Fri, 27 Oct 2000 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

_default_POA if no default ORB?

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

    what should _default_POA() return if the default ORB was never initialized?
    The spec doesn't say...

  • Reported: CPP 1.1 — Tue, 17 Oct 2000 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

questions to IDL - C++ mapping ( CORBA 2.3, valuebox)

  • Key: CPP13-51
  • Legacy Issue Number: 4119
  • Status: open  
  • Source: Fraunhofer FOKUS ( Dorota Witaszek)
  • Summary:

    I have the following questions to IDL - C++ mapping CORBA 2.3 (concerning valueboxes).
    Can somebody give me an answer?

    1. I assume that valueboxes T as a special kind of valuetypes also
    need in C++ the T_var and the T_out types and the T_out types will be
    used in function signatures for IDL out-parameters. Is it true?

    2. The mapping for strings and wstrings requires a definition of C++
    operators << and >> to allow a use of strings (wstrings) with the c++ iostreams.
    What about valueboxes of strings (wstrings) - chapter 1.17.7.4?
    Is it required to define (in C++) the operators <<, >> to use T_var and T_out
    with C++ iostreams, where T is a type for a valuebox T of string (wstring)?

  • Reported: CPP 1.1 — Tue, 14 Nov 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Inserters/extractors for boxed strings?

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

    Given

    valuetype WStringValue wstring;

    is there any requirement to have stream inserters and extractors for the
    boxed value type itself? The spec is currently silent on this issue.

    Should the following work?

    WStringValue ws;
    cin >> ws;
    cout << ws;

  • Reported: CPP 1.1 — Mon, 12 Feb 2001 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

publication of messaging / unchecked_narrow

  • Key: CPP13-55
  • Legacy Issue Number: 4157
  • Status: open  
  • Source: UBS ( Hans Kneubuehl)
  • Summary:

    Incorporate Messaging changes relevant to the C++ mapping, as shown in
    orbos/98-05-05 pages 115 and 116 together with any changes made to them
    by the Messaging RTF, into the IDL-C++ mapping chapter.

  • Reported: CPP 1.1 — Fri, 19 Jan 2001 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Supporting typedefs for _var types?

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

    quite some time ago, we added the _var_type and _ptr_type definitions
    to proxies to make it easier to write templates. Similarly, we have
    the _whatever_seq typedefs for recursive structs and unions, to avoid
    problems with anonymous types.

    What's missing at the moment is a similar feature for _var types.
    When I'm writing a template that does it's job in terms of _var types,
    I also quite often want to do something to the underlying target type
    of the _var. However, I can't do that unless I pass in an extra template
    parameter (which, in turn, doesn't always work if I also want to use
    STL standard binders and such...)

    So, why not add a typedef for the target type to every _var type?

  • Reported: CPP 1.1 — Fri, 14 Apr 2000 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Variable-length out params and exceptions

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

    the spec is currently not terribly clear about the server's responsibilities
    when throwing an exception from an operation that has a variable-length
    out param.

    The intent of the spec is that the server is responsible for deleting
    the memory it allocated to an out param before it throws an exception:

    // Correct implementation
    void
    Foo_impl::
    op(CORBA::String_out out_p) throw(CORBA::SystemException)

    { CORBA::String_var tmp = CORBA::string_dup("Hello"); bar(); // bar() may throw out_p = tmp._retn(); // No leak, even if bar() throws }

    // Incorrect implementation
    void
    Foo_impl::
    op(CORBA::String_out out_p) throw(CORBA::SystemException)

    { out_p = CORBA::string_dup("Hello"); bar(); // Leak if bar() throws }

    However, the spec never states this clearly. In fact, it sort of says
    the opposite. On page 1-110, table item 3:

    To maintain local/remote transparency, the caller must always
    release the returned storage, regardless of whether the callee
    is located in the same address space as the caller or is located
    in a different address space.

    There is no mention here of what should happen in the presence of exceptions.

    I think it would be nice to clarify that the skeleton will never look
    at an out param in the presence of exceptions and that the operation
    implementation is responsible for deallocating memory in this case.

  • Reported: CPP 1.1 — Tue, 11 Apr 2000 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Read-only parameter remnants

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

    in the resolution to issue 863, we decided to get rid of the read-only
    restriction for parameters. However, we forgot to remove a few snippets.

    Page 1-110, table, case 3:

    Remove the following text:

    Following the completion of a request, the caller is not allowed
    to modify any values in the returned storage--to do so, the
    caller must first copy the returned instance into a new instance,
    then modify the new instance.

    Page 1-110, table, case 6:

    Remove the following text:

    Following completion of a request, the caller is not allowed
    to modify any values in the returned storage--to do so, the
    caller must first copy the returned array instance into a new
    array instance, then modify the new instance.

  • Reported: CPP 1.1 — Tue, 11 Apr 2000 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Sequence mapping & custom marshalling

  • Key: CPP13-40
  • Legacy Issue Number: 3537
  • Status: open  
  • Source: Cisco Systems ( Paul Kyzivat)
  • Summary:

    Section 1.17.11 of ptc/2000-01-02 says that DataInputStream &
    DataOutputStream are mapped according to the normal valuetype mappings.
    This mapping results in operations that are at best cumbersome to use in
    marshalling sequences of primitive types:

    Operations read_xxx_array and write_xxx_array are defined, taking argments
    of type CORBA::xxxSeq. These are obviously intended to be sufficient for
    marshalling all defined sequences of the corresponding primitive type xxx.

    However, the c++ mapping for sequences requires that each distinctly
    declared sequence type be unique and separately overloadable. This
    guarantees that a marshaller attempting to marshal an sequence of primitive
    other than CORBA::xxxSeq will not be able to pass that sequence to the
    corresponding read_xxx_array and write_xxx_array operations. Instead, code
    must be written to bypass strict typing.

    To fix this, either the mappings for DataInputStream and DataOutputStream
    need to be non-standard, the mapping of sequences needs to change, or the
    mapping of CORBA::xxxSeq needs to change to something special.

  • Reported: CPP 1.1 — Mon, 10 Apr 2000 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

set_servant and null servant

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

    the text for set_servant doesn't say what should happen if I call
    set_servant(0). I would suggest to throw BAD_PARAM in this case.

  • Reported: CPP 1.1 — Tue, 22 Feb 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

ref counting ambiguous?

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

    For servant reference counting, the words "at least once" appear
    in a number of places when it comes to servant activation. set_servant(),
    activate_object(), activate_object_with_id(), servant_to_id(),
    servant_to_reference(), and _this() all use this language (pages 1-137 and
    1-138):

    ... will invoke _add_ref at least once on the Servant argument...

    Problem: suppose my ORB calls _add_ref() twice in each of these operations
    for some reason. I now have a problem. That's because, for servant
    activators, responsibility for calling _remove_ref() passes to
    etherialize(). However, if the ORB is permitted to call _add_ref() as
    many times as it likes, I have no idea how many times I have to call
    _remove_ref() from within etherealize(). I think that the spec should say
    that _add_ref() is called exactly once for these operations if the
    corresponding servant is not in the AOM already.

    I vaguely remember the discussion about optimization of the calls
    to _add_ref() and _remove_ref(). I think the idea was to permit the ORB
    to avoid redundant calls. However, it seems that the language in the spec
    isn't precise enough. Under one interpretation, the refcount counts
    the number of entries in the AOM. Under another interpretation, it counts
    the number of calls in progress as well (because an ORB could call _add_ref()
    when a call is dispatched and call _remove_ref() when it finishes).
    Under yet a third interpretation, the refcount counts the number of
    object references in my address space. That interpretation is happens
    if every call to _this() calls _add_ref()...

    The language is not precise enough, I think...

  • Reported: CPP 1.1 — Fri, 3 Mar 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Object Reference insertion/extration to Any

  • Key: CPP13-30
  • Legacy Issue Number: 3248
  • Status: open  
  • Source: Cisco Systems ( Paul Kyzivat)
  • Summary:

    I believe the specification for insertion of object references to Anys is
    somewhat ambiguous. And, if it is intended to be as I think, it may also be
    less than ideal.

    Consider the following idl:

    interface B

    {...};
    interface D : B {...}

    ;

    And then consider the following code:

    D_ptr d; // initialize this to non-null value somehow
    B_ptr b = B::_narrow(d);
    Any ab;
    ab <<= b;
    Any ad;
    ad <<= d;
    // ...
    B_ptr b_val;
    if (ab>>=b_val)

    { /* do stuff with b_val */ }; // 1
    if (ad>>=b_val) { /* do stuff with b_val */ }

    ; // 2
    D_ptr d_val;
    if (ab>>=d_val)

    { /* do stuff with d_val */ }; // 3
    if (ad>>=d_val) { /* do stuff with d_val */ }

    ; // 4

    >From what I can see of the spec, it is a bit unclear about whether then
    insertion of an object should use the static type or the dynamic type of the
    object to initialize the typecode. Simplicity and consistency with other
    related operations suggests that it should use the static type. That is what
    we currently do, and a quick test of ORBIX 2000 seems to tell me it does it
    that way too.

    With that interpretation, 1&4 will work, while 2&3 will fail.
    Nobody should be surprised that 3 fails, but it is inconvenient
    that 2 doesn't work.

    If insertion used the dynamic type of its argument, then 1&2
    would work, while 3&4 would fail.

    To get reasonable behavior when derived types might be present,
    (and how often can you be certain they cannot?)
    it seems that one should almost never use type specific object
    extraction. Instead, one must do something like:

    Object_var o;
    B_var bv;
    if (ad>>=to_object(o._out()) &&
    !CORBA::is_nil(bv = B::_narrow(o)))

    { // do stuff with bv }

    ;

    This is unfortunately a bit inconvenient.

    So, is there any text in the spec that says, when inserting an object
    reference type into an any, if the repository id in the typecode should be
    the static type of the inserted argument or the dynamic type of the value of
    the argument?

    If not, I think we need to add some text.

  • Reported: CPP 1.1 — Thu, 27 Jan 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

DSI and implicit activation

  • Key: CPP13-39
  • Legacy Issue Number: 3532
  • Status: open  
  • Source: Anonymous
  • Summary:

    The C++ "Mapping of PortableServer Dynamic Implementation Routine" states
    that "If DynamicImplementation::_this() is invoked outside of the context
    of a request invocation on a target object being served by the DSI servant,
    it raises the PortableServer::WrongPolicy exception".

    This conflicts with the behaviour of _this() in static skeletons as de-
    fined in "Skeleton Operations".

    In particular, this means that DSI servants cannot be implicitly acti-
    vated, and therefore, the choice of DSI vs. static skeleton is not trans-
    parent to the application integrator.

    Is there any rationale behind this?

  • Reported: CPP 1.1 — Fri, 7 Apr 2000 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

void * operations on Any?

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

    I seem to remember that we decided to deprecate the void * functions
    on type Any. However, looking at the latest C++ draft, they are not
    marked as deprecated.

    Can anyone remember what we decided to do? Is this a bug in the spec
    or a bug in my memory?

  • Reported: CPP 1.1 — Thu, 2 Mar 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Valuetype "copying" semantics underspecified? (C++ issue # 1)

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

    C++ issue #1: The C++ specification should state that valuetype
    parameters which are copied by the ORB for collocated invocations are
    done using an ORB internal mechanism, not _copy_value().

  • Reported: CPP 1.1 — Fri, 18 Feb 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

ValueBase::_copy_value() function is underspecified

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

    The CORBA 2.3 C++ mapping is clear on what the use of
    ValueBase::_copy_value is, but is unclear as to who is responsible for
    providing an overriding definition of this pure virtual function. Is
    it the IDL compiler, generating an overriding _copy_value() function for
    each valuetype C++ class, or is the user, when he provides a valuetype
    implementation class?

  • Reported: CPP 1.1 — Wed, 16 Feb 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Valuetype "copying" semantics underspecified? (C++ Issue # 2)

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

    C++ issue #2: The ValueBase::_copy_value() function should be
    deprecated in favor of a new ValueBase::_clone_value() operation:

    // IDL
    module CORBA {
    abstract valuetype CloneContext { };
    };

    // C++
    namespace CORBA {
    ...
    class ValueBase

    { ... public: ValueBase *_clone_value(CloneContext *&); }

    ;
    ...
    };

    The _clone_value() function provides an independant copy of the
    valuetype it is invoked on. Any valuetypes reachable via the state of
    the original valuetype are also copied, and relationships between
    original valuetype(s) will be preserved in the cloned copies. The
    CloneContext argument provides the necessary state information for the
    ORB to properly maintain relationships between copied valuetypes. If
    _clone_value() is called with a null CloneContext, a new CloneContext
    will be generated and returned by the ORB as a result of the call.

  • Reported: CPP 1.1 — Fri, 18 Feb 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Issue with valuetypes & inout/out parameters

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

    The CORBA 2.3 C++ specification, section 1.22 states that valuetypes
    passed as in parameters to an invocation of an object are copied, even
    if the object is collocated with the caller. It does not make this
    statement for inout or out parameters (or return results), which
    strongly suggests that valuetype copying is not necessary. In fact, the
    text for valuetype inout parameters strongly suggests that copying is
    not performed.

    I think this is wrong and inout & out valuetypes should be copied as
    well (inout parameters should be copied before and after the invocation,
    while out and return values should be copied after the invocation
    completes.) Without the copies, call transparency will be broken and
    the client can distinguish between a local and a remote call.

  • Reported: CPP 1.1 — Thu, 24 Feb 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Constructor for structures?

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

    The mapping for user exceptions and structures is identical, except
    for one thing: user exceptions have an additional constructor with
    one parameter for each member, so I can construct and throw the exception
    with a single throw statement.

    However, structures are second-class citizens: I can't instantiate and
    initialize a structure at the same time. (Well, at least not in general,
    because static initialization only works for aggregates and, at any rate,
    I can only instantiate and initialize with compile-time constants.)

    So, why don't we add the same constructor to the mapping for structures?
    It seems inconsistent to have one mapping for structures and a slightly
    different one for exceptions, when in fact they both could be the same.

  • Reported: CPP 1.1 — Wed, 1 Mar 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

unclear semantics for valuetype insertion into Any

  • Key: CPP13-45
  • Legacy Issue Number: 3574
  • Status: open  
  • Source: Cisco Systems ( Paul Kyzivat)
  • Summary:

    The semantics for insertion of a valuetype into an Any are unclear.
    (Note, this is related to issue 2531 in the IDL-to-Java RTF.
    It is also related to orb_revision issue 3205.)

    In section 1.16.2 of ptc/2000-01-02, two forms of insertion are defined:
    copying and non-copying. The non-copying form is described as:

    "The noncopying valuetype insertion consumes the valuetype pointed to by the
    pointer that T** points to. After insertion, the caller may not access the
    valuetype instance pointed to by the pointer that T* points to. The caller
    maintains ownership of the storage for the pointed-to-T* itself."

    There is no specific description of the copying form specific to valuetypes,
    so the generic description must apply:

    "For the copying version of operator<<=, the lifetime of the value in the
    any is independent of the lifetime of the value passed to operator<<=. The
    implementation of the any may not store its value as a reference or pointer
    to the value passed to operator<<=."

    One possible interpretation (1) is that the copying form should be
    implemented via a call to the _copy_value virtual function, while the
    non-copying form should simply retain the provided pointer (without calling
    _add_ref) and eventually call _remove_ref when done with it.

    If so, what is the significance of the rule about the caller not continuing
    to use the pointer? It it only that it has lost a reference count, and may
    continue using the pointer if it has another reference count? Or does this
    imply that continued access to the value is forbidden regardless of
    reference count?

    Another possible interpretation (2) is that the description is nonsense, and
    that the non-copying form should use _add_ref and the copying form should
    use _copy_value. In this interpretation the caller would be free to continue
    using the original pointer and would be obligated to _remove_ref it
    eventually. This seems like a more practical interpretation, but is
    inconsistent with usage for other non-copying insertions.

    Suggested Resolution:

    Replace the paragraph on non-copying insertion of valuetypes (quoted above)
    with:

    "The noncopying valuetype insertion takes ownership of one reference count
    to the valuetype pointed to by the pointer that T** points to. After
    insertion, the caller should treat the pointer as if _remove_ref had been
    called on it. The caller maintains ownership of the storage for the
    pointed-to-T* itself."

    "For copying valuetype insertion, the lifetime of the value in the any is
    independent of the lifetime of the value provided. The implementation of the
    any shall duplicate the value using the virtual function _copy_value or an
    equivalent mechanism. The caller retains ownership of the T* pointer and
    remains obliged to call _remove_ref on it."

  • Reported: CPP 1.1 — Thu, 20 Apr 2000 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Any insertion for Boolean/Octet/Char

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

    The mapping is currently a bit ambiguous about the insertion/extraction
    operators for Any. It says:

    Assuming that boolean, char, and octet all map the C++ type
    unsigned char, the private and unimplemented operator<<= and
    operator>>= functions for unsigned char will cause a compile-time
    error if straight insertion or extraction of any of the
    boolean, char, or octet types is attempted.

    This is ambiguous. It is not clear what is qualified by the first part
    of the sentence "Assuming that...". It could qualify all of the paragraph,
    in which case the interpretation is:

    Only on platform where these three types indeed map to the same
    C++ type will it be necessary to have these unimplemented operators.

    // C++ Octet
    oct = 040;
    Any any;
    any <<= oct; // this line will not compile
    any <<= Any::from_octet(oct); // but this one will

    This is unambiguous, but it doesn't make it clear whether this will be
    the case for all mapping implementations, or only those where the
    IDL types map to ambiguous C++ types.

    It is important to note that the previous example is only one
    possible implementation for these helpers, not a mandated one.
    Other compliant implementations are possible, such as providing
    them via in-lined static any member functions if boolean, char,
    and octet are in fact mapped to distinct C++ types. All
    compliant C++ mapping implementations must provide these helpers,
    however, for purposes of portability.

    Again, this is slightly ambiguous because, even though it requires the
    presence of the helpers, it doesn't make any statement about whether the
    prohibition of the direct insertion operators is mandatory for all
    implementations.

    I would suggest to clarify the text to state that direct insertion/extraction
    of Bool, Octet, and Char must fail with a compile-time error, regardless
    of how these types are mapped.

  • Reported: CPP 1.1 — Tue, 18 Apr 2000 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

CORBA::Environment for EH compilers

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

    Question: Is it legal to do the following if I use a C++ mapping that
    uses C++ exceptions instead of using CORBA::Environment to
    handle errors?

    CORBA::Environment my_env;

    The spec says (page 114):

    The C++-PIDL specification differs from the C-PIDL specification
    as follows:
    [...]
    Supports a default constructor that initializes it to hold no
    exception information.

    However, the class definition that follows does not show the
    default constructor.

    So, the text disagrees with the class definition that is shown because
    "supports a default constructor" does not have a "may" or "might", so
    the text would appear to make the default constructor mandatory for
    both EH and non-EH mappings.

  • Reported: CPP 1.1 — Tue, 16 May 2000 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

unspecified criterion for Any extraction

  • Key: CPP13-46
  • Legacy Issue Number: 3603
  • Status: open  
  • Source: Cisco Systems ( Paul Kyzivat)
  • Summary:

    The C++ language mapping does not specify what criterion should be used to
    determine the validity of a typesafe extraction from an Any.

    The closest it ever comes is the statement in 1.16.3:
    "In this case, the version of operator>>= for type Long must be able to
    determine whether the Any truly does contain a value of type Long...".

    There are two obvious candidates: the equal and equivalent operations of
    TypeCode.

    Proposed resolution:

    Replace the first sentence of 1.16.3:

    "To allow type-safe retrieval of a value from
    an any, the mapping provides the following
    operators for each OMG IDL type T:"

    with:

    To allow type-safe retrieval of a value
    from an Any, the mapping provides an
    operator>>= for each OMG IDL type T.
    Each such operator returns a boolean
    indicating success or failure, and if
    successful, makes the value of the any
    available via a user supplied argument.
    The success of the operation is determined
    by applying the

    {equal | equivalent}
    operation to the typecode of the any and
    the typecode of the target type.

    The exact form of operator>>= varies
    according to the type T as follows:

    The choice of {equal | equivalent}

    needs to be discussed. I believe there
    are valid arguments for each.

  • Reported: CPP 1.1 — Tue, 9 May 2000 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

CORBA::release and CORBA::is_nil on POA_ptr

  • Key: CPP13-48
  • Legacy Issue Number: 3673
  • Status: open  
  • Source: Objective Interface Systems ( Mr. Bill Beckwith)
  • Summary:

    I believe that the CORBA::release and CORBA::is_nil
    functions that take a POA_ptr argument do not
    reference the proper scope:

    1.41.11 release and is_nil
    // C++
    namespace CORBA

    { ... void release(POA_ptr); ... Boolean is_nil(POA_ptr); ... }

    Should be:

    1.41.11 release and is_nil
    // C++
    namespace CORBA

    { ... void release(PortableServer::POA_ptr); ... Boolean is_nil(PortableServer::POA_ptr); ... }

    I don't see in the specification where the scope
    of POA_ptr is explicitly defined. But, I believe
    that the correct definition of POA_ptr is in the
    PortableServer namespace (i.e. the enclosing scope
    of the POA class).

    Then again I can't find anything in the specification
    that asserts that any Foo_ptr type must go in the
    immediately enclosing class or namespace containing
    the Foo type. :-/

    Also, if POA_ptr is in PortableServer when an ORB is
    mapping of modules to classes the definition of the
    above release and is_nil functions in the CORBA class
    will be impossible.

    So I feel compelled to ask:

    Do we really need to have release and is_nil functions
    for types outside of the CORBA module?

  • Reported: CPP 1.1 — Wed, 7 Jun 2000 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

fixed-length _var assignment from pointer

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

    the new mapping for _var types for fixed-length underlying types shows:

    T_var &operator=(T *t) {
    if (t != m_ptr)

    { delete m_ptr; m_ptr = t; }

    return *this;
    }

    This guards against self assignment when a pointer is assigned to the _var.

    I don't think this is right:

    • Assigning a pointer to a _var that already owns what the pointer
      points at is almost certainly an error:

    MyStruct * p = ...;
    MyStruct_var v = p; // OK

    // ...

    v = p; // Almost certainly an error

    • We don't do the same thing elsewhere. On page 1-13:

    A_var &operator=(const A_var& a)

    { reset(p); return *this; }

    This is inconsistent: assignment of a _ptr to a _var reference
    is not safe against self assignment, so assignment of a pointer
    to the _var for a fixed-length type shouldn't be either.

    Note that the other assignment operators are just fine – I'm only objecting
    to testing for self-assignment for operator= with a pointer as the RHS.
    (A nice compiler could even insert an assertions if a _var is assigned the
    same thing that it already points at.)

  • Reported: CPP 1.1 — Tue, 25 Jan 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UnknownUserException and stubs

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

    the spec currently says (page 1-101):

    Request invocations made through the DII may result in
    user-defined exceptions that cannot be fully represented
    in the calling program because the specific exception type
    was not known at compile-time. The mapping provides the
    UnknownUserException so that such exceptions can be represented
    in the calling process: [...]

    Here is a code snippet for the DII:

    req->invoke();
    if (req->env()->exception())

    { // Got an exception CORBA::Exception * ep = req->env()->exception(); // ... }

    The para on page 1-101, by implication, says that:

    • If there are concrete C++ types available in the caller that
      can represent the user exception, a real user exception is
      instantiated and the pointer returned by exception() points
      at the concrete user exception instance.
    • If there is no concrete C++ type available in the caller for
      a user exception, the pointer returned by exception() points
      at an instance of UnknownUserException.

    It's not as clearly spelled out as this, but it can be implied from the
    words on page 1-101.

    This is bad. For one, it implies "action at a distance". For example,
    linking the stubs for a user exception into a completely unrelated
    part of the same binary (possibly via a library) would change
    the behavior of the above DII call. Further, to make this behavior
    happen would require some form of global initialization data structure.
    In effect, there would have to be something that would let the ORB
    know (globally) for which user exceptions stub code is linked in.

    We rejected the need for global data recently in another context (for
    the proposed extraction operator for user exceptions). For the same reason,
    we should reject this here and mandate that, if I use the DII, all user
    exceptions are always returned as UnknownUserException.

  • Reported: CPP 1.1 — Tue, 25 Jan 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Construction of _var types

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

    the spec says (on page 1-23):

    The T* constructor creates a T_var that, when destroyed, will
    delete the storage pointed to by the T* parameter. The parameter
    to this constructor should never be a null pointer. Compliant
    implementations are not required to detect null pointers passed
    to this constructor.

    This seems broken for two reasons:

    • In an environment without real exceptions, null pointers must
      be returned for variable-length types in the presence of an
      exception. So if I write

    Foo_var fv(some_ref->op(my_corba_environment));

    and op() raises an exception (which will be returned in the
    environment), I'm hosed.

    • The assignment operator permits assignment of null, but the
      constructor doesn't. This is inconsistent, if nothing else.

    It seems that disallowing initialization from null pointer is some
    historical hangover? I think the restriction should be removed.

  • Reported: CPP 1.1 — Tue, 25 Jan 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

C++ spec: Valuebase missing get_value_def

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

    In section 1.17.5, the C++ class for Valuebase does not show the
    get_value_def operation.

  • Reported: CPP 1.1 — Fri, 21 Jan 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

C++ ValueBox & Fixed question

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

    Section 1.17.7.5 states: "Value boxes for these types [including Fixed]
    map to classes that have exactly the same public interfaces as the
    underlying boxed types...".

    Does this also include overloaded operators that are defined in the
    Fixed class?

    It sure seems weird to allow some operators to work but not others:

    // IDL
    valuetype FixedVal fixed<5,2>;

    // C++
    FixedVal *fv = ...;

    ++fv; // legal?

    CORBA::Fixed f = fv * 2; // illegal?

  • Reported: CPP 1.1 — Sat, 15 Jan 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Any and UnknownUserException

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

    The mapping requires that it must be possible to insert CORBA::Exception
    into an any (section 1.19.2).

    Question: Is it possible to insert UnknownUserException into an Any?

    If the answer is yes, what are the members of UnknownUserException, what
    is its CDR representation, and what is its TypeCode?

    If the answer is no, we should clearly state this and specify what happens
    if I attempt to insert UnknownUserException into an Any.

  • Reported: CPP 1.1 — Thu, 13 Jan 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT