C++ Language Mapping Avatar
  1. OMG Specification

C++ Language Mapping — All Issues

  • Acronym: CPP
  • Issues Count: 42
  • Description: All Issues
Closed All
All Issues

Issues Summary

Key Issue Reported Fixed Disposition Status
CPP12-43 Typedefs for struct members? CPP 1.1 CPP 1.2 Resolved closed
CPP12-42 Deprecated Ref identifier CPP 1.1 CPP 1.2 Resolved closed
CPP12-40 Server-side exception specifications and ISO C++ std::exception CPP 1.1 CPP 1.2 Resolved closed
CPP12-41 There is an incorrect page reference CPP 1.1 CPP 1.2 Resolved closed
CPP12-39 Remnant of read-only return values and out params CPP 1.1 CPP 1.2 Resolved closed
CPP12-38 Backward compatibility with C CPP 1.1 CPP 1.2 Resolved closed
CPP12-37 Non-exception neutral code in C++ mapping. CPP 1.1 CPP 1.2 Resolved closed
CPP12-36 Need for TIE template for skeletons for valuetypes that support CPP 1.1 CPP 1.2 Resolved closed
CPP12-35 _name & _rep_id pure virtual? CPP 1.1 CPP 1.2 Resolved closed
CPP12-34 Requiring ref counting in ServantBase CPP 1.1 CPP 1.2 Resolved closed
CPP12-33 CORBA::Fixed needs a to_string() conversion function CPP 1.1 CPP 1.2 Resolved closed
CPP12-32 Another issue with String_var CPP 1.1 CPP 1.2 Resolved closed
CPP12-31 Missing conversion operator on String_var CPP 1.1 CPP 1.2 Resolved closed
CPP12-30 Any extraction widening to ValueBase CPP 1.1 CPP 1.2 Resolved closed
CPP12-29 Null assignment to String_var? CPP 1.1 CPP 1.2 Resolved closed
CPP12-28 _name and _rep_id CPP 1.1 CPP 1.2 Resolved closed
CPP12-27 Do valuetype POA servants get tie templates? CPP 1.1 CPP 1.2 Resolved closed
CPP12-25 Problem with OBV_ valuetype class constructor CPP 1.1 CPP 1.2 Resolved closed
CPP12-26 Problem with type specific valuetype factories in CORBA 2.3.1 C++ mapping CPP 1.1 CPP 1.2 Resolved closed
CPP12-23 C++ Value Type issue (02) CPP 1.1 CPP 1.2 Resolved closed
CPP12-24 Obsolete text in 1.40.3 CPP 1.1 CPP 1.2 Resolved closed
CPP12-22 Valuebox for object reference underspecified CPP 1.1 CPP 1.2 Resolved closed
CPP12-21 C++ valuetype issue (01) CPP 1.1 CPP 1.2 Resolved closed
CPP12-20 Valuetype code typo in CORBA 2.3 C++ mapping CPP 1.1 CPP 1.2 Resolved closed
CPP12-9 Escaped keyword mapping? CPP 1.1 CPP 1.2 Resolved closed
CPP12-8 Local interfaces issue 1 CPP 1.1 CPP 1.2 Resolved closed
CPP12-16 implementing local interfaces in C++ CPP 1.1 CPP 1.2 Resolved closed
CPP12-15 Initialized T_var? CPP 1.1 CPP 1.2 Resolved closed
CPP12-14 Missin operations in Object interface, ptc/01-06-07 CPP 1.1 CPP 1.2 Resolved closed
CPP12-19 String_var and C++ implicit conversions CPP 1.1 CPP 1.2 Resolved closed
CPP12-18 need mapping for get_orb and get_component on CORBA::Object CPP 1.1 CPP 1.2 Resolved closed
CPP12-17 No Mapping for Local interface in C++ CPP 1.1 CPP 1.2 Resolved closed
CPP12-11 Bug on _var references CPP 1.1 CPP 1.2 Resolved closed
CPP12-10 Dangling reference CPP 1.1 CPP 1.2 Resolved closed
CPP12-7 Structure member ordering CPP 1.1 CPP 1.2 Resolved closed
CPP12-6 semantics of valuetype _downcast operation unclear CPP 1.1 CPP 1.2 Resolved closed
CPP12-13 ValueRefCountBase::_add_ref CPP 1.1 CPP 1.2 Resolved closed
CPP12-12 C++ mapping for CORBA::LocalObject CPP 1.1 CPP 1.2 Resolved closed
CPP12-3 LocalObject CPP 1.1 CPP 1.2 Resolved closed
CPP12-2 mapping of local interfaces CPP 1.1 CPP 1.2 Resolved closed
CPP12-5 How to create a local object reference? CPP 1.1 CPP 1.2 Resolved closed
CPP12-4 CORBA::Object & LocalObject CPP 1.1 CPP 1.2 Resolved closed

Issues Descriptions

