C++ Language Mapping Avatar
  1. OMG Specification

C++ Language Mapping — Closed Issues

  • Acronym: CPP
  • Issues Count: 131
  • Description: Issues resolved by a task force and approved by Board
Closed All
Issues resolved by a task force and approved by Board

Issues Summary

Key Issue Reported Fixed Disposition Status
CPP11-266 20.17.9 Valuetype Inheritance CPP 1.0 CPP 1.1 Resolved closed
CPP11-265 sequence max < length CPP 1.0b2 CPP 1.1 Resolved closed
CPP11-261 Add _narrow() operation to each POA servant CPP 1.0b2 CPP 1.1 Resolved closed
CPP11-258 freebuf and destruction of elements CPP 1.0b1 CPP 1.1 Closed; No Change closed
CPP11-256 C++: ostream insertion CPP 1.0 CPP 1.1 Duplicate or Merged closed
CPP11-255 _var types for fixed-length underlying types CPP 1.0 CPP 1.1 Resolved closed
CPP11-254 string sequences and empty strings CPP 1.0 CPP 1.1 Resolved closed
CPP11-253 Incorrect types for type-safe Any extraction CPP 1.0 CPP 1.1 Resolved closed
CPP11-136 Unknown parts of an IOR and interoperability CORBA 2.2 CPP 1.1 Resolved closed
CPP11-123 Typographical problems CPP 1.0 CPP 1.1 Resolved closed
CPP11-122 Supporting typedefs for _var types? CPP 1.0b1 CPP 1.1 Duplicate or Merged closed
CPP11-121 Any::to_abstract_base needs statement about memory management CPP 1.0 CPP 1.1 Resolved closed
CPP11-120 allocbuf() for bounded sequences? CPP 1.0 CPP 1.1 Resolved closed
CPP11-119 Extraction operator for system exceptions? CPP 1.0 CPP 1.1 Resolved closed
CPP11-118 Need Any::to_value operation? CPP 1.0 CPP 1.1 Resolved closed
CPP11-117 4 of 4 issues with Abstract interfaces CPP 1.0 CPP 1.1 Resolved closed
CPP11-116 don't understand the last paragraph of 1.18.2: CPP 1.0 CPP 1.1 Resolved closed
CPP11-115 2 of4 issues with Abstract interfaces CPP 1.0 CPP 1.1 Resolved closed
CPP11-114 1 of 4 issues with Abstract interfaces CPP 1.0 CPP 1.1 Resolved closed
CPP11-113 NamedValue not only an NVList element CPP 1.0 CPP 1.1 Resolved closed
CPP11-112 Standard object operations & DynamicImplementation CPP 1.0 CPP 1.1 Resolved closed
CPP11-111 Inconsistency in 1.7 and 1.9 of mapping CPP 1.0 CPP 1.1 Resolved closed
CPP11-110 Fixed::round and truncate issue CPP 1.0 CPP 1.1 Resolved closed
CPP11-109 Fixed(const char *) constructor problem CPP 1.0 CPP 1.1 Resolved closed
CPP11-108 Editorial typo in Section 1.36.3 of C++ mapping CPP 1.0 CPP 1.1 Resolved closed
CPP11-107 Object _out class copy constructor & assignment op wrong CPP 1.0 CPP 1.1 Resolved closed
CPP11-106 CORBA 2.3 Editorial problem in TypeCode CPP 1.0 CPP 1.1 Resolved closed
CPP11-105 Unary operators for Fixed class have wrong return types CPP 1.0 CPP 1.1 Resolved closed
CPP11-104 Exception constructors should be protected CPP 1.0 CPP 1.1 Resolved closed
CPP11-103 Exception::_raise() should be const? CPP 1.0 CPP 1.1 Resolved closed
CPP11-102 String extractor semantics undefined? CPP 1.0 CPP 1.1 Resolved closed
CPP11-101 Contents of string members (02) CPP 1.0 CPP 1.1 Resolved closed
CPP11-100 Contents of string members (01) CPP 1.0 CPP 1.1 Resolved closed
CPP11-99 Union string member mapping defect? CPP 1.0 CPP 1.1 Resolved closed
CPP11-98 Two obvious typos in the C++ mapping for OBV (docs/formal/99-07-41.pdf) CPP 1.0 CPP 1.1 Resolved closed
CPP11-97 operator>> for String_var CPP 1.0 CPP 1.1 Resolved closed
CPP11-96 Valuetypes and _out classes in C++ mapping CPP 1.0 CPP 1.1 Resolved closed
CPP11-95 Valuetypes and arbitrary graphs CPP 1.0 CPP 1.1 Resolved closed
CPP11-94 Factories for StringValue and WStringValue CPP 1.0 CPP 1.1 Resolved closed
CPP11-93 Sequences and get_buffer() CPP 1.0 CPP 1.1 Resolved closed
CPP11-92 Valuetype argument passing CPP 1.0 CPP 1.1 Resolved closed
CPP11-91 Add AbstractBase base type to IDL language? CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-90 narrow abstract interface class to concrete object? CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-89 generate concrete classes and factories for valuetypes without initializer CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-88 add a _var type for each servant type CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-87 tie doesn"t do ref counting CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-86 Misleading text for DSI invoke() and _primary_interface() CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-85 Any missing LongLong operators, etc? CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-84 _primary_interface CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-83 The C++ mapping for valuetype _narrow should not _add_ref CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-82 sequence allocbuf parameter != 0 CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-81 Passing Fixed to operations CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-80 Comparison operators for Fixed CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-79 Parameter passing rules for ValueFactory CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-78 C++ language mapping minor editorial revision CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-77 Section 5.3.6.3 Value Factories CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-76 Problems with deactivate_object() CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-75 Do POA servant classes need to use virtual inheritance? CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-74 Spec is too verse in defining the T_var types for fixed length CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-73 Spec does not mention the existance of an Any_out class CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-72 _var & _out types problems (01) CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-71 Missing operators in orbos/98-01-11 CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-70 C++ Sequence mapping Question CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-69 TypeCode_ptr base_typecode(TypeCode_ptr tc) CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-68 C++ mapping for fixed is broken (02) CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-67 No conversion defined from a B_var to an A_ptr CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-66 ServantBase mappings CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-65 C and C++ Mapping question CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-64 inout strings modifiable? CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-63 Multiple inheritance of C++ Servants is ill-defined CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-62 C++ mapping of servants may result in ambigous run-time behavior CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-61 Implementation problem with policy objects using root POA CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-60 sec. 18.1.2: explicit information on _this() is missing CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-59 Blocking semantics of get_next_response not well specified CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-58 Section 16.2, Section 16.6: editorial CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-57 IDL from Ennvironment has invalid attribute CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-56 Interface definition must be standardized CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-55 String_var and Any_var are missing the T_ptr definition CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-54 const method qualification should be removed CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-53 Legal IDL cannot map to C++ CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-52 Double underscore identifier mapping CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-51 [q] intf name == op name CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-50 u++ binding for ServerRequest pseudo object CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-49 C++ semantics vs. IDL semantics CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-48 ANy release flag and operator CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-47 operator<< for ostreams and Exceptions CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-46 make String_var reference but not adopt CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-45 buffer classes for sequences CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-44 TypeCode for each basic and IDL defined types CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-43 Exception id for each exception type CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-42 Accessor for exception id CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-41 Accessors for the Any release flag CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-40 Constructor taking discriminant as argument CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-39 Name field for SystemExceptions CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-38 union accessors require temporaries CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-37 accessor members for structs CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-36 allocbuf and initialization of elements CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-35 C++ namespaces CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-34 Allocated storage for out and return strings CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-33 accessor function on SystemException CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-32 Mapping for IDL context CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-31 union accessors CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-30 callee-allocated storage modification CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-29 anonymus types CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-28 void* from Any for constructed types CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-27 handling void* from Any CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-26 Pointers vs. values CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-25 Storage ownership issue CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-24 Global functions vs. T_var namespace CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-23 Array_forany CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-22 Array slice example CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-21 Semantics of sequence length() operation CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-20 Copying of out parameters CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-19 C vs. C++ coding style CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-18 Autoextension of sequences CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-17 Implementation description CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-16 Detection of initialization of T_var CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-15 Assignment to T_var CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-14 example incorrect? CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-13 Levels of portability conformance requested CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-12 Representation of void* returned from ANY CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-11 TypeCode/Value mismatch in ANY CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-10 illegal union access when discriminator is wrong CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-9 _ptr member accessors for string and objref CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-8 Pseudo objects for DSI CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-7 Identifier conflicts resulting from the language mapping CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-6 interface mapping CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-5 Inconsistent interfaces for the operation pairs *duplicate* and CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-4 Testing exceptions CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-3 Passing of object reference in pointers CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-2 Fixed structs CPP 1.0b1 CPP 1.1 Resolved closed