Typedefs for struct members?

  • Key: CPP12-43
  • Legacy Issue Number: 4344
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    I recently got a query from a customer. Basically, they have a CORBA system
    that interfaces to some legacy library. Lots of structures are being passed
    back and forth, many of which contain strings; these need to be passed
    as char * or as std::string, depending on where they go.

    So, the customer defined conversion functions that correctly copied a
    std::string or char * into and out of a string member (using string_dup()
    or whatever, as appropriate). The problem is that they have to use
    an undefined type name as the type of the parameter. For example:

    void copy(const std::string & from, CORBA::string_mgr & to);

    Of course, "string_mgr" is a mapping-internal type name and therefore the
    code is non-portable.

    I don't see an easy work-around that would be within the current mapping.
    I could use a function that accepts a reference to a struct instead of
    the string inside the struct, but that then means that I need a different
    function for each structure type. Or I can write macros that are specific
    to each ORB to handle it (but that is truly ugly and breaks if the vendor
    decides to tinker with the internals of their mapping).

    One way around it all would be to require a typedef to be generated for
    string members. For example:

    // IDL
    struct Foo

    { string s; }

    ;

    // C++

    namespace CORBA {
    // ...
    class string_mgr

    { /* ... */ }

    ; // Mapping-internal class

    typedef string_mgr string_member; // New standard name
    };

    struct Foo

    { CORBA::string_mgr s; // Mapping-internal type name }

    ;

    This would allow me to portably pass a string member to a function because
    the mapping would guarantee the existence of a type named "string_member"
    (or whatever name we can settle on).

    void copy(const std::string & from, CORBA::string_member & to);

    (Depending on the mapping implementation, there may be similar issues for
    other types, such as references or arrays. If there are such mappings,
    we'd need typedefs for those too.)

    Basically, wherever a type name that is internal to the mapping can appear,
    we end up with this kind of problem – I can't pass a value of that type
    because I don't know the type name. I'd like to fix that, if possible.

  • Reported: CPP 1.1 — Fri, 15 Jun 2001 04:00 GMT
  • Disposition: Resolved — CPP 1.2
  • Disposition Summary:

    rejected

  • Updated: Fri, 6 Mar 2015 21:38 GMT

Deprecated Ref identifier

  • Key: CPP12-42
  • Legacy Issue Number: 4325
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    In the first para of section 1.3.1, we still have a sentence about
    the deprecated Ref names for object references. Those have been deprecated
    for a long time now.

    Proposal:

    Remove the sentence beginning with "For historical reasons, the
    type ARef..."

  • Reported: CPP 1.1 — Tue, 29 May 2001 04:00 GMT
  • Disposition: Resolved — CPP 1.2
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 21:38 GMT

Server-side exception specifications and ISO C++ std::exception

  • Key: CPP12-40
  • Legacy Issue Number: 4265
  • Status: closed  
  • Source: ZeroC ( Bernard Normier)
  • Summary:

    In CORBA C++ 2.4 and before, the exception specification of generated
    POA skeleton member functions is CORBA::SystemException plus the mapped C++
    class for exceptions specified in the raise expression of the corresponding
    IDL operation [see CORBA C++ 2.4 paragraph 23.27].
    As a result, a servant programmer needs to convert any exception other than
    those in the exception specification to one in the exception specification
    – else the C++ runtime will call std::unexpected() if an unexpected
    exception is thrown.

    This makes exception handling on the server-side quite painful:
    for example if a servant programmer calls operator new(), s/he's supposed
    to catch std::bad_alloc and convert it to CORBA::NO_MEMORY. Similarly,
    if s/he uses any of the ISO C++ libraries, s/he's supposed to convert the
    std::exception objects raised by the library into CORBA::SystemExceptions,
    or user-defined IDL exceptions.

    Given that C++ compilers provide more and more features of ISO C++,
    in particular the standard libraries, this is a real world issue!

    Proposal
    ========

    Add std::exception in the exception specification of generated
    POA-skeleton member functions. The POA (or POA skeleton) implementation
    is responsible to perform the following conversions:
    std::bad_alloc to CORBA::NO_MEMORY
    other std::exception to CORBA::UNKNOWN (see 3.17.1.1 in CORBA 2.3 core)

    Source-code backward-compatibility
    ----------------------------------
    I propose to make exception specifications in generated skeletons a bit
    less restrictive than they were in CORBA C++ 2.4 (and before).
    C++ servants written with the CORBA C++ 2.4 (and before) mapping do not
    require any change – their exception specifications will be more
    restrictive than required by the new mapping, which is perfectly correct.

    Interoperability
    ----------------
    It does not affect interoperability: only CORBA exceptions go on the
    wire. An ORB-mediated operation can only raise a CORBA::SystemException
    or a user-defined IDL exception.

    Alternative Mapping for C++ Dialects
    ------------------------------------
    Unfortunately, not all C++ compilers comply (or almost comply) with
    ISO C+. With such a "C+ compiler", the ORB/POA implementation will
    behave as in CORBA C++ 2.4 (i.e. no std::exception is the exception
    specification). Or maybe we can allow the ORB/POA to add an
    implementation-dependent class in the generated exception
    specifications?

    Portable user-written servants will simply include
    CORBA::SystemException (or something more restrictive) in their
    exception specifications.

  • Reported: CPP 1.1 — Wed, 11 Apr 2001 04:00 GMT
  • Disposition: Resolved — CPP 1.2
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 21:38 GMT

There is an incorrect page reference

  • Key: CPP12-41
  • Legacy Issue Number: 4274
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Details: This section (entitled 1.16.10 The Any Class) refers the reader to the full definition of the Any class. However, it provides the page number and section heading of itself – it is self referential.

    Suggested Correction: The reference should refer to the section on page 1-150 (entitled 1.41.5 The Any Class)

  • Reported: CPP 1.1 — Tue, 17 Apr 2001 04:00 GMT
  • Disposition: Resolved — CPP 1.2
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 21:38 GMT

Remnant of read-only return values and out params

  • Key: CPP12-39
  • Legacy Issue Number: 4244
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    About two or three years ago, we decided to deprecate the read-only
    nature of in params on the server side, and out params and return values
    on the client side.

    The second-last para of 1.13.2 still contains a remnant that we forgot
    to clean up back then:

    As with other out and return values, out and return sequences must
    not be assigned to by the caller without first copying them.

    I would suggest to modify this sentence to read:

    For a sequence passed to an operation as an in parameter, the
    operation must not assign to the sequence if its release flag
    is false and the sequence has variable-length elements.

    For a sequence passed to a client as an out parameter or return
    value, the client must not assign to the sequence if its
    release flag is false and the sequence has variable-length elements.

    This captures more correctly the intent and the semantics of the release
    flag (because assigning to a sequence with the release flag set to true
    is perfectly OK).

  • Reported: CPP 1.1 — Fri, 30 Mar 2001 05:00 GMT
  • Disposition: Resolved — CPP 1.2
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 21:38 GMT

Backward compatibility with C

  • Key: CPP12-38
  • Legacy Issue Number: 4243
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    the spec talks about backward compatibility with the C mapping in a number
    of places:

    • 1.1.14
    • at the beginning of 1.7
    • in the footnote on page 1-29
    • at the end of 1.10
    • at the end of 1.12
    • at the beginning of 1.13.3
    • at the end of 1.16.10
    • at the end of 1.20
    • at the end of 1.23
    • at the beginning of 1.26
    • 1.31.3
    • 1.42.1

    Binary compatibility with the C mapping has never existed and never will.

    Proposal: Remove all mention of the C mapping from the above places.

  • Reported: CPP 1.1 — Fri, 30 Mar 2001 05:00 GMT
  • Disposition: Resolved — CPP 1.2
  • Disposition Summary:

    Remove all mention of the C mapping from the above places.

  • Updated: Fri, 6 Mar 2015 21:38 GMT

Non-exception neutral code in C++ mapping.

  • Key: CPP12-37
  • Legacy Issue Number: 4210
  • Status: closed  
  • Source: University of California, Irvine ( Carlos O'Ryan)
  • Summary:

    formal/99-07-41 in section 1.36.3 includes the following code:

    ---------------- cut here ----------------
    class ServantBase_var {
    public:

    ~ServantBase_var ()

    { if (_ptr != 0) _ptr->_remove_ref (); }

    ServantBase_var& operator=(ServantBase* p)
    { if (_ptr != 0) _ptr->_remove_ref (); _ptr = p; return *this; }

    ServantBase*& out()
    { if (_ptr != 0) _ptr->_remove_ref (); _ptr = 0; return _ptr; }
    };
    ---------------- cut here ----------------

    unfortunately this code is not exception safe: if
    _remove_ref() throws the class is left in an inconsistent state (for
    out() and operator=). The fact that the destructor can potentially
    throw exceptions makes it extremely hard for application developers to
    write exception safe classes.
    A better implementation could be:

    ---------------- cut here ----------------
    class ServanBase_var
    {
    ServantBase_var& operator=(ServantBase* p)
    { if (p == _ptr) return *this; ServanBase_var tmp (p); std::swap (p._ptr, p); return *this; }

    ServantBase*& out()
    { if (_ptr != 0) _ptr->_remove_ref (); _ptr = 0; return _ptr; }
    };
    ---------------- cut here ----------------

    The implementation above also prevents silly mistakes like:

    ServantBase_var foo = ...;
    foo = foo.in ();

    The destructor is a little trickier:

    ---------------- cut here ----------------
    ServantBase_var::~ServantBase_var ()
    {
    // do not propagate exceptions out of the destructor
    try { if (_ptr != 0) _ptr->_remove_ref (); }

    catch (...)
    {
    }
    }
    ---------------- cut here ----------------

    Event better would be to add some throw spec to _remove_ref()
    and _add_ref(). The spec is, as far as I can tell, silent in this
    respect, thus those operations can throw anything. This is
    unfortunate because it makes it harder to write exception-safe code,
    both for application developers and ORB implementors alike.

  • Reported: CPP 1.1 — Tue, 20 Feb 2001 05:00 GMT
  • Disposition: Resolved — CPP 1.2
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 21:38 GMT

Need for TIE template for skeletons for valuetypes that support

  • Key: CPP12-36
  • Legacy Issue Number: 4166
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    The third bullet of 1.17.9 states that a POA skeleton class is generated
    for valuetypes that support interfaces, but is silent about whether a
    _tie template is also generated.

    Proposal:

    Add the following to the end of the third bullet in 1.17.9:

    "No tie skeleton class is generated for the valuetype because the tie
    for the inherited class can be used instead."

  • Reported: CPP 1.1 — Sat, 20 Jan 2001 05:00 GMT
  • Disposition: Resolved — CPP 1.2
  • Disposition Summary:

    duplicate of issue 3328 close issue

  • Updated: Fri, 6 Mar 2015 21:38 GMT

_name & _rep_id pure virtual?

  • Key: CPP12-35
  • Legacy Issue Number: 4153
  • Status: closed  
  • Source: IONA ( Matthew Newhook)
  • Summary:

    The definition for Exception in the current spec is:

    // C++
    class Exception

    { public: virtual ~Exception(); virtual void _raise() const = 0; virtual const char * _name() const; virtual const char * _rep_id() const; }

    ;

    Why aren't _rep_id() and _name() pure virtual?

  • Reported: CPP 1.1 — Tue, 16 Jan 2001 05:00 GMT
  • Disposition: Resolved — CPP 1.2
  • Disposition Summary:

    rejected

  • Updated: Fri, 6 Mar 2015 21:38 GMT

Requiring ref counting in ServantBase

  • Key: CPP12-34
  • Legacy Issue Number: 4114
  • Status: closed  
  • Source: Objective Interface Systems ( Mr. Bill Beckwith)
  • Summary:

    The current requirement that the default implementations of _add_ref
    and _remove_ref in ServantBase do nothing creates several problems:

    1. The text in the C++ mapping that states that _remove_ref
    must be called on a servant means nothing unless the ref
    counting mix-in was used by the servant author.

    2. The intended semantics of _var types as "smart pointers"
    is upheld only if the servant author goes to the extra
    step of using the ref counting mix-in.

    3. In many places the C++ mapping explicitly or implicitly
    states that _var types will recover memory for the application
    developer:

    1.3.1:

    Client code frequently will use the object reference
    variable type (A_var) because a variable will
    automatically release its object reference when it is
    deallocated or when assigned a new object reference.

    1.3.6:

    When a _var is passed as an out parameter, any
    previous value it refers to must be implicitly
    released.

    In addition, there are many places in the C++ mapping where
    the specification of _var types for arrays, structs, strings,
    sequences, type Any, type codes, value types, value boxes,
    value factories, etc. guarantees that the memory will be
    reclaimed when the _var goes out of scope. This makes it
    easy for users to believe that all _var types will release
    storage for the objects that point to.

    Benefits of Proposed Resolution:

    Users can depend on ORB's to manage servant memory by default
    rather than by exception.

    Specification text that promises or implies automatic memory
    reclamation need not change.

    Existing user code will still compile.

    Resolution:
    Revised Text:

    Replace the text in section 1.36.1 beginning with the sentence:

    Servant instances may implement reference counting to prevent
    themselves from being destroyed while the application is
    still using them.

    and section 1.36.2 in its entirety with:

    Servant instances may implement reference counting to prevent
    themselves from being destroyed while the application is still
    using them. Servant reference counting is performed using the
    _add_ref and _remove_ref functions declared in ServantBase. The
    default implementations of _add_ref and _remove_ref supplied by
    ServantBase provide true reference counting. An instance of a
    servant class derived from ServantBase initially has a reference
    count of one. Invoking _add_ref on the servant instance
    increases its reference count by one. Invoking _remove_ref on
    the servant instance decreases its reference count by one; if the
    resulting reference count equals zero, _remove_ref invokes delete
    on its this pointer in order to destroy the servant. For ORBs
    that operate in multi-threaded environments, the implementations
    of _add_ref and _remove_ref that the ServantBase class provides
    shall be thread-safe.

    ServantBase supports copy construction and the default assignment
    operation. Copy construction always sets the reference count of
    the new servant instance to one. The default assignment
    implementation merely returns *this and does not affect the
    reference count.

    For servants that require that servants are not reference
    counted, these functions are virtual and thus may be overridden
    by derived servant classes. A default mix-in class is also
    provided to remove the reference counting in the PortableServer
    namespace; please see Section 1.36.2, "Servant No Reference
    Counting Mix-In," on page 1-??? for more details. Details
    concerning POA and application responsibilities with respect to
    reference counting can be found in Section 1.36.4, "Servant
    Memory Management Considerations," on page 1-???.

    Note that for applications that depended on the the
    RefCountServantBase provided in previous revisions of this
    specification ORBs must provide a default implementation of this
    mix-in class in the PortableServer namespace that essentially
    does nothing:

    // C++
    namespace PortableServer
    {
    class RefCountServantBase : public virtual ServantBase

    { public: ~RefCountServantBase(); protected: RefCountServantBase(const RefCountServantBase&); RefCountServantBase& operator=(const RefCountServantBase&); private: // ...other implementation details... }

    ;

    }

    1.36.2 Servant No Reference Counting Mix-In

    The PortableServer namespace also provides a standard servant
    mix-in class to remove the reference counting:

    // C++
    namespace PortableServer
    {
    class NoRefCountServantBase : public virtual ServantBase
    {
    public:
    ~NoRefCountServantBase();
    virtual void _add_ref() {}
    virtual void _remove_ref() {}
    protected:
    NoRefCountServantBase() {}
    NoRefCountServantBase(const NoRefCountServantBase&) {}
    NoRefCountServantBase& operator=(const NoRefCountServantBase&);
    private:
    // ...other implementation details...
    };
    }

    The NoRefCountServantBase mix-in class overrides the inherited
    _add_ref and _remove_ref functions it inherits from ServantBase,
    in order to override and remove the default reference counting in
    ServantBase.

  • Reported: CPP 1.1 — Thu, 6 Apr 2000 04:00 GMT
  • Disposition: Resolved — CPP 1.2
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 21:38 GMT

CORBA::Fixed needs a to_string() conversion function

  • Key: CPP12-33
  • Legacy Issue Number: 3944
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    CORBA::Fixed should have a to_string() member function to allow an
    explicit conversion to a string. Otherwise the only way to get a string
    version of the information in a fixed is via a string stream, which can
    be awkward.

    namespace CORBA {
    class Fixed

    { public: ... char *to_string(); ... }

    ;
    }

    The caller of Fixed::to_string() must deallocate the return value by
    calling CORBA::string_free or assigning it to a String_var.

  • Reported: CPP 1.1 — Tue, 10 Oct 2000 04:00 GMT
  • Disposition: Resolved — CPP 1.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:38 GMT

Another issue with String_var

  • Key: CPP12-32
  • Legacy Issue Number: 3797
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    Why is it that String_var contains the following?

    operator char *();

    The mapping never passes strings as a char *. The only parameter
    passing signatures are const char * for in params, char * & for inout params,
    and String_out for out params.

    It seems that this operator is redundant?

    The only reason I can think of for it having been added are sloppy signatures
    (such as old implementations of strcpy or some such, which sometimes used
    char * instead of const char *). However, wouldn't it be better to remove
    operator char *() from String_var and force a cast for such broken function
    signatures?

  • Reported: CPP 1.1 — Thu, 31 Aug 2000 04:00 GMT
  • Disposition: Resolved — CPP 1.2
  • Disposition Summary:

    Remove operator char*() from class String_var.

  • Updated: Fri, 6 Mar 2015 21:38 GMT

Missing conversion operator on String_var

  • Key: CPP12-31
  • Legacy Issue Number: 3796
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    Page 1-153, section 1.41.2:

    String_var has:

    operator char*();
    operator const char*() const;

    What is missing here is:

    operator char*&();

    Without that, a String_var cannot be passed as an inout param.

  • Reported: CPP 1.1 — Thu, 31 Aug 2000 04:00 GMT
  • Disposition: Resolved — CPP 1.2
  • Disposition Summary:

    Add operator char*&() to class String_var.

  • Updated: Fri, 6 Mar 2015 21:38 GMT

Any extraction widening to ValueBase

  • Key: CPP12-30
  • Legacy Issue Number: 3604
  • Status: closed  
  • Source: International Business Machines ( Michael Cheng)
  • Summary:

    Currently there is Any extraction with widening to Object, and
    AbstractBase.
    It seems useful to also have one that widens to ValueBase.

  • Reported: CPP 1.1 — Tue, 9 May 2000 04:00 GMT
  • Disposition: Resolved — CPP 1.2
  • Disposition Summary:

    duplicate of issue 3092...closed

  • Updated: Fri, 6 Mar 2015 21:38 GMT

Null assignment to String_var?

  • Key: CPP12-29
  • Legacy Issue Number: 3534
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    page 1-23 says:

    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.

    So, I can't explicitly initialize with null:

    T_var tv = 0;

    This seems strange, seeing that the default constructor does initialize
    with null.

    Also, the spec doesn't say anything about assignment. Is the following legal?

    T_var tv = ...;
    tv = 0;

    I don't understand the restriction. What's the motivation for
    disallowing this? Especially for String_var, the prohibition against null
    null seems rather draconian. For example, I may be using a temporary local
    String_var for exception safety and then, at some point, decide to
    assign null to it to force an early deallocation of the string instead
    of having to create a separate scope to achieve this.

    At any rate, we should clarify so that, whatever the eventual decision is,
    the text for the assignment operator agrees with the text for the constructor.

  • Reported: CPP 1.1 — Fri, 7 Apr 2000 04:00 GMT
  • Disposition: Resolved — CPP 1.2
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 21:38 GMT

_name and _rep_id

  • Key: CPP12-28
  • Legacy Issue Number: 3381
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    Question: do I need to deallocate the string returned by Exception::_name()
    and Exception::_rep_id() or not? The spec doesn't say...

    Given that these are PIDL, and that the return value is const char *
    (rather than non-const char *), I'd say that I shouldn't have to deallocate
    the return value. But I think we should clarify this in the spec.

    Also, the Exception class in section 1.41.7 doesn't show the _name and
    _rep_id members, so we need to add them there.

    Further, Exception doesn't show up in section 1.23 (Mapping of Pseudo
    Objects). I suspect that we need to add Exception there as well and
    mention the exception to the memory management rules? Another interesting
    thing is that, if Exception is a pseudo object, then UserException and
    everything derived from it is also a pseudo object. But, user exceptions
    can't be pseudo objects. But, if they are not pseudo-objects, we can't
    really make special-purpose memory managment rules. Sigh...

  • Reported: CPP 1.1 — Wed, 1 Mar 2000 05:00 GMT
  • Disposition: Resolved — CPP 1.2
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 21:37 GMT

Do valuetype POA servants get tie templates?

  • Key: CPP12-27
  • Legacy Issue Number: 3328
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    Section 1.17.9 states that valuetypes that support a non-abstract
    interface have a POA skeleton class generated for them. Is a tie
    template class also supposed to be generated?

  • Reported: CPP 1.1 — Thu, 17 Feb 2000 05:00 GMT
  • Disposition: Resolved — CPP 1.2
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 21:37 GMT

Problem with OBV_ valuetype class constructor

  • Key: CPP12-25
  • Legacy Issue Number: 3298
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    The CORBA 2.3.1 specification does not cover the case of code generation
    for the OBV_ class constructor for a valuetype that inherits from
    another concrete valuetype:

    // IDL
    valuetype A

    { octet o1; }

    ;

    valuetype B : A

    { octet o2; }

    ;

    The generated OBV constructor for class B needs to take both o1 and o2
    arguments, so it should look like this:

    // C++
    class OBV_B

    { ... protected: ... OBV_B(Octet init_o1, Octet init_o2) }

    ;

    Proposal:

    Change the second paragraph of 1.17.2 to read:

    "For the same reasons, a C++ OBV_ class defines a protected default
    constructor, a protected constructor that takes an initializer for each
    valuetype data member, and a protected default constructor. The
    parameters of the constructor that takes an initializer for each member
    appear in the same order as the data members appear, top to bottom, in
    the IDL valuetype definition, regardless of whether they are public or
    private. If the valuetype inherits from a concrete valuetype, then
    parameters for the data members of the inherited valuetype appear
    first. All parameters for the member initializer constructor follow the
    C++ mapping parameter passing rules for in arguments of their respective
    types."

  • Reported: CPP 1.1 — Sun, 6 Feb 2000 05:00 GMT
  • Disposition: Resolved — CPP 1.2
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 21:37 GMT

Problem with type specific valuetype factories in CORBA 2.3.1 C++ mapping

  • Key: CPP12-26
  • Legacy Issue Number: 3304
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    Section 1.17.10.3 states that type specific valuetype factories are
    generated with a public destructor. This conflicts with the reference
    counting requirement for factories, since it makes it easier for
    application code to delete a factory that still has outstanding
    references.

    Proposal:

    Change the text in 1.17.10.3 to make destructors for type specific
    valuetype factories protected rather than public.

  • Reported: CPP 1.1 — Wed, 9 Feb 2000 05:00 GMT
  • Disposition: Resolved — CPP 1.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:37 GMT

C++ Value Type issue (02)

  • Key: CPP12-23
  • Legacy Issue Number: 3224
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    2. Valuetypes should have _var typedef inside the class to aid template
    programming just like objects, structs and unions.

  • Reported: CPP 1.1 — Sat, 15 Jan 2000 05:00 GMT
  • Disposition: Resolved — CPP 1.2
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 21:37 GMT

Obsolete text in 1.40.3

  • Key: CPP12-24
  • Legacy Issue Number: 3239
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    The last C++ RTF made changes that identify specific inheritence
    strategies must be used for generating code for interfaces that inherit
    from abstract interfaces. The text in 1.40.3 was not updated to reflect
    this, and still suggests that other strategies are possible, when they
    are no longer allowed.

  • Reported: CPP 1.1 — Wed, 19 Jan 2000 05:00 GMT
  • Disposition: Resolved — CPP 1.2
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 21:37 GMT

Valuebox for object reference underspecified

  • Key: CPP12-22
  • Legacy Issue Number: 3223
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    The CORBA 2.3 C++ mapping for valueboxes (1.17.7.2) does not specify the
    behavior of the constructors, assignment operator and _value modifier
    method with respect to the object reference argument. These methods
    clearly need to call _duplicate on their argument, since the valuebox
    must manage its own memory.

    Proposal:

    Add the following paragraph just before the example in 1.17.7.2:

    Value box classes for object reference maintain a private managed copy
    of the object reference. The constructor, assignment operator and
    _value modifier method for these classes call _duplicate on the object
    reference argument, and the destructor calls CORBA::release on the boxed
    reference.

  • Reported: CPP 1.1 — Sat, 15 Jan 2000 05:00 GMT
  • Disposition: Resolved — CPP 1.2
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 21:37 GMT

C++ valuetype issue (01)

  • Key: CPP12-21
  • Legacy Issue Number: 3222
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    The CORBA 2.3 C++ mapping makes no mention of _out types for
    valuetypes. Clearly this is needed and should be mentioned.

  • Reported: CPP 1.1 — Sat, 15 Jan 2000 05:00 GMT
  • Disposition: Resolved — CPP 1.2
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 21:37 GMT

Valuetype code typo in CORBA 2.3 C++ mapping

  • Key: CPP12-20
  • Legacy Issue Number: 3206
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    Section 1.17.10.2, the definition of operator= for ValueFactoryBase_var
    has "ValueFactoryBaseBase_var".

  • Reported: CPP 1.1 — Tue, 11 Jan 2000 05:00 GMT
  • Disposition: Resolved — CPP 1.2
  • Disposition Summary:

    fixed editorially...issue closed

  • Updated: Fri, 6 Mar 2015 21:37 GMT

Escaped keyword mapping?

  • Key: CPP12-9
  • Legacy Issue Number: 4498
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    the mapping says in section 1.1.2:

    To avoid C++ compilation problems, every use in OMG IDL of a
    C++ keyword as an identifier is mapped into the same name preceded
    by the prefix "cxx." For example, an IDL interface named "try"
    would be named "_cxx_try" when its name is mapped into C++.
    For consistency, this rule also applies to identifiers that
    are derived from IDL identifiers. For example, an IDL interface
    "try" generates the names "_cxx_try_var" and "cxx_try_ptr,"
    ^^^^^^^^^^^
    that is, the IDL compiler behaves as if the interface were
    names "cxx_try" and then applies the normal mapping rules.
    ^ ^^^^^^^

    Four issues here:

    1) I think we have a typo at the first place I highlighed. I
    believe it should be "_cxx_try_ptr". (The leading underscore
    is missing in the text as it stands now.)

    2) Typo: It should be '...were named "cxx_try"', not
    '... were names "cxx_try"'

    3) To state that the compiler behaves is if the interface were
    named "cxx_try" doesn't explain where the additional leading
    underscore comes from because we get cxx, not cxx_
    for the mapped identifiers.

    Unfortunately, changing this sentence to state that the compiler
    behaves as if the interface were named "_cxx_try" won't fix
    it, because the leading underscore would be dropped by the
    IDL keyword escape mechanism.

    4) The explanations are insufficient:

    interface try {};

    This will result in "_cxx_try" as the interface name. But what
    about the generated tc type code constant? It could be:

    a) _cxx_tc_try

    This mapping would be consistent with the statement that
    the "cxx" is a prefix.

    b) cxx_tc_try

    Same as above but, given that, normally, the tc type code
    constants already start with an underscore, the escaped
    mapping results in a double underscore.

    c) _tc_cxx_try

    This mapping would be consistent with the directive to map
    as if the type were named "cxx_try".

    d) tc_cxx_try

    Same as above but preserves the underscore for both the
    "tc" and the "cxx", resulting in a double underscore.

    To me, interpretation (d) seems the most natural and intuitive because
    it preserves the leading "tc" for all type code constants (including ones
    for identifiers that are C++ keywords). Also, if the mapping of the type
    is to "_cxx_try", then it makes sense to have the double underscore because
    that is consistent and doesn't make an exception to the rule of "use
    "tc" for type code constants and "cxx" for IDL identifiers that are
    C++ keywords."

    Proposal:

    Rewrite the above para to read:

    To avoid C++ compilation problems, every use in OMG IDL of a
    C++ keyword as an identifier is mapped into the same name preceded
    by the prefix "cxx." For example, an IDL interface named "try"
    would be named "_cxx_try" when its name is mapped into C++.
    For consistency, this rule also applies to identifiers that
    are derived from IDL identifiers. For example, an IDL interface
    "try" generates the names "_cxx_try_var," "_cxx_try_ptr,"
    and "tc_cxx_try".

  • Reported: CPP 1.1 — Thu, 16 Aug 2001 04:00 GMT
  • Disposition: Resolved — CPP 1.2
  • Disposition Summary:

    accept the suggested proposal

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Local interfaces issue 1

  • Key: CPP12-8
  • Legacy Issue Number: 4496
  • Status: closed  
  • Source: Borland Software Corporation ( Vijaykumar Natarajan)
  • Summary:

    The current specification of the local mapping requires the
    implementation to enforce the "localness" of the object. This was very
    similar to the (old) java mapping. The inheritance heirarchy is as
    follows

    CORBA::LocalObject : CORBA::Object

    abstract MyLocalObject : CORBA::Object

    MyLocalObjectImpl : MyLocalObject, CORBA::LocalObject

    The problem here is that there is no way for the ORB or the code
    generators to enforce the last inheritance. And I am not even sure how
    an ORB can detect the following case

    MyLocalObjectImpl : MyLocalObject

    which I suspect would be a very common error.

    Proposal:

    Fix the mapping to have the following heirarchy.

    CORBA::LocalObject : CORBA::Object

    abstract MyLocalObject : CORBA::LocalObject <===== Difference is here

    MyLocalObjectImpl : MyLocalObject <== and here

    Now an _is_a("IDL:omg.org/CORBA/LocalObject:1.0") is guaranteed to give
    a correct answer and it is enforced by the IDL compilers.

    This is also backward source compatible.

  • Reported: CPP 1.1 — Tue, 14 Aug 2001 04:00 GMT
  • Disposition: Resolved — CPP 1.2
  • Disposition Summary:

    see issue #4160 (the proposed resolution rejects this suggestion)

  • Updated: Fri, 6 Mar 2015 20:57 GMT

implementing local interfaces in C++

  • Key: CPP12-16
  • Legacy Issue Number: 5579
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    There seems to be only two choices:

    1. Accept that changing interfaces to local breaks old code that implemented
    POA interfaces using servants. Not wonderful, but I can live with it, since
    the source code changes are evident and fixed in a straightforward fashion.

    2. Try to come up with a scheme where local objects can be implemented either
    by using LocalObject or by the traditional servant route. This is more
    specification work, but cleaner, and I an live with it too.

    While we are at it, we should make sure that any other CORBA 3.0 changes are
    properly reflected in the C++ mapping as well.

  • Reported: CPP 1.1 — Fri, 9 Aug 2002 04:00 GMT
  • Disposition: Resolved — CPP 1.2
  • Disposition Summary:

    see proposed resolution for issue #4160

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Initialized T_var?

  • Key: CPP12-15
  • Legacy Issue Number: 5578
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    a discussion in comp.object.corba pointed out the difficulty
    of testing whether a T_var has been initialized. There is
    no _is_null() member function or some such. As a result,
    calling operator->() appears to be the only way to test
    whether a T_var is initialized:

    if (T_var.operator->())
    // It's initialized...

    Not exactly elegant, but workable. However, the following
    words in the spec get in the way:

    "The overloaded operator-> returns the T* held by the T_var,
    but retains ownership of it. Compliant applications may not
    call this function unless the T_var has been initialized with a
    valid non-null T* or T_var."

    These words forbid me to call operator->() until after the
    T_var has been initialized, meaning that there is no portable
    and compliant way to test whether a T_var is nil. I think
    what was meant here is that

    "Compliant applications may not *dereference the return value
    of this function* unless the T_var has been initialized with a
    valid non-null T* or T_var."

    BTW – using operator->() to test for null is a bit obscure.
    We could add a _is_null() member to T_var for this. But,
    given the versioning confustion we'd cause and the fact
    that adding the member provides only marginal benefit,
    I think it may be better to leave things as they are. (But
    we should fix the description of operator->(), of course.)

  • Reported: CPP 1.1 — Tue, 20 Aug 2002 04:00 GMT
  • Disposition: Resolved — CPP 1.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Missin operations in Object interface, ptc/01-06-07

  • Key: CPP12-14
  • Legacy Issue Number: 4871
  • Status: closed  
  • Source: seimet.de ( Uwe Seimet)
  • Summary:

    in ptc/01-06-07, 1.34.1, several operations seem to be missing in the Object
    interface, e. g.

    get_client_policy()
    get_policy_overrides()
    validate_connection()

    These are also missing in the Object C++ class, 1.34.2. create_request2() is
    also missing here.

  • Reported: CPP 1.1 — Wed, 27 Feb 2002 05:00 GMT
  • Disposition: Resolved — CPP 1.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:57 GMT