Issues Descriptions

20.17.9 Valuetype Inheritance

  • Key: CPP11-266
  • Legacy Issue Number: 2489
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: For an IDL valuetype derived from other valuetypes or that supports
    interface types, several C++ inheritance scenarios are possible:
    ...

    • Interface classes supported by the IDL valuetype are not inherited. Instead,
      the operations on the interface (and base interfaces, if any) are mapped to
      pure virtual functions in the generated C++ base value class. In addition to
      this abstract base value class and the OBV_ class, the IDL compiler generates
      a POA skeleton for this value type; the name of this skeleton is formed by
      prepending the string "POA_" to the fully-scoped name of the valuetype. The
      base value class and the POA skeleton of the interface type are public virtual
      base classes of this skeleton.

    Consider this example:

    // IDL
    interface I {};
    abstract valuetype A supports I {};
    valuetype B : A {};

    Is a POA skeleton generated for A? Is one generated for B?

  • Reported: CPP 1.0 — Thu, 25 Feb 1999 05:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:
  • Updated: Sun, 8 Mar 2015 15:33 GMT

sequence max < length

  • Key: CPP11-265
  • Legacy Issue Number: 1947
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: What happens when you pass a maximum argument that is less than the length
    argument to the "T* data" constructor of an unbounded sequence? Should the
    length argument be treated as equal to the max argument, or should an
    implementation-defined error (such as an assert) be allowed?

    What happens if you pass a null pointer for the buffer argument to the "T*
    data" constructor of a sequence? Should the constructor create the sequence
    as if it was created with the default constructor, or should an
    implementation-defined error (such as an assert) be allowed? Should a null
    pointer argument be allowed if the maximum and length arguments are zero?

  • Reported: CPP 1.0b2 — Sun, 13 Sep 1998 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 15:33 GMT

Add _narrow() operation to each POA servant

  • Key: CPP11-261
  • Legacy Issue Number: 1534
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: 1. The C++ spec requires that all POA servant classes derive from
    PortableServer::ServantBase as a virtual base class. For C++
    environments without RTTI, it is then impossible for the programmer to
    narrow a servant received from the POA via reference_to_servant() or
    id_to_servant() back to the programmer"s specific servant class.

    Proposal: Add a _narrow() operation to each POA servant class in the
    same fashion that _narrow() operations are defined for exception
    classes:

    // IDL
    interface A { };

    // C++
    class POA_A : public virtual PortableServer::ServantBase

    { public: POA_A *_narrow(PortableServer::Servant); }

    ;

    The _narrow() operation will return a valid pointer if the servant isa
    POA_A, otherwise it returns 0.

  • Reported: CPP 1.0b2 — Thu, 18 Jun 1998 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    :ServantBase as a virtual base class. For C++

  • Updated: Sun, 8 Mar 2015 15:33 GMT

freebuf and destruction of elements

  • Key: CPP11-258
  • Legacy Issue Number: 242
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Sec 3.13.2 para 25 describes freebuf. It doesn"t specify if storage associated with each element is released, i.e deep-free. Sun prefers that freebuf deep-free...

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Closed; No Change — CPP 1.1
  • Disposition Summary:

    Close no change. This issue is already addressed in the CORBA 2.3 specification.

  • Updated: Sat, 7 Mar 2015 02:09 GMT

C++: ostream insertion

  • Key: CPP11-256
  • Legacy Issue Number: 3165
  • Status: closed  
  • Source: UBS ( Hans Kneubuehl)
  • Summary:

    Many ORBs provide ostream insertion for exceptions as an extension to C++
    mapping. Typically, applications are required to use them (there is not really
    a usable alternative) to write code in the following style:

    try

    { // do some operations }

    catch (CORBA::Exception & ex)

    { cerr << "some operation failed: " << ex << endl; }

    This breaks portability as not all ORBs provide the functionality in the same
    way. Therefore ostream insertion should be part of the standard.

  • Reported: CPP 1.0 — Thu, 23 Dec 1999 05:00 GMT
  • Disposition: Duplicate or Merged — CPP 1.1
  • Disposition Summary:

    closed issue, duplicate of 266

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

_var types for fixed-length underlying types

  • Key: CPP11-255
  • Legacy Issue Number: 3101
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    the spec currently is extremely vague about how _var types for fixed-length
    underlying types are supposed to work. The only words are:

    The T_var types are also produced for fixed-length structured
    types for reasons of consistency. These types have the same
    semantics as T_var types for variable-length types. This allows
    applications to be coded in terms of T_var types regardless of
    whether the underlying types are fixed- or variable-length.

    This has long been a source of confusion to me. In particular, it doesn't
    answer questions such as

    • Can a _var for a fixed-length type be initialized with a pointer
      to the fixed-length type? If so, does the _var adopt it?
    • Can a _var for fixed-length type be initialized with a value?
    • What does assignment between _vars for fixed-length types do?
    • Does the _var for a fixed-length type work like a reference
      and remain bound to the same block of memory?
    • What does default-initialization of such a _var do?
    • etc, etc.
  • Reported: CPP 1.0 — Thu, 9 Dec 1999 05:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    duplicate of issdue 1521...close issue

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

string sequences and empty strings

  • Key: CPP11-254
  • Legacy Issue Number: 2525
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: For string sequences, new string elements, that are created when the
    sequence length is increased, should be initialized to the empty string.

    I therefore raise this herewith as an official issue.

    I also don"t think it makes sense to vote on issue 2234 before we
    decided on the issue above. As I already pointed out, I raised issue
    2234 in the believe that the spec already says that new string sequence
    elements are initialized as empty string. But this assumption was wrong.

  • Reported: CPP 1.0 — Wed, 10 Mar 1999 05:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    closed and fixed

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

Incorrect types for type-safe Any extraction

  • Key: CPP11-253
  • Legacy Issue Number: 2463
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The first bullet point at the bottom of page 20-61 is incorrect. It
    states that Boolean, Char, and Octet can be extracted using >>=. However,
    on page 20-66, the mapping requires a compile-time error for attempts
    to extract these types with >>=.

    Proposal:

    Delete Boolean, Char, and Octet from teh list of types at
    the bottom of page 20-61.

  • Reported: CPP 1.0 — Mon, 22 Feb 1999 05:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    No Data Available

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

Unknown parts of an IOR and interoperability

  • Key: CPP11-136
  • Legacy Issue Number: 2457
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: There is currently a heated discussion in comp.object.corba about
    interoperability (Subject: Naming Service Interoperability).

    In a nutshell, the argument is about whether, if I send an object reference
    created by ORB A as a parameter to ORB B, whether or not ORB B is

    a) obliged to accept that reference as a valid parameter

    b) obliged to return me the same reference I sent (in the sense
    that the reference is functionally equivalent) when it returns
    that reference as a parameter to me

    c) obliged to preserve the contents of the reference if it goes
    though a cycle of object_to_string/string_to_object in ORB B.

    Now, my argument in this thread is that if an ORB doesn"t behave in line
    with the above three points, interoperability is completely lost because
    I could never be guaranteed that I can, for example, expect to be able
    to store an IOR in a Naming Service and have that work.

  • Reported: CORBA 2.2 — Fri, 19 Feb 1999 05:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    issue split into issues 3234 and 3235

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

Typographical problems

  • Key: CPP11-123
  • Legacy Issue Number: 5450
  • Status: closed  
  • Source: Boeing Australia ( Bruce McIntosh)
  • Summary:

    Name: Bruce McIntosh
    Company: Boeing Australia
    mailFrom: bruce.mcintosh@boeing.com
    Notification: Yes
    Specification: C++ Language Mapping
    Section: 1.36.2
    FormalNumber: ptc/01-06-07
    Version: Proposed Available Revision
    RevisionDate: 01/26/2002
    Page: 1-136
    The example given has a couple of small typographical problems: (1) the function signature specifies a void return type, but returns a Foo* (2) the function returns "foo_servant->this;" which I think should be "return foo_servant->_this();"

    Perhaps the example should read:

    Foo* some_function (/.../)

    { Servant_var<Foo_impl> foo_servant = new Foo_impl; foo_servant->do_something(); // might throw... some_poa->activate_object_with_id(...); return foo_servant->_this(); }
  • Reported: CPP 1.0 — Sun, 30 Jun 2002 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Updated the example code as suggested

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

Supporting typedefs for _var types?

  • Key: CPP11-122
  • Legacy Issue Number: 3563
  • Status: closed  
  • 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.0b1 — Mon, 1 Mar 1999 05:00 GMT
  • Disposition: Duplicate or Merged — CPP 1.1
  • Disposition Summary:

    No Data Available

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

Any::to_abstract_base needs statement about memory management

  • Key: CPP11-121
  • Legacy Issue Number: 3113
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    The description of Any::to_abstract_base does not have any information
    about its memory managment implications. It should have the equivalent
    semantics to Any::to_object, and require the resulting reference to be
    released by the caller.

  • Reported: CPP 1.0 — Sun, 12 Dec 1999 05:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    closed/resolved

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

allocbuf() for bounded sequences?

  • Key: CPP11-120
  • Legacy Issue Number: 3110
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    What should allocbuf() for a bounded sequence return if I ask for more
    elements than the sequence bound? The spec doesn't say. I think it should
    return null in this case.

    Also, what should allocbuf() return if I ask for zero elements?

  • Reported: CPP 1.0 — Sat, 11 Dec 1999 05:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    closed/resolved

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

Extraction operator for system exceptions?

  • Key: CPP11-119
  • Legacy Issue Number: 3103
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    currently it is not possible to pull an exception out of an Any generically,
    that is, I cannot write:

    const CORBA::SystemException * sep;
    CORBA::Any a;

    // assume a contains a system exception...

    a >>= sep;

    Normally, I won't need this. However, it's come up as part of portable
    interceptors. For example, I might want to write an interceptor that
    logs things, including system exceptions. Now, if I have a system exception
    in an Any, the only way to get it out is to successively try to extract
    every possible system exception until I find one that works.

    That's rather tedious. It would be nicer if I could extract a base
    pointer to the actual exception, so I can print the minor number and
    completion status.

    I would like to suggest adding the following extraction operator:

    Boolean operator>>=(const SystemException * &);

  • Reported: CPP 1.0 — Fri, 10 Dec 1999 05:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    closed/resolved

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

Need Any::to_value operation?

  • Key: CPP11-118
  • Legacy Issue Number: 3092
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    Given that we have Any::to_object and Any::to_abstract_base, shouldn't
    there be an Any::to_value_base as well?

  • Reported: CPP 1.0 — Sat, 4 Dec 1999 05:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    closed/resolved

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

4 of 4 issues with Abstract interfaces

  • Key: CPP11-117
  • Legacy Issue Number: 3081
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    4. Is there any merit in adding narrow operations to AbstractBase that
    would allow the programmer to narrow to ValueBase or Object_ptr?

  • Reported: CPP 1.0 — Sat, 4 Dec 1999 05:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    closed/resolved

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

don't understand the last paragraph of 1.18.2:

  • Key: CPP11-116
  • Legacy Issue Number: 3080
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    "Both interfaces that are derived from one or more abstract interfaces,
    and valuetypes that support one or more abstract interfaces support
    implicit widening to the _ptr type for each abstract interface base
    class. Specifically, the T* for valuetype T and the T_ptr type for
    interface type T support implicit widening to the Base_ptr type for
    abstract interface type Base. The only exception to this rule is for
    valuetypes that directly or indirectly support one or more regular
    interface types (see Section 1.17.9, Valuetype Inheritance, on page
    1-83). In these cases, it is the object reference for the valuetype, not
    the pointer to the valuetype, that supports widening to the abstract
    interface base."

    This seems to prohibit widening from a valuetype pointer to an abstract
    interface _ptr if the valuetype happens to support a normal interface.
    I don't understand the restriction. This seems to prohibit the
    programmer making a choice of using value or reference semantics in the
    case of diamond inheritence of an abstract interface:

    // IDL
    abstract interface A {
    };

    interface I : A {
    };

    valuetype V1 : supports A {
    };

    valuetype V2 : supports I {
    };

    This means that I must always pass V2 valuetypes by reference to
    operations expecting an A, and cannot choose to pass V2 valuetypes by
    value instead. Why was this restriction added and what would be the
    problem with relaxing it in this case?

  • Reported: CPP 1.0 — Sat, 4 Dec 1999 05:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    see below

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

2 of4 issues with Abstract interfaces

  • Key: CPP11-115
  • Legacy Issue Number: 3079
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    2. I do not understand this bullet in section 1.18.2:

    "o Inserting an abstract interface reference into a CORBA::Any operates
    polymorphically; either the object reference or valuetype to which the
    abstract interface reference refers is what actually gets inserted into
    the Any. Because abstract interfaces cannot actually be inserted into an
    Any, there is no need for abstract interface extraction operators,
    either. The CORBA::Any::to_abstract_base type allows the contents of an
    Any to be extracted as an AbstractBase if the entity stored in the Any
    is an object reference type or a valuetype directly or indirectly
    derived from the AbstractBase base class. See Section 1.16.6, Widening
    to Abstract Interface, on page 1-62 for details."

    This seems to make no sense. It seems to state that the actual
    reference or valuetype is inserted into the Any, which means that the
    TCKind associated with the any will be tk_objref or tk_value, not
    tk_abstract_interface. This seems to have particularly bad implications
    with the DII & DSI. How does the DII know to encode an abstract
    interface correctly in CDR if the Any it receives doesn't have a
    tk_abstract_interface TypeCode? It also means that an application which
    only knows the abstract interface type must handle the case where the
    Any has a tk_objref or tk_value instead, use Any::to_abstract_interface
    and then a narrow call to get the abstract interface pointer it needs.

    This seems needlessly complex and unnecessary. This bullet should be
    replaced with one that just states that abstract interfaces have
    inserters and extractors generated for them just like normal interfaces.

  • Reported: CPP 1.0 — Sat, 4 Dec 1999 05:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    closed/resolved

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

1 of 4 issues with Abstract interfaces

  • Key: CPP11-114
  • Legacy Issue Number: 3078
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    1. The resolution that we seemed to be converging on for issue 674
    allows programmers to inherit servant implementations like this:

    // IDL

    interface A {
    };

    interface B : A {
    };

    // C++

    class MyA : public virtual POA_A {
    };

    class MyB : public virtual POA_B, public virtual MyA {
    };

    However, this paradigm breaks when using abstract interfaces:

    // IDL
    abstract interface A {
    };

    interface B : A {
    };

    since the spec does not require a POA skeleton be generated for A.

    I think we should change the spec to state that POA skeletons for
    abstract interfaces are generated, but that these skeletons do not
    inherit from ServantBase, and do not contain a _this() member function.
    This will allow inheritence of implementations, even for abstract
    interfaces.

    I considered just having POA_B just inherit directly from the abstract
    class A, but that would allow POA_B skeletons to be widened implicitly
    to an abstract interface pointer (for implementations which define A_ptr
    as A *), and that seems to be too trouble prone. If someone can think
    of a way to do this and prevent implicit widening, then this would be
    better, since it would even allow sharing of implementation between a
    servant and a valutype that both inherit from the same abstract
    interface.

  • Reported: CPP 1.0 — Sat, 4 Dec 1999 05:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    resolved/closed

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

NamedValue not only an NVList element

  • Key: CPP11-113
  • Legacy Issue Number: 2967
  • Status: closed  
  • Source: Hewlett-Packard ( Owen Rees)
  • Summary:

    In formal/99-07-41 section 1.28 "NamedValue" it says "NamedValue is used
    only as an element of NVList, especially in the DII." but this is not
    correct. Note the remark in section 1.33.3 "Differences from C-PIDL" which
    describes other uses: "Added create_named_value, which is required for
    creating NamedValue objects to be used as return value parameters for the
    Object::create_request operation."

  • Reported: CPP 1.0 — Mon, 27 Sep 1999 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    editorial fix, issue closed

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

Standard object operations & DynamicImplementation

  • Key: CPP11-112
  • Legacy Issue Number: 2966
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    The CORBA 2.3 spec needs to make it clear that for dynamic
    implementations, invocations of the standard object operations
    (get_interface, is_a, non_existent) call the virtual functions defined
    in PortableServer::ServantBase, and do not call
    PortableServer::DynamicImplementation::invoke().

  • Reported: CPP 1.0 — Thu, 14 Oct 1999 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    closed/resolved

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

Inconsistency in 1.7 and 1.9 of mapping

  • Key: CPP11-111
  • Legacy Issue Number: 2951
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    Minor editorial issue:

    In Section 1.9.2, "T_out Types":

    class T_out {
    public:
    //...
    T_out(const T_out& p) : ptr_(p.ptr_) {}
    T_out& operator=(const T_out& p)

    { ... }
    };

    In Section 1.7, "Mapping for String Types":

    class String_out {
    public:
    // ...
    String_out(String_out& s) : ptr_(s.ptr_) {}
    String_out& operator=(String_out& s) { ... }

    };

    Note the missing "const" in 1.7. I suspect String_out should do the
    same as T_out and pass const references.

  • Reported: CPP 1.0 — Mon, 11 Oct 1999 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    closed/resolved

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

Fixed::round and truncate issue

  • Key: CPP11-110
  • Legacy Issue Number: 2950
  • Status: closed  
  • Source: Progress Software ( Steve Vinoski)
  • Summary:

    The Fixed::round() and Fixed::truncate() functions do not mention what to
    do if their scale argument is larger than the current scale. I figure they
    shouldn't do anything – for example, "truncating" by making something have
    more digits doesn't seem to make sense. I propose adding the sentence below
    after the sentence reading "The round and truncate functions convert a
    fixed value to a new value with the specified scale." (page 23-32 of
    ptc/99-03-04):

    If the new scale is equal to or larger than the new scale, no rounding or
    truncation is performed and the result is equal to the target object.

  • Reported: CPP 1.0 — Wed, 29 Sep 1999 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    closed/resolved

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