String_var and C++ implicit conversions

  • Key: CPP12-19
  • Legacy Issue Number: 5807
  • Status: closed  
  • Source: Anonymous
  • Summary:

    This e-mail addresses three CORBA C++ Revision Task Force issues:
    3796
    3797
    4530
    It also addresses section 6.10.2 of your book, "Advanced CORBA
    Programming with C++" ((C) 1999).

    Starting with 6.10.2 of your book, p. 164, you show an example where a
    CORBA::String_var is implicitly converted to 'const char *' in a
    function call, with the conversion operators as defined on p. 157 (sect.
    6.10).

    However, the C++ language won't choose the 'const char *() const'
    operator as you (and I) would think. Instead, since the String_var
    isn't const in the call's scope, the 'char *()' (i.e., non-const)
    operator is chosen.

    Aparently, the conversion path
    String_var -> char * -> const char *
    Is considered "better" than the conversion path we'd expect, namely
    String_var -> const String_var -> const char *

    Further, updating String_var with the resolutions of Issues 3796 and
    3797 (as found in http://cgi.omg.org/issues/cxx_revision.html), namely
    removing 'operator char *()' and adding 'operator char *&()' now leads
    to the conversion path
    String_var -> char *& -> const char *
    The 'const char *' operator is still bypassed, and with 'operator char
    *&()' in the picture, it seems trouble is more likely.

    For reference, take a look at the USENET newsgroup comp.std.c++, the
    thread of "Subject: Implicit conversion of g++", starting 2000/03/02 (I
    know that long URL's don't e-mail well, but...
    http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&threadm=p6qr
    9dsxi04.fsf%40informatik.hu-berlin.de&rnum=1&prev=/groups%3Fhl%3Den%26lr
    %3D%26ie%3DUTF-8%26oe%3DUTF-8%26selm%3Dp6qr9dsxi04.fsf%2540informatik.hu
    -berlin.de)

    For reference, I've attached a little source-code. Imagine that the
    class is String_var. This program produces identical results under two
    compilers:

    • Microsoft's Visual C++ 6.0 (SP3)
    • CygWin's gcc v3.2

    Though the String_var implementations I've seen aren't adversely
    affected, I wanted to bring this compiler behavior to your attention. I
    think the CORBA & C++ folks should eventually know, too, since CORBA and
    C++ seem to miss each other here.

  • Reported: CPP 1.1 — Fri, 10 Jan 2003 05:00 GMT
  • Disposition: Resolved — CPP 1.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:57 GMT

need mapping for get_orb and get_component on CORBA::Object

  • Key: CPP12-18
  • Legacy Issue Number: 5784
  • Status: closed  
  • Source: Thematix Partners LLC ( Jishnu Mukerji [X] (Inactive))
  • Summary:

    The Core issue that adds get_orb to CORBA::Object has passed. It would
    be good if you were to initiate an issue in the C++ RTF to make the
    necessary changes in the C++ pseudo-object mapping section for Object to
    incorporate this new operation. While you are at it you might also wish
    to throw in the get_component operation, which was added by the
    Components specification, and is yet to get into the C++ mapping chapter
    (I think).

    These might be way easier tor esolve than some of the weightier issues
    that you have been struggling with, since these have very
    straightforward and non-controversial resolutions

  • Reported: CPP 1.1 — Tue, 10 Dec 2002 05:00 GMT
  • Disposition: Resolved — CPP 1.2
  • Disposition Summary:

    same as proposed resolution for issue #4871

  • Updated: Fri, 6 Mar 2015 20:57 GMT

No Mapping for Local interface in C++

  • Key: CPP12-17
  • Legacy Issue Number: 5580
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The bit that defines the mapping of local
    interfaces to C++ seems to be missing from the specification (ptc/99-10-09 has a change
    > based on the CCM specification, which does not appear in
    > ptc/01-06-07. )

  • Reported: CPP 1.1 — Fri, 9 Aug 2002 04:00 GMT
  • Disposition: Resolved — CPP 1.2
  • Disposition Summary:

    same as proposed resolution for issue #4160

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Bug on _var references

  • Key: CPP12-11
  • Legacy Issue Number: 4530
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    he spec shows on page 1-13:

    class A_var {
    public:
    // ...
    operator const A_ptr&() const

    { return ptr_; }
    operator A_ptr&() { return ptr_; }

    // ...
    };

    The conversion operator is overloaded for const and non-const.

    Now, two issues here:

    1) It seems that "const A_ptr &" as the return type for the
    first operator is wrong because it really means
    "A * const", not "const A *". So, if anything, I think it
    would have to be written as

    operator const A * &() const

    { return ptr_; }

    2) But why provide a const version of the conversion operator
    at all? Object references are never passed with a const
    qualifier, so why provide this conversion operator? I think
    it could simply be deleted without affecting anything.

    Proposal: Delete the const version of the conversion operator.

    Opinions?

  • Reported: CPP 1.1 — Wed, 22 Aug 2001 04:00 GMT
  • Disposition: Resolved — CPP 1.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Dangling reference

  • Key: CPP12-10
  • Legacy Issue Number: 4499
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    On page 1-3 of the mapping, it says:

    For more information about CORBA compliance, refer to the
    Preface, "Definition of CORBA Compliance" on page viii.

    That preface hasn't existed for a long time now.

    Proposal:

    Strike this sentence.

  • Reported: CPP 1.1 — Thu, 16 Aug 2001 04:00 GMT
  • Disposition: Resolved — CPP 1.2
  • Disposition Summary:

    Strike this sentence

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Structure member ordering

  • Key: CPP12-7
  • Legacy Issue Number: 4340
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    The C++ mapping says in section 1.10:

    An OMG IDL struct maps to C++ struct, with each OMG IDL struct
    member mapped to a corresponding member of the C++ struct.

    This doesn't say that the order of the struct members in C++ must be the
    same as in the IDL. Without that guarantee, code that compares pointers to
    members is non-portable. We need a requirement to preserve the order here.

  • Reported: CPP 1.1 — Wed, 6 Jun 2001 04:00 GMT
  • Disposition: Resolved — CPP 1.2
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:57 GMT