Fixed(const char *) constructor problem

  • Key: CPP11-109
  • Legacy Issue Number: 2949
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    The CORBA 2.3 C++ spec says (1.11):

    "The Fixed(char*) constructor converts a string representation of a
    fixed-point literal into a real fixed-point value, with the trailing 'd'
    or 'D' optional."

    However, the CORBA 2.3 spec for a fixed point literal says (3.2.5.5):

    "A fixed-point decimal literal consists of an integer part, a decimal
    point, a fraction part and a d or D. The integer and fraction parts both
    consist of a sequence of decimal (base 10) digits. Either the integer
    part or the fraction part (but not both) may be missing; the decimal
    point (but not the letter d (or D)) may be missing."

    This means that the following call is illegal:

    CORBA::Fixed f("-1.0");

    Even though this can be rewritten (legally) as:

    CORBA::Fixed f(-CORBA::Fixed("1.0"));

    I think it would be a good idea change the definition of the constructor
    to also allow an optional sign (+ or -).

  • Reported: CPP 1.0 — Fri, 24 Sep 1999 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    closed/resolved

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

Editorial typo in Section 1.36.3 of C++ mapping

  • Key: CPP11-108
  • Legacy Issue Number: 2948
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    The code example has a "ServantBaseBase_var".

  • Reported: CPP 1.0 — Wed, 13 Oct 1999 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    closed, editorial fix

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

Object _out class copy constructor & assignment op wrong

  • Key: CPP11-107
  • Legacy Issue Number: 2947
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    Issue 1776 was supposed to change all T_out classes so that their copy
    constructor and assignment operators took a "const T_out &". The _out
    class in 1.3.6 didn't get updated with this change.

  • Reported: CPP 1.0 — Mon, 18 Oct 1999 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    closed/resolved

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

CORBA 2.3 Editorial problem in TypeCode

  • Key: CPP11-106
  • Legacy Issue Number: 2946
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    Sections 1.32.2 and 1.41.20 have TypeCode::type_modifier() returning a
    ValuetypeModifier. It should be ValueModifier instead.

  • Reported: CPP 1.0 — Thu, 21 Oct 1999 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    editorial fix...isssue closed

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

Unary operators for Fixed class have wrong return types

  • Key: CPP11-105
  • Legacy Issue Number: 2902
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    Some of the unary operators for the Fixed class have the wrong return
    type:

  • Reported: CPP 1.0 — Mon, 20 Sep 1999 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close no change. This issue is already addressed in the CORBA 2.3 specification.

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

Exception constructors should be protected

  • Key: CPP11-104
  • Legacy Issue Number: 2897
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    The constructors for CORBA::Exception, CORBA::SystemException and
    CORBA::UserException should be protected, not public, since there is no
    reason for a direct instance of these classes ever to be instantiated.

  • Reported: CPP 1.0 — Fri, 15 Oct 1999 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close no change. Base exception classes are abstract, so this change is not necessary.

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

Exception::_raise() should be const?

  • Key: CPP11-103
  • Legacy Issue Number: 2895
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: There is no reason that the _raise() function for CORBA::Exception
    should not be const. We should change it"s signature to:

    class Exception

    { public: ... void _raise() const = 0; ... }

    ;

  • Reported: CPP 1.0 — Mon, 20 Sep 1999 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close no change. This issue is already addressed in the CORBA 2.3 specification.

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

String extractor semantics undefined?

  • Key: CPP11-102
  • Legacy Issue Number: 2890
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: CORBA 2.3 added the requirement (1.7 & 1.8) that string extractor
    operators be defined for String_var & string member classes, for
    example:

    std::istream& operator >>(std::istream &, CORBA::String_var &);

    However, the semantics of the extractor operations is undefined. Does
    the extractor operator extract characters until the first whitespace?
    until a newline? until the default width of the stream? until eof?

    The same applies to wide strings.

  • Reported: CPP 1.0 — Tue, 14 Sep 1999 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    closed/resolved

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

Contents of string members (02)

  • Key: CPP11-101
  • Legacy Issue Number: 2888
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: 2. Should it be legal to assign a null pointer to a string member of a
    struct, sequence, array or exception?

  • Reported: CPP 1.0 — Tue, 14 Sep 1999 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    closed/resolved

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

Contents of string members (01)

  • Key: CPP11-100
  • Legacy Issue Number: 2887
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: 1. What is the contents of a string member of a struct, sequence, array
    or exception after out() or _retn() has been called? Is it a null
    pointer, or an empty string?

    I think that for best consistency, it should be an empty string, which
    is the same state after default construction.

  • Reported: CPP 1.0 — Tue, 14 Sep 1999 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    closed/resolved

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

Union string member mapping defect?

  • Key: CPP11-99
  • Legacy Issue Number: 2880
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary:
    The mapping for string members has modifier functions for "char *",
    "const char *", and "String_var". Shouldn"t there also be a modifier
    function that takes the unnamed struct string member and array string
    member types?

  • Reported: CPP 1.0 — Sat, 4 Sep 1999 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    closed/resolved

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

Two obvious typos in the C++ mapping for OBV (docs/formal/99-07-41.pdf)

  • Key: CPP11-98
  • Legacy Issue Number: 2841
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: - The factories" names in the example IDL on page 1-88 are incomplete

    • Page 1-90: should be CORBA::CustomMarshal rather than
      CORBA::CustomerMarshal. Nice freudian slip. Might it be that the OBV
      mapping was done by marketeers rather than technicians?
  • Reported: CPP 1.0 — Sun, 15 Aug 1999 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close as duplicate of 2354.

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

operator>> for String_var

  • Key: CPP11-97
  • Legacy Issue Number: 2619
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The C++ mapping says:

    A compliant mapping implementation shall provide overloaded operator<<
    (insertion) and operator>> (extraction) operators for using String_var
    and
    String_out directly with C++ iostreams.

    >From this definition it"s no clear whether operator>> allocates memory
    or not. That is, is the following code correct?

    CORBA::String_var str;
    cin >> str;

  • Reported: CPP 1.0 — Wed, 21 Apr 1999 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    closed/resolved

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

Valuetypes and _out classes in C++ mapping

  • Key: CPP11-96
  • Legacy Issue Number: 2564
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: I"m trying to work out how valuetypes interact with My question is what should the two reference counts be, and why?
    >From my understanding, myVal"s reference count should be 1, and myPtr"s
    reference count should be 0.

    Is this correct? Perhaps an example _out type for valuetypes should be
    included in the spec to clear this up for future reference.

  • Reported: CPP 1.0 — Wed, 31 Mar 1999 05:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close no change. The submitter of the issue misunderstood _var semantics.

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

Valuetypes and arbitrary graphs

  • Key: CPP11-95
  • Legacy Issue Number: 2561
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Valuetypes can be used to form arbitrary, potentially circular graphs.
    This means that reference counts may never drop to zero and that more
    advanced garbage collection is required, which does not come natural to
    C++.

    An ORB may keep track of circularity by traversing a graph and can detect
    if the last outside reference is lost. However, the overhead is significant,
    and the solution would be incomplete, as users need not use "proper" refe-
    rence counting on graph nodes by ignoring both OBV_* classes and default
    reference counting.

    Possible solution: restrict CORBA::DefaultValueRefCountBase to
    non-circular graphs. Users can decide much better when a graph is safe
    to be cleaned up.

  • Reported: CPP 1.0 — Tue, 30 Mar 1999 05:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close as duplicate of 2309.

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

Factories for StringValue and WStringValue

  • Key: CPP11-94
  • Legacy Issue Number: 2560
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The C++ mapping for Objects by Value requires factories for marshalling
    valuetypes. Therefore, it needs to specify default factories for the
    standard StringValue and WStringValue types.

  • Reported: CPP 1.0 — Tue, 30 Mar 1999 05:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close no change. Valueboxes do not have factories.

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

Sequences and get_buffer()

  • Key: CPP11-93
  • Legacy Issue Number: 2530
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: This is a new issue for the C++ RTF.

    The mapping for sequences mandates a get_buffer() accessor for read/write
    access to the members of the sequence. It is mentioned that an implemen-
    tation is not required to store sequence elements in continuous memory
    for efficiency reasons, but may choose to do so only when get_buffer()
    is called.

    However, this introduces coherency problems if sequence elements are
    accessed and modified using both get_buffer() and operator[].

    get_buffer() is not possible for recursive sequences anyway.

  • Reported: CPP 1.0 — Fri, 12 Mar 1999 05:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close no change. The submitter of the issue misread the specification.

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

Valuetype argument passing

  • Key: CPP11-92
  • Legacy Issue Number: 2523
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The passing of valuetypes as parameter to operations needs more
    consideration. Section 20.22 of ptc/98-09-03 (98/11/06) specifies
    that the callee should receive a deep-copy of each valuetype to
    preserve location transparently.

    Now, does this apply only to operations of interfaces, or also to
    valuetype operations? With the current phrasing, this applies just
    the same (meaning that valuetype operations also receive a deep-
    copy). And then there are abstract interfaces, which may incarnate
    a remote interface or a local valuetype.

  • Reported: CPP 1.0 — Tue, 9 Mar 1999 05:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close no change. The specification is already clear about valuetype argument passing semantics.

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

Add AbstractBase base type to IDL language?

  • Key: CPP11-91
  • Legacy Issue Number: 2499
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Does it make sense to add the AbstractBase base
    type to the IDL language, so that operations could
    receive an AbstractBase parameter?

  • Reported: CPP 1.0b1 — Mon, 1 Mar 1999 05:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    close with no change

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

narrow abstract interface class to concrete object?

  • Key: CPP11-90
  • Legacy Issue Number: 2498
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Should it be possible to narrow an abstract interface
    class to a concrete Object, or to downcast it to a
    Valuetype?

  • Reported: CPP 1.0b1 — Mon, 1 Mar 1999 05:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    closed/resolved

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

generate concrete classes and factories for valuetypes without initializer

  • Key: CPP11-89
  • Legacy Issue Number: 2496
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Suggestion: generate concrete classes and factories
    for valuetypes that do not have any initializers. If a
    value type does not have any initializers, it should
    be safe to use the default constructor for all members.

    This would reduce the size of the code that needs
    to be written by the application programmer.

    Similarly, concrete factories could be generated for
    value boxes

  • Reported: CPP 1.0b1 — Mon, 1 Mar 1999 05:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    resolved/closed

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

add a _var type for each servant type

  • Key: CPP11-88
  • Legacy Issue Number: 2445
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: full_desc: The C++ mapping for CORBA 2.3 introduces reference
    counting on servants and provides the
    PortableServer::ServantBase_var class for automated
    reference counting. However, this class can not be
    used if a more specific type of the servant is needed.
    Proposal: add a _var type for each servant type, for
    example POA_FooBar_var.

  • Reported: CPP 1.0b1 — Tue, 9 Feb 1999 05:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    see below

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

tie doesn"t do ref counting

  • Key: CPP11-87
  • Legacy Issue Number: 2441
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: After all the recently past work getting servant reference counting, it
    just occurred to me that this doesn"t work with TIE. Or am I missing
    something?

    As things stand, to make it work it is necessary to derive a new class
    from both the instantiated tie template and RefCountServantBase. This
    then requires all the constructors to be redefined - ugh!

  • Reported: CPP 1.0b1 — Fri, 5 Feb 1999 05:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    See resolution for issue 4114, which addresses this issue as well.

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

Misleading text for DSI invoke() and _primary_interface()

  • Key: CPP11-86
  • Legacy Issue Number: 2357
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Section 20.38.3 of the CORBA 2.3 draft states:
    I believe that the intent of this paragraph is to forbid the user from
    calling invoke() and _primary_interface() directly, not to forbid the
    POA from calling _primary_interface() in circumstances other than
    processing a request.

    The paragraph should be reworded to say:

    "The invoke() and _primary_interface() methods will be called by the
    POA, and should never be explicitly called by the application."

  • Reported: CPP 1.0b1 — Fri, 29 Jan 1999 05:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close no change. This issue is already addressed in the CORBA 2.3 specification.

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

Any missing LongLong operators, etc?

  • Key: CPP11-85
  • Legacy Issue Number: 2118
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: In the latest spec (98-09-03) the Any class appears to be missing
    insertion extraction operators for LongLong, ULongLong, etc.

  • Reported: CPP 1.0b1 — Thu, 22 Oct 1998 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close no change. This issue is already addressed in the CORBA 2.3 specification.

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

_primary_interface

  • Key: CPP11-84
  • Legacy Issue Number: 2029
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: From the C++ spec (CORBA2_3-c++.pdf) pg: 20-132

    For static skeletons, the default implementation of the _get_interface
    and _is_a functions provided by ServantBase use the interface associated
    with the skeleton class to determine their respective return values. For
    dynamic skeletons (see Section 20.37), these functions use the
    _primary_interface function to determine their return values.

    Does this mean that a dynamic implementation needs the IFR?
    If not, then how can _is_a be implemented for sub-types?

    I note that the java mapping includes the method _all_interfaces in Servant
    for precisely this reason...

  • Reported: CPP 1.0b1 — Fri, 2 Oct 1998 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Already resolved.

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

The C++ mapping for valuetype _narrow should not _add_ref

  • Key: CPP11-83
  • Legacy Issue Number: 2002
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The C++ mapping for valuetype includes a typesafe _narrow generated
    for all values. The specification states that the caller
    of _narrow must invoke _remove_ref once on the returned value
    from _narrow (just like object reference _narrow).
    f

  • Reported: CPP 1.0b1 — Sun, 27 Sep 1998 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Already resolved.

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

sequence allocbuf parameter != 0

  • Key: CPP11-82
  • Legacy Issue Number: 1946
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Sequence allocbuf functions should be specified such that passing zero for
    their arguments is illegal. Allocating a sequence buffer of zero elements
    is rather pointless because nothing useful can be done with such a buffer.
    The result of passing zero to allocbuf should be implementation-defined,
    since throwing an exception is not a good way to handle programming logic
    errors (similar to how indexing past the end of a sequence is a logic error
    for which an exception is pretty useless).

  • Reported: CPP 1.0b1 — Sun, 13 Sep 1998 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close no change. Discussion of this issue determined that a zero parameter to allocbuf is legal and

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

Passing Fixed to operations

  • Key: CPP11-81
  • Legacy Issue Number: 1785
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: // IDL
    typedef fixed<4,2> F;

    interface foo

    { void op(in F param); }

    ;

    What should happen if at run time, I do the following?

    F myf = "12345.678D";

    foo_var fv = ...;
    fv->op(myf); // ???

    I think the operation should raise BAD_PARAM, because silent truncation
    is too dangerous. Note that the operation cannot send a fixed<8,3> because
    the operation expects a fixed<4,2> and will get a marshalling error if
    what arrives over the wire does not match the IDL definition.

  • Reported: CPP 1.0b1 — Fri, 7 Aug 1998 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close no change. This issue is already addressed in the CORBA 2.3 specification.

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

Comparison operators for Fixed

  • Key: CPP11-80
  • Legacy Issue Number: 1783
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The fixed mapping in 98-07-12 shows:

    Fixed operator > (const Fixed &val1, const Fixed& val2);
    Fixed operator < (const Fixed &val1, const Fixed& val2);
    Fixed operator >= (const Fixed &val1, const Fixed& val2);
    Fixed operator <= (const Fixed &val1, const Fixed& val2);
    Fixed operator != (const Fixed &val1, const Fixed& val2);
    Fixed operator == (const Fixed &val1, const Fixed& val2);

    I"m surprised at the return type – shouldn"t that be bool for ANSI
    compilers and int for non-ANSI compilers?

  • Reported: CPP 1.0b1 — Fri, 7 Aug 1998 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Already resolved.

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

Parameter passing rules for ValueFactory

  • Key: CPP11-79
  • Legacy Issue Number: 1658
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Since it is a native, the parameter passing rules for ValueFactory
    must be specified so the register/unregister/lookup operations
    can be mapped.

  • Reported: CPP 1.0b1 — Thu, 9 Jul 1998 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Already resolved.

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

C++ language mapping minor editorial revision

  • Key: CPP11-78
  • Legacy Issue Number: 1656
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: There are a few minor editorial mistakes in the C++ language
    mapping examples. These are included in this single issue for
    brevity.

  • Reported: CPP 1.0b1 — Thu, 9 Jul 1998 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Already resolved.

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

Section 5.3.6.3 Value Factories

  • Key: CPP11-77
  • Legacy Issue Number: 1655
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The last paragraph of section 5.3.6.3 says the standard language mapping
    rules are followed when determining these operation signatures. Since
    one of the arguments/return values is a Native, this isn"t quite
    possible.

  • Reported: CPP 1.0b1 — Thu, 9 Jul 1998 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Already resolved.

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