semantics of valuetype _downcast operation unclear

  • Key: CPP12-6
  • Legacy Issue Number: 4270
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    The definition of the _downcast operation generated for valuetypes is
    unclear about whether it increments the reference count of the valuetype
    before returning the downcasted pointer. I assume by the fact that it
    is called _downcast rather than _narrow that it should not increment the
    reference count.

    Proposal:

    Add the following text to the end of the last paragraph in 1.17.3:

    "The _downcast function does not increment the reference count of the
    valuetype."

  • Reported: CPP 1.1 — Fri, 13 Apr 2001 04:00 GMT
  • Disposition: Resolved — CPP 1.2
  • Disposition Summary:

    Add the proposed text

  • Updated: Fri, 6 Mar 2015 20:57 GMT

ValueRefCountBase::_add_ref

  • Key: CPP12-13
  • Legacy Issue Number: 4610
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    PortableServer::ValueRefCountBase derives from both CORBA::ValueBase and
    PortableServer::ServantBase. This create a problem because ValueBase
    contains

    virtual ValueBase * _add_ref() = 0;

    but ServantBase contains

    virtual void _add_ref();

    The easy fix would appear to be to change the ValueBase version to return void.

    Anyone see a problem with this? (I don't understand why the ValueBase version
    currently returns a ValueBase * anyway. Any subtle reason for this that I
    am not aware of?)

  • Reported: CPP 1.1 — Tue, 9 Oct 2001 04:00 GMT
  • Disposition: Resolved — CPP 1.2
  • Disposition Summary:

    Change _add_ref() on ValueBase to return void.

  • Updated: Fri, 6 Mar 2015 20:57 GMT