Problems with deactivate_object()

  • Key: CPP11-76
  • Legacy Issue Number: 1627
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The POA does not properly define the behavior of POA operations
    for requests that are currently executing in an object that
    has been deactivated.

  • Reported: CPP 1.0b1 — Thu, 2 Jul 1998 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close no change. This issue is already addressed in the CORBA 2.3 specification.

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

Do POA servant classes need to use virtual inheritance?

  • Key: CPP11-75
  • Legacy Issue Number: 1535
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: 2. The spec is silent on whether POA servant classes need to use
    virtual inheritence when an IDL class inherits from the same base
    interface more than once:

    // IDL
    interface A

    { void op(); }

    ;
    interface B : A { };
    interface C : A { };
    value D : supports B, C { };

    Must POA_B & POA_C inherit virtually from POA_A or can defined
    independently with all of interface A"s operations? This makes a big
    difference for values that support interfaces, since, for example, value
    D is defined by the C++ language mapping to inherit from both POA_B and
    POA_C. So, does value D inherit one or two versions of A::op()?

  • Reported: CPP 1.0b1 — Thu, 18 Jun 1998 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    resolved

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

Spec is too verse in defining the T_var types for fixed length

  • Key: CPP11-74
  • Legacy Issue Number: 1521
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: 3. The spec is too terse in defining the T_var types for fixed length
    structured types as having "the same semantics as T_var types for
    variable-length types." This is not quite true, since the signatures
    for out and return values of these types are different, thus changing
    the semantics of the implicit and explicit (out() and _retn())
    conversion operations. The spec should show the definition of the out()
    and _retn() operations for fixed length types as:

    T &T_var::out()

    { return ptr_; }

    T &T_var::_retn()
    { return ptr_; }
  • Reported: CPP 1.0b1 — Wed, 10 Jun 1998 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    closed/resolved

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

Spec does not mention the existance of an Any_out class

  • Key: CPP11-73
  • Legacy Issue Number: 1520
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: 2. The spec does not explicitly mention the existence of an Any_out
    class. I believe that this class is necessary, following the same
    pattern as the normal T_out class for variable length structured types.

  • Reported: CPP 1.0b1 — Wed, 10 Jun 1998 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    resolved and closed

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

_var & _out types problems (01)

  • Key: CPP11-72
  • Legacy Issue Number: 1519
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: 1. The spec insection 20.9.2 does not specifically address the form of
    T_out types for fixed length structured types. So, should the T_out
    type be:

    typedef T &T_out;

    or should it follow the form of the T_out type for variable length
    structured types and define as a "class T_out"? In this case, of course
    the copy contructor operator from T_var would not delete the pointer
    held by the T_var.

    Since the "class T_out" solution for fixed length types does not appear
    to have any advantages over the typedef, I recommend that the spec be
    modified to state that T_out types for fixed length structured types
    simply be a typedef of "T&".

  • Reported: CPP 1.0b1 — Wed, 10 Jun 1998 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    see below

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

Missing operators in orbos/98-01-11

  • Key: CPP11-71
  • Legacy Issue Number: 1383
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: the Any class shown on page 20-115 of 98-01-11 appears to be missing
    support for some of the new IDL types. In particular, no operators
    are shown for (unsigned and signed) long long and long double.

    Also, there is no operator to insert an unbounded wide string.

  • Reported: CPP 1.0b1 — Mon, 18 May 1998 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close no change. This issue is already addressed in the CORBA 2.3 specification.

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

C++ Sequence mapping Question

  • Key: CPP11-70
  • Legacy Issue Number: 1134
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Section 20.13 states:

    "For each different named OMG IDL sequence type, a compliant
    implementation provides a separate C++ sequence type."

    This certainly means that each declared sequence with a different bound
    and component type maps to a unique C++ class. But how about this:

    // IDL
    typedef sequence<long> LongSeq1;
    typedef sequence<long> LongSeq2;

    Are LongSeq1 & LongSeq2 mapped to the same or different C++ classes?

  • Reported: CPP 1.0b1 — Tue, 7 Apr 1998 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close no change. This issue is already addressed in the CORBA 2.3 specification.

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

TypeCode_ptr base_typecode(TypeCode_ptr tc)

  • Key: CPP11-69
  • Legacy Issue Number: 1115
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Look at this code and tell me what is wrong with it (CORBA:: left off
    for simplicity):
    So, now the question is: Inside the
    TypeCode_var::operator=(TypeCode_ptr tc)
    assignment operator, when tc == this, what should happen?

    Should this call release(this) to satisfy the requirements of code frag
    #3? Or should it be a noop to satisfy the requirements of code frag #4?

  • Reported: CPP 1.0b1 — Mon, 6 Apr 1998 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close no change. The submitter of the issue misunderstood _var reference counting semantics.

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

C++ mapping for fixed is broken (02)

  • Key: CPP11-68
  • Legacy Issue Number: 1093
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: 2. The mapping for the "_out" type for Fixed is broken. It is
    specified as a typedef, for example "Fixed<3,1>" maps to:

    typedef Fixed<3,1> &Fixed_3_1_out;

    but the IDL grammar allows fixed types to be declared as attribute
    types, operation parameters and return values. This causes problems
    because it is no longer obvious where to declare the _out type for an
    out parameter.

  • Reported: CPP 1.0b1 — Sat, 21 Mar 1998 05:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close as fixed. The new Fixed mapping takes care of this.

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

No conversion defined from a B_var to an A_ptr

  • Key: CPP11-67
  • Legacy Issue Number: 956
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: I was writing some C++ code and noticed that the following doesn"t work:

    // IDL

    interface A {
    };

    interface B : A {
    };

    // C++

    B_var bv = get_b_from_somewhere();
    A_var av = A::_duplicate(bv);

    because there is no conversion defined from a B_var to an A_ptr. Is
    there a way that this could be added to the language binding without
    ambiguity problems?

  • Reported: CPP 1.0b1 — Wed, 11 Feb 1998 05:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    close with no change

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

ServantBase mappings

  • Key: CPP11-66
  • Legacy Issue Number: 920
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Should the C++ mapping for ServantBase also have _duplicate,
    _var mappings ? For example if get_servant is called on POA, what
    are the ownership rules for the returned Servant. It seems providing
    a _duplicate, _release operations on ServantBase might be useful. These
    operations could be used to ensure that the Servant is not released
    while the caller has a reference to it.

  • Reported: CPP 1.0b1 — Tue, 27 Jan 1998 05:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    resolved and closed in ptc/1998-09-03

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

C and C++ Mapping question

  • Key: CPP11-65
  • Legacy Issue Number: 705
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: IDL spec states that identifiers can have characters that are things like an A with accent aigu, or a german script B. Can IDL identifiers have these characters? How are they mapped ontoC/C++?

  • Reported: CPP 1.0b1 — Sat, 23 Aug 1997 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close as non-issue. IDL no longer permits non-ASCII letters in identifiers.

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

inout strings modifiable?

  • Key: CPP11-64
  • Legacy Issue Number: 678
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: C++ mapping spec should be clearer about the rules for inout strings.There are currently two possible interpretations of what server can do with an inout string (details in archive)

  • Reported: CPP 1.0b1 — Mon, 18 Aug 1997 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    resolverd and closed

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

Multiple inheritance of C++ Servants is ill-defined

  • Key: CPP11-63
  • Legacy Issue Number: 674
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Please find example/discussion in corresponding archive file

  • Reported: CPP 1.0b1 — Mon, 11 Aug 1997 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    closed and resolved

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

C++ mapping of servants may result in ambigous run-time behavior

  • Key: CPP11-62
  • Legacy Issue Number: 673
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: If the same servant and ObjectId are registered with two POAs, _this() can"t know which object to return outside of a method invokation

  • Reported: CPP 1.0b1 — Mon, 11 Aug 1997 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close no change. This issue is already addressed in the CORBA 2.3 specification.

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

Implementation problem with policy objects using root POA

  • Key: CPP11-61
  • Legacy Issue Number: 663
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: It appears to be impossible to implement the policy objects using the root POA due to race conditions on the Polilicy::destroy() operation. There appears to be no safe time to delete servant

  • Reported: CPP 1.0b1 — Sat, 9 Aug 1997 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close no change. This issue is already addressed in the CORBA 2.3 specification.

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

sec. 18.1.2: explicit information on _this() is missing

  • Key: CPP11-60
  • Legacy Issue Number: 653
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The discussion of how _this() operates is missing explicit information about what to do if there is no request context. Should _this() return nil reference, or should exception be thrown

  • Reported: CPP 1.0b1 — Tue, 5 Aug 1997 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close no change. This issue is already addressed in the CORBA 2.3 specification.

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

Blocking semantics of get_next_response not well specified

  • Key: CPP11-59
  • Legacy Issue Number: 646
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The semantics of get_next_response sec 4.3.4 are not well-defined with respect to blocking behavior. There is no explicit description of the behavior of the C++ routines

  • Reported: CPP 1.0b1 — Thu, 31 Jul 1997 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    resolved, issue closed

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

Section 16.2, Section 16.6: editorial

  • Key: CPP11-58
  • Legacy Issue Number: 622
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Section 16.2: "A shown" should be "As shown". Section 16.6: The title is incorrect "TMapping" remove the "T"

  • Reported: CPP 1.0b1 — Wed, 9 Jul 1997 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close as fixed. A search through the current draft does not locate either of the two typos mentioned

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

IDL from Ennvironment has invalid attribute

  • Key: CPP11-57
  • Legacy Issue Number: 618
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: IDL from Environment has an attribute called "exception" which is invalid. This member should be renammed to "ex"or some other name which is a legal identifier

  • Reported: CPP 1.0b1 — Mon, 14 Jul 1997 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close no change. Environment is defined as PIDL, so this is legal.

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

Interface definition must be standardized

  • Key: CPP11-56
  • Legacy Issue Number: 608
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: IDL for Object Interface differs from that provided by core specification in section 7.2 page 7.2

  • Reported: CPP 1.0b1 — Wed, 9 Jul 1997 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close with no change. The relevant functions are shown in the latest C++ mapping.

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

String_var and Any_var are missing the T_ptr definition

  • Key: CPP11-55
  • Legacy Issue Number: 600
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Appendix E page E-2 and E-3: String_var and Any_var classes are missing T_ptr definition that occurs in the template for var types. These should be added for completness.

  • Reported: CPP 1.0b1 — Wed, 9 Jul 1997 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close with no change. Only object reference types have _ptr type. They do not apply to strings or ty

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

const method qualification should be removed

  • Key: CPP11-54
  • Legacy Issue Number: 599
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: C++ mapping for pseudo request class contains const member functions mapped from readonly attributes. IDL does not define C++ mapping for readonly attribs to const member functions.

  • Reported: CPP 1.0b1 — Wed, 9 Jul 1997 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    close with no change

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

Legal IDL cannot map to C++

  • Key: CPP11-53
  • Legacy Issue Number: 497
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Generated C++ (example) ends up with redefinition errors. This is not addressed in current C++ mapping. Options are to amend IDL or to simply state that such IDL cannot be translated.

  • Reported: CPP 1.0b1 — Wed, 5 Feb 1997 05:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    close with no change

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

Double underscore identifier mapping

  • Key: CPP11-52
  • Legacy Issue Number: 496
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: identifiers containing a double underscore[..] are reserved for use by C++ implementations and standard libraries and shall be avoided by users. IDL could be amended to prohibit double undersc.

  • Reported: CPP 1.0b1 — Wed, 5 Feb 1997 05:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    closed with no change

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

[q] intf name == op name

  • Key: CPP11-51
  • Legacy Issue Number: 481
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Sentence in IDL spec "An identifier can only be defined once in a scope.However,identifiers can be redifined in nested scopes" seems to allow interface Foo

    { void Foo(in long 1); }

    ;

  • Reported: CPP 1.0b1 — Wed, 22 Jan 1997 05:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close no change. This issue is already addressed in the CORBA 2.3 specification

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

u++ binding for ServerRequest pseudo object

  • Key: CPP11-50
  • Legacy Issue Number: 290
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Class defined for ServerRequest shows op_def() operation. Seems not to be in IDL for ServerRequest and there is no description in the rest of the section (CORBA 2 spec, Sect. 18.4.1)

  • Reported: CPP 1.0b1 — Thu, 24 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close no change. This issue is already addressed in the CORBA 2.3 specification.

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

C++ semantics vs. IDL semantics

  • Key: CPP11-49
  • Legacy Issue Number: 268
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Isn"t it the mappings responsibility to decide how to project the semantics to the underlying "wire rep". You don"t need to put NULL on the wire. Sec 16.18 Pg 16-46 para 11 CORBA2.0

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close no change. This change is too intrusive and would break too much existing code

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

ANy release flag and operator

  • Key: CPP11-48
  • Legacy Issue Number: 267
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Sec 3.16.2 para 11 describes lifetime of inserted value. Since lifetime of the value is independent of value passed to operator<<=, Any must contain a copy of value.

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    close with no change

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

operator<< for ostreams and Exceptions

  • Key: CPP11-47
  • Legacy Issue Number: 266
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Exceptions could be formatted onto ostreams using operator<<..Examples available on /archives/issues/issue266

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    closed/resolved

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