C++ mapping for CORBA::LocalObject

  • Key: CPP12-12
  • Legacy Issue Number: 4545
  • Status: closed  
  • Source: Dell Technologies ( Ted Burghart)
  • Summary:

    In the latest C++ mapping including RTF report changes (ptc/01-06-07) I see no mention of a mapping for CORBA::LocalObject. CORBA 2.4.x 3.7.6.2 states that this is to be specified in each language mapping.

    How does it get mapped and, in particular, what are it's memory management semantics and relevant methods?

  • Reported: CPP 1.1 — Wed, 29 Aug 2001 04:00 GMT
  • Disposition: Resolved — CPP 1.2
  • Disposition Summary:

    same as proposed resolution for issue #4160

  • Updated: Fri, 6 Mar 2015 20:57 GMT

LocalObject

  • Key: CPP12-3
  • Legacy Issue Number: 4172
  • Status: closed  
  • Source: IONA ( Matthew Newhook)
  • Summary:

    From orbos/99-07-01 (is there a more up-to-date version with the C++
    mapping?)

    namespace CORBA
    {
    class LocalObject
    : public virtual Object

    { protected: LocalObject(); ~LocalObject(); public: virtual void _add_ref(); virtual void _remove_ref(); // pseudo operations not shown... }

    ;
    };

    Member functions and any data members needed to implement the Object
    pseudo-operations and any other ORB support functions must also be
    supplied but are not shown.

    _add_ref

    The _add_ref member function is called when the reference is duplicated.
    A default implementation is provided that does nothing. A derived
    implementation may use this operation to maintain a reference count.

    _remove_ref

    The _remove_ref member function is called when the reference is
    released. A default implementation is provided that does nothing. A
    derived implementation may use this operation to maintain a reference
    count, and delete the object when the count becomes zero.

    This implies that by default a LocalObject will not be reference
    counted. That seems counter-intuitive. What was the intention here? It
    seems that every application I can think of will want reference counted
    local objects – however, to get this at present the application developer
    either has to implement the reference counting themselves or inherit
    off some proprietary interface.

  • Reported: CPP 1.1 — Tue, 23 Jan 2001 05:00 GMT
  • Disposition: Resolved — CPP 1.2
  • Disposition Summary:

    same as issue #4160

  • Updated: Fri, 6 Mar 2015 20:57 GMT

mapping of local interfaces

  • Key: CPP12-2
  • Legacy Issue Number: 4160
  • Status: closed  
  • Source: AdNovum Informatik ( Stefan Wengi)
  • Summary:

    I took a closer look at orbos/99-07-01 to see how I'd have to implement
    local objects.
    Several questions came to my mind:

    1)
    what happens if you invoke CORBA::Object::_duplicate on a LocalObject?

    • does it call _add_ref on the local object (as the spec seems to say in
      4.1.2)?
    • is it allowed to return a copy of the object?

    2)
    how is memory handling done on existing interfaces?

    4.1.5 defines a list of interfaces that are changed to local interfaces
    e.g. CORBA::Current. How are they supposed to support proper memory
    handling when the default implementations of _add_ref/_remove_ref do
    nothing?

    3)
    local interfaces can be implemented by the application programmer, e.g.
    PortableInterceptors.

    • what happens if my _duplicate operation on CORBA::Object creates a
      copy (which is legal) and my implemenation of the local interface
      contains some state?

    This mapping creates more problems than it solves.
    It breaks at least one of the basic rules of OO design: base classes
    must not know about subclasses.
    Also disabling some methods that are valid on CORBA::Object (e.g. is_a)
    is a hint for bad design.
    Why not take the same interface 'inheritance' approach as with value
    types?

  • Reported: CPP 1.1 — Thu, 18 Jan 2001 05:00 GMT
  • Disposition: Resolved — CPP 1.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:57 GMT