make String_var reference but not adopt

  • Key: CPP11-46
  • Legacy Issue Number: 264
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: String_var could refer to memory without assuming memory management responsibilities for it, like void String_var::value(const char*, Boolean release = 0

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    close with no change

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

buffer classes for sequences

  • Key: CPP11-45
  • Legacy Issue Number: 263
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: p41,sec 3.13.3,para 24: These functions should return buffers, not T* If you wanted a T* provide a conversion on returned buffer. No need to lock down implementation in this manner

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    closed with no change

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

TypeCode for each basic and IDL defined types

  • Key: CPP11-44
  • Legacy Issue Number: 261
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Sec 4.10 para 2: pseudo object reference of form tc<type> made available for basic and IDL defined types. Sun wants replacements with global function of form TypeCode_ptr tc<type>

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close with no change

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

Exception id for each exception type

  • Key: CPP11-43
  • Legacy Issue Number: 260
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: C++ mapping should make available the exception id for each exception type.. Sun would like to revise sec. 3.17 to add following function: static const char * _exception_id();

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    closed/resolved

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

Accessor for exception id

  • Key: CPP11-42
  • Legacy Issue Number: 259
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The base exception class should include an accessor to get the exception id of an exception.It"s obtained from environment.Ability to get exception id is desirable in C++

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    closed/resolved

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

Accessors for the Any release flag

  • Key: CPP11-41
  • Legacy Issue Number: 258
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Sun would like to add the following accessors to Any: Boolean release(); void release(Boolean);

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close with no change

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

Constructor taking discriminant as argument

  • Key: CPP11-40
  • Legacy Issue Number: 255
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Sec 3.12 para1 describes union constructors.Sun would like to add new constructor that takes as its sole argument a discriminant value.It initializes union according to specified discr. value

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close with no change

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

Name field for SystemExceptions

  • Key: CPP11-39
  • Legacy Issue Number: 253
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: SystemException class should contain a string name field for easy printing of error messages,or operator<< should be overloaded for each system exception

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    closed/resolved

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

union accessors require temporaries

  • Key: CPP11-38
  • Legacy Issue Number: 250
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: For structs and exceptions: Unions" access functions return primitives by value, not by refs.I need to use temporaries.Change them to refs

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close no change. This issue is already addressed in the CORBA 2.3 specification.

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

accessor members for structs

  • Key: CPP11-37
  • Legacy Issue Number: 245
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Struct Mapping: IONA that accessor functions be provided for struct members. Direct access to member variables still available. Enhancement affords the user a consistent interface.

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Closed with no change

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

allocbuf and initialization of elements

  • Key: CPP11-36
  • Legacy Issue Number: 241
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Sec 3.13.2 para 25describes allocbuf. Sun prefers that allocated sequence elements be initialized as if vector were allocated by sequence constructor

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close no change. This issue is already addressed in the CORBA 2.3 specification.

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

C++ namespaces

  • Key: CPP11-35
  • Legacy Issue Number: 238
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Implementation dependent: Namespaces available/not available

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close no change. Issue withdrawn by submitter.

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

Allocated storage for out and return strings

  • Key: CPP11-34
  • Legacy Issue Number: 237
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Sec 16.6 Pg 16-11 CORBA2.0: Sec D.12 states that client stub allocates buffer of specified size for bounded strings.This may result in unnecessary memory consumption.

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    close with no change

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

accessor function on SystemException

  • Key: CPP11-33
  • Legacy Issue Number: 234
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: SystemException has accessor functions minor() and completed() rather than public data members like exceptions normally do. Normal mapping is to make exception data into public data members

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close with no change.

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

Mapping for IDL context

  • Key: CPP11-32
  • Legacy Issue Number: 232
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: If operation in an IDL spec. has a context spec, then a Context_ptr input parameter follows all operation specific arguments (OMGD 3.19) It should map to const Context_ptr

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close with no change. Object references are always passed as a plain _ptr parameter and never as a c

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

union accessors

  • Key: CPP11-31
  • Legacy Issue Number: 231
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Accessors that return a reference to a non-const object can be used for read-write access. They are provided only for following types: struct, union, sequence, any.Provede for all types..

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close no change. This change is too intrusive and would break too much existing code.

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

callee-allocated storage modification

  • Key: CPP11-30
  • Legacy Issue Number: 228
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: CORBA2.0 Sec 16.18 Pg 16-45 para 9 The caller has sufficient knowledge to release, but not sufficient knowledge to know if contiguous. ("to allow..we adopt the policy....")

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Already resolved.

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

anonymus types

  • Key: CPP11-29
  • Legacy Issue Number: 227
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Tables not present in CORBA2.0 Aren"t anonymus sequences still allowed in structs, union, and exception?

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close no change. This issue is already addressed in the CORBA 2.3 specification.

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

void* from Any for constructed types

  • Key: CPP11-28
  • Legacy Issue Number: 226
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: tables not present in CORBA2.0 What about structs, unions, exceptions, and arrays?

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close no change. This issue is already addressed in the CORBA 2.3 specification

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

handling void* from Any

  • Key: CPP11-27
  • Legacy Issue Number: 225
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Sec 16.14.6 Pg 16-38 para 44 CORBA2.0 How are you supposed to delete/duplicate this void* value if you don"t know the type? Do we have to emulate a C++ compiler

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close no change. This issue is already addressed in the CORBA 2.3 specification.

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

Pointers vs. values

  • Key: CPP11-26
  • Legacy Issue Number: 224
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Sec. 16.14.3 Pg 16-34 para 30 CORBA2.0 p.48, sec 3.16.3, para 26 Why is this specified. Why are pointers treated differently from Values. Primitives are not set to NULL

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close with no change. It is no longer possible to identify the document to which the question refers

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

Storage ownership issue

  • Key: CPP11-25
  • Legacy Issue Number: 223
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: CORBA2.0 Care must be taken to avoid using T_var types with these extraction operators. They will try to assume responsibility for deleting storage owned by Any. Problem in mapping.

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close with no change. That's how the mapping was designed to work.

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

Global functions vs. T_var namespace

  • Key: CPP11-24
  • Legacy Issue Number: 222
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Sec 16.12 Pg 16-28 CORBA2.0 p. 44, sec 3.14 para 8: Why are these global functions rather than static methods of T_var?

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    closed/resolved

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

Array_forany

  • Key: CPP11-23
  • Legacy Issue Number: 221
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Do you anticipate end user"s instantiating the Array_forany class? Isn"t this a implementation detail? The name conflicts with IDL specifiable. Section should be removed.

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    closed/resolved

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

Array slice example

  • Key: CPP11-22
  • Legacy Issue Number: 219
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Sec 16.12 Pg 16-27 CORBA 2.0 Why is a Long Array_slice declared to be a typedef Long[]? Why are these locked down rather than allowing a slice to be a class?

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    resolved/closed

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

Semantics of sequence length() operation

  • Key: CPP11-21
  • Legacy Issue Number: 218
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Sec 16.11 Pg 16-23 CORBA2.0 What is the semantics of the length() member? When can I do reallocation? Can it truncate? Can it realloc if length== current size?

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close no change. This issue is already addressed in the CORBA 2.3 specification.

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

Copying of out parameters

  • Key: CPP11-20
  • Legacy Issue Number: 217
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Sec 16.11.2 Pg 16-25 CORBA2.0 p.41, section 3.13.2 para 21 Do I have to make an application level full copy? This doesn"t meet the performance goal outlined in the beginning

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Already resolved.

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

C vs. C++ coding style

  • Key: CPP11-19
  • Legacy Issue Number: 215
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Sec 16.11.2 Pg 16-24 CORBA2.0 p. 40 Section 3.13.2, para 17 Looks like C, not C++

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close no change. We do not have enough context to determine what the issue is.

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

Autoextension of sequences

  • Key: CPP11-18
  • Legacy Issue Number: 208
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: [Sec 16.11 Pg 16-21 CORBA2.0 Since autoextension is not apparently supported, you should change "may" to "must"

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    resolved and closed

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

Implementation description

  • Key: CPP11-17
  • Legacy Issue Number: 206
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: [Sec 16.9 Pg 16-15 CORBA2.0 p.32, Section 3.11 para 4: Seems to describe an implementation. Why is it specified. Is this how Sec. 3.10.1 para 14 issue is supposed to be addressed?

  • Reported: CPP 1.0b1 — Fri, 11 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close no change. We do not have enough context to determine what the issue is.

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

Detection of initialization of T_var

  • Key: CPP11-16
  • Legacy Issue Number: 203
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: [Sec 16.8.1 Pg 16-14 CORBA2.0] p.31, Section 3.10.1 para 12: How do I know if the T_var I"ve been passed (in C++) has been initialized?

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close no change. This change is too intrusive and would break too much existing code.

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

Assignment to T_var

  • Key: CPP11-15
  • Legacy Issue Number: 202
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: What happens if i assign a container of data I hold Does aliasing allow in more than simple temporary. Is there a restriction that there can be NO overlapping?

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close no change. We do not have enough context to determine what the issue is.

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

example incorrect?

  • Key: CPP11-14
  • Legacy Issue Number: 201
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Sec 16.8 Pg 16-13 CORBA2.0 p. 29, Section 3.10 example para 4. : This example looks incorrect. Example shown in 3.10.1 is inconsistent with the code in paragraph 4.

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close no change. We do not have enough context to determine what the issue is.

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

Levels of portability conformance requested

  • Key: CPP11-13
  • Legacy Issue Number: 199
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Sec 15.1.1 Pg 15-1 CORBA2.0 "Conforming client or server program is portable across all conforming implementations" We object the word "portable"being used in this context.

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close no change. We do not have enough context to determine what the issue is.

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

Representation of void* returned from ANY

  • Key: CPP11-12
  • Legacy Issue Number: 198
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Implementation dependent: Implementation representation of the void * pointer returned by Any::value() for unknown types

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close with no change. The latest draft has already deprecated the void * member functions for type A

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

TypeCode/Value mismatch in ANY

  • Key: CPP11-11
  • Legacy Issue Number: 197
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Implementation dependent: What happens if the typecode & value for the unsafe Any operations do not match?

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close no change. Issue withdrawn by submitter.

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

illegal union access when discriminator is wrong

  • Key: CPP11-10
  • Legacy Issue Number: 196
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Implementation dependent: illegal access of union member accessor functions when the discriminator has the wrong value

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close no change. Issue withdrawn by submitter.

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

_ptr member accessors for string and objref

  • Key: CPP11-9
  • Legacy Issue Number: 195
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Implementation dependent: _ptr member accessors for strings & object references

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close no change. Issue withdrawn by submitter.

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

Pseudo objects for DSI

  • Key: CPP11-8
  • Legacy Issue Number: 193
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: [Ch 17 CORBA2.0] Sun would like section 4 to include the interface for the dynamic server invocation

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close no change. This issue is already addressed in the CORBA 2.3 specification.

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

Identifier conflicts resulting from the language mapping

  • Key: CPP11-7
  • Legacy Issue Number: 192
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Section 3.1 para 4 specifies the rule for resolving identifier conflicts with C++ keywords. A similar rule is required to resolve name conflicts resulting from the mapping.

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close 192 with no change

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

interface mapping

  • Key: CPP11-6
  • Legacy Issue Number: 188
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Mapping for Interface [16.3 CORBA2.0] Mapping example in 3.5.6 implements the ptr type as full pointer. A pointer could be implemented as a class

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close no change. This change is too intrusive and would break too much existing code.

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

Inconsistent interfaces for the operation pairs *duplicate* and

  • Key: CPP11-5
  • Legacy Issue Number: 186
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The operations duplicate and release work together to provide memory mgmt. functionallity. It"s desirable to use both via similar interface/syntax. nil/is_nil similar problem

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    close with no change

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

Testing exceptions

  • Key: CPP11-4
  • Legacy Issue Number: 143
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: In the DII, testing what variety of exception is stored in the Request Pseudo-object requires a sequence of dynamic_cast<> or (_narrow) calls. It would be useful to have a single call.

  • Reported: CPP 1.0b1 — Tue, 1 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    closed/resolved

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

Passing of object reference in pointers

  • Key: CPP11-3
  • Legacy Issue Number: 125
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Suggest changing the mapping so that object references for an interface "T" are passed as "const T_ptr&" instead of just "T_ptr" for "in" parameters.

  • Reported: CPP 1.0b1 — Mon, 23 Sep 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close no change. This change is too intrusive and would break too much existing code.

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

Fixed structs

  • Key: CPP11-2
  • Legacy Issue Number: 123
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Should the ORB hide the difference between fixed and variable length structs from the application developer?

  • Reported: CPP 1.0b1 — Mon, 23 Sep 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close no change. This change is too intrusive and would break too much existing code.

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