How to create a local object reference?

  • Key: CPP12-5
  • Legacy Issue Number: 4245
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    The text added by the CCM spec that describes LocalObject has no
    information on how to portably create a local object reference. Since
    we have ORB services, like the Security or Transaction service which
    must create local object references, and since we have a goal that these
    services should be portable as source code between ORBs, we need a
    portable way to create a local object reference.

    Proposal:

    Add a static _create_reference() member function to local object
    interface classes:

    // IDL
    local interface I

    { ... }

    ;

    // C++

    ... I_ptr;

    class I : ...

    { public: I_ptr _create_reference(I *); }

    ;

    A programmer can then create a new local object reference portably:

    class MyI : public I, public CORBA::LocalObject

    { ... }

    ;

    I_var new_i = I::_create_reference(new MyI());

  • Reported: CPP 1.1 — Fri, 30 Mar 2001 05:00 GMT
  • Disposition: Resolved — CPP 1.2
  • Disposition Summary:

    same as issue #4160

  • Updated: Fri, 6 Mar 2015 20:57 GMT

CORBA::Object & LocalObject

  • Key: CPP12-4
  • Legacy Issue Number: 4186
  • Status: closed  
  • Source: IONA ( Matthew Newhook)
  • Summary:

    Is the definition of CORBA::Object given the C++ specificaton intended
    to be normative? If so then the C++ mapping given in the components
    spec won't work since it's clear that LocalObject is supposed to
    override the various methods provided on CORBA::Object.

  • Reported: CPP 1.1 — Wed, 24 Jan 2001 05:00 GMT
  • Disposition: Resolved — CPP 1.2
  • Disposition Summary:

    same as issue #4160

  • Updated: Fri, 6 Mar 2015 20:57 GMT