C++ Language Mapping Avatar
  1. OMG Specification

C++ Language Mapping — All Issues

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

Issues Summary

Key Issue Reported Fixed Disposition Status
CPP11-264 Rounding and truncation of Fixed CPP 1.0b2 CPP 1.0 Resolved closed
CPP11-263 Fixed-point initialization CPP 1.0b2 CPP 1.0 Resolved closed
CPP11-262 C++ Servants: Adding Reference counting CPP 1.0b2 CPP 1.0 Resolved closed
CPP11-260 mapping IDL Unicode escapes to C++ CPP 1.0b2 CPP 1.0 Resolved closed
CPP11-259 Mappings for hash, is_equivalent, _is_a and _non_existent CPP 1.0b1 CPP 1.0b2 Duplicate or Merged closed
CPP11-257 Re-opening modules CPP 1.0b1 CPP 1.0b2 Resolved closed
CPP11-252 "Diamond of Death" in CosLifeCycleReference CPP 1.0b2 CPP 1.0 Resolved closed
CPP11-251 Typedef for ties? CPP 1.0b2 CPP 1.0 Resolved closed
CPP11-250 Tie classes CPP 1.0b2 CPP 1.0 Closed; No Change closed
CPP11-249 Servant management rules CPP 1.0b2 CPP 1.0 Resolved closed
CPP11-248 Typos in parameter passing rules CPP 1.0b2 CPP 1.0 Resolved closed
CPP11-247 Efficiency issue in C++ mapping CPP 1.0b1 CPP 1.0b2 Resolved closed
CPP11-228 CORBA::Bounds and CORBA::TypeCode::Bounds CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-227 Read-only restrictions on parameters CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-226 C++ mapping: missing from_wchar and to_wchar CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-225 C++ mapping for IN object references CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-224 IDL generated C++ types and stream operators CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-223 Wide string allocation (2) CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-218 Why does get_principal() take an Environment parameter CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-217 POA_*_tie classes in 18.1.4 can"t be supported CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-214 Boolean type left undefined by C++ mapping CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-213 Defect with anonymus types in union mapping CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-220 Section 18.1.2: _this() and IMPLICIT_ACTIVATION need clarification CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-219 PortableServer:ObjectId_tow_wstring() and string_to_ObjectId() CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-216 Section 8.2: set_exception() supported by BOA? CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-215 Section 17..13.1 release()method should be added to mappping CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-222 Wide string allocation (1) CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-221 Bounded strings CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-212 Interpretation of _narrow semantics CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-183 Distinction between _var and _ptr types CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-182 Return value of maximum() for unbounded sequences CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-195 Sequence buffer types CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-194 Sequence lacks common features CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-185 get_principal () needs an environment parameter CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-184 Names of anonymous types CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-181 Bounded sequence problem (Section 16.11 p. 16-23) CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-180 Problem with Any::to_object memory management CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-189 C++ mapping complexity CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-188 string and objrev members of constructed types CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-191 State of release flag for sequence CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-190 Sequence implementation CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-193 References returned from sequence operator[] after realloc CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-192 Sequence maximum() call CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-187 fixed- vs. variable-length types CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-186 Implementation dependency for _var and _ptr CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-179 Any string extractor CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-178 Adding T_copy function CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-135 Potential interop. problem in CORBA 2.3: pseudo-operation marshalling CORBA 2.2 CPP 1.0 Resolved closed
CPP11-134 Clarification of OBV GIOP encoding rules CORBA 2.2 CPP 1.0 Resolved closed
CPP11-141 Mapping for wide strings CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-140 Old References in C++ mapping CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-139 Semantics of >>= operator in C++ mapping CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-153 Errors in example code for boxed struct CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-152 Object reference members, _var, and widening CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-151 98-09-03, exception inconsistency CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-150 Is SystemException supposed to be concrete? CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-149 DSI C++ issue CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-145 resolve_initial_references missing from Orb interface CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-144 Section 7.3.5 ValueBase editorial changes CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-143 C++ mapping for strings CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-142 Any and WChar issue CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-148 New C++ issue about T_out classes CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-147 from_string issue CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-146 void * functions for Any CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-138 Alias type codes in any values CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-137 Missing Mappings for Object CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-246 Signature of _narrow in exceptions CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-245 C++ issue to coordinate with proposed resolution of issue 752 CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-244 Missing text describing fixed point constant mapping CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-234 Missing constructor for Fixed CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-233 fixed_digits and fixed_scale member functions CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-243 C++ Any mapping proposed change CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-242 How to put a generic CORBA exception into an Any CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-232 macros for fixed arithmetic results CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-231 Typos on p 20-34 of orbos/98-01-11 CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-230 Fixed types in orbos/98-01-11 CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-229 CORBA::ORB::InvalidName ambigious in C++ mapping CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-238 C++ Fixed Type (03) CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-237 Fixed type (02) CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-241 _out parameter typo CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-240 Typo in orbos/98-01-11 CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-236 C++ Fixed type issue (01) CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-235 C++ mapping for fixed is broken (01) CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-239 String member initialization CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-202 Access to sequence elements CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-201 Any and IN_COPY_VALUE CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-200 operator>>= on strings and object references CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-199 A_ptr and A_var should be distinct types CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-211 Default constructor for String_var CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-210 explicit copy/adopt for String_var CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-209 TypeCode interpreter CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-208 Any release flag and operator<<= CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-205 to/from string for Any type safety CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-204 nested ptr and var types CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-197 Typo in table 3? CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-196 Sequence creation CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-207 Accessors for release flag of sequence CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-206 T_copy for string and array CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-198 _var types for fixed-length types CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-203 TypeCode mapping update for CORBA 2.) CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-165 Interface issue CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-164 Transfer of C++ codes CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-163 ORB mapping re Policy CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-169 Access to sequence buffers CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-168 Omission in union C++ mapping CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-167 Any inserters for strings need to use const pointers CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-166 C++ keyword mapping ambiguous CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-158 Extraction from Any by pointer CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-157 C++ spec uses reserved names in global namespace CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-156 string allocation functions -- description ambiguous CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-155 String sequence and allocbuff CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-154 _raise() should be const CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-160 boxed types for floating point values CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-159 Any inserters and extractors CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-162 CustomMarshal mapping type CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-161 CORBA2.3 C++ mapping for the TypeCode class (section 20.31.2) CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-172 C++ classes for modules CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-171 Defining an operator for struct/union/sequence _var types CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-170 T__alloc in C mapping CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-175 Memory Management Clarification CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-174 Union discriminators in C++ CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-173 In String Argument Passing Question CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-177 inserter and extractor functions for exceptions CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-176 Union problem CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-129 GIOP fragment alignment issue for CORBA 2.3 CORBA 2.2 CPP 1.0 Resolved closed
CPP11-128 COMM_FAILURE and completion_status CORBA 2.2 CPP 1.0 Resolved closed
CPP11-127 Typo in page 15-44 CORBA 2.2 CPP 1.0 Resolved closed
CPP11-126 CloseConnection CORBA 2.2 CPP 1.0 Resolved closed
CPP11-125 How to handle unexpected exceptions? CORBA 2.2 CPP 1.0 Resolved closed
CPP11-124 IIOP server-initiated connection closure problem CORBA 2.0 CPP 1.0 Resolved closed
CPP11-133 Move recently added text to correct place CORBA 2.2 CPP 1.0 Resolved closed
CPP11-132 OBV GIOP clarification needed CORBA 2.2 CPP 1.0 Resolved closed
CPP11-131 Tagged Component interactions CORBA 2.2 CPP 1.0 Resolved closed
CPP11-130 Obsolete text in ptc/98-08-13.pdf CORBA 2.2 CPP 1.0 Resolved closed

Issues Descriptions

Rounding and truncation of Fixed

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

    Summary: What happens if I do:

    Fixed f = "999999.999";
    Fixed f2;

    f2 = f.round(3, 1); // ???
    f2 = f.truncate(3, 1); // ???

    Should these throw DATA_CONVERSION? I think so – if we agree on this,
    the spec should state it.

  • Reported: CPP 1.0b2 — Mon, 31 Aug 1998 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    No Data Available

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

Fixed-point initialization

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

    Summary: The Fixed mapping requires throwing DATA_CONVERSION if a value has more
    than 31 integral digits:

    Fixed f = 1E32; // DATA_CONVERSION

    This raises the question of how to deal with Fixed types in environments
    without C++ exceptions. Presumably, we need to add a CORBA::Environment
    parameter everywhere. Unfortunately, that isn"t possible with the overloaded
    operators that are currently defined.

  • Reported: CPP 1.0b2 — Mon, 31 Aug 1998 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:
  • Updated: Sun, 8 Mar 2015 15:33 GMT

C++ Servants: Adding Reference counting

  • Key: CPP11-262
  • Legacy Issue Number: 1631
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The C++ mapping for the Portability Specification does not provide
    reference counting for servants. This proposal adds reference
    counting to the C++ mapping to ease memory management of
    implementations. It borrows from the C++ language mapping from the
    Objects by Value specification which does have reference counting for
    values. Specifying the reference counting calls is important so that
    both the Adapter implementation and multi-threaded application code
    can cooperate to ensure that implementations are only deleted when no
    longer used by any thread. Without specifying these calls, deadlocks
    are extremely easy to introduce into the system.

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

    No Data Available

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

mapping IDL Unicode escapes to C++

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

    Summary: The question has arisen how the new Unicode escapes that were
    introduced in the Java to IDL mapping should be mapped to C++.
    There"s nothing about this in the C++ mapping chapter.

  • Reported: CPP 1.0b2 — Mon, 5 Oct 1998 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    No Data Available

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

Mappings for hash, is_equivalent, _is_a and _non_existent

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

    Summary: The C++ mapping for CORBA::Object does not specify the mappings for
    hash, is_equivalent, is_a and non_existent methods. I am assuming
    these map to _hash, _is_equivalent, _is_a and _non_existent. Is this
    correct ?

  • Reported: CPP 1.0b1 — Mon, 19 Jan 1998 05:00 GMT
  • Disposition: Duplicate or Merged — CPP 1.0b2
  • Disposition Summary:

    duplicate of issue # 800, closed

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

Re-opening modules

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

    Summary: Is it legal to split IDL module declarations and to re-open a module similarly to what is done with C++ namespaces?

  • Reported: CPP 1.0b1 — Fri, 30 Aug 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.0b2
  • Disposition Summary:

    obsolete, cloe issue

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

"Diamond of Death" in CosLifeCycleReference

  • Key: CPP11-252
  • Legacy Issue Number: 2345
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The following MIGHT be considered an issue for CosLifeCycle and/or
    CosReference.

    The inheritance of CosReference::Relationship and
    CosCompoundLifeCycle::Relationship by CosLifeCycleReference::Relationship
    creates a "Diamond of Death" inheritance structure, in which
    CosRelationships::Relationship is inherited by two distinct paths:

    CosRelationships::Relationship
    / \
    / \
    CosReference::Relationship CosCompoundLifeCycle::Relationship
    \ /
    \ /
    CosLifeCycleReference::Relationship

  • Reported: CPP 1.0b2 — Tue, 26 Jan 1999 05:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    No Data Available

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

Typedef for ties?

  • Key: CPP11-251
  • Legacy Issue Number: 2032
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: We currently have the _ptr_type and _var_type definitions for interface
    classes. These are useful for template functions that need to deal with
    the proxy type as well as the _ptr and/or _var references.

    In a similar vein, we could add a typedef to the tie template for the
    tied object class:

    template<class T>
    class POA_A_tie : public POA_A

    { public: typedef T _tied_object_type; // <=== New // }

    ;

  • Reported: CPP 1.0b2 — Mon, 5 Oct 1998 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    No Data Available

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

Tie classes

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

    Summary: It would be nice to have a trait in the Tie classes of the class that the requests are being forwarded to. Something like this:

    template <class T>
    class POA_Foo_tie : public POA_Foo

    { public: // .... typedef T tie_object_type; }

    ;

  • Reported: CPP 1.0b2 — Mon, 28 Sep 1998 04:00 GMT
  • Disposition: Closed; No Change — CPP 1.0
  • Disposition Summary:

    No Data Available

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

Servant management rules

  • Key: CPP11-249
  • Legacy Issue Number: 1735
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Here is a list of all the POA-related operations that deal with the Servant
    type, and how I believe they need to act with respect to reference
    counting. Because there aren"t that many operations in this list, I believe
    that by spelling them out in detail rather than trying to capture their
    behavior in general rules accomplishes two things:

    1) We make it crystal clear to POA implementors and application developers
    how each operation handles reference counting for the Servants it deals
    with, and how the POA interacts with those servants.

    2) We make it clear to future maintainers of the C++ mapping for the
    PortableServer module that any new operations that deal with servants must
    have their servant reference counting semantics explicitly specified.

    Again, because there are so few operations to cover, explicitly specifying
    rules for each one is simple and precise.

  • Reported: CPP 1.0b2 — Sat, 25 Jul 1998 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    No Data Available

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

Typos in parameter passing rules

  • Key: CPP11-248
  • Legacy Issue Number: 1137
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: page 20-74 of orbos/98-01-11 shows the tables for the parameter passing
    rules. There are six notes on page 20-76 that are meant to be referenced
    by the tables. However, those references are no longer correct.

    For example, the array parameter passing rules in table 19-2 (should be
    table 20-2) have the index 2, but note 2 actually refers to the rules
    for passing references.

    Notes 3 to 6 are no longer referenced by the table, but should be.

  • Reported: CPP 1.0b2 — Mon, 30 Mar 1998 05:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    No Data Available

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

Efficiency issue in C++ mapping

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

    Summary: There is a problem with the C++ mapping which requires excessive memory copying in order to be exception safe while constructing a return value.

  • Reported: CPP 1.0b1 — Thu, 22 Aug 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.0b2
  • Disposition Summary:

    This issue was fixed by Portability Submission

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

CORBA::Bounds and CORBA::TypeCode::Bounds

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

    Summary: The C++ mapping uses a Bounds exception in the PIDL for NVList (page 17-6). This is the first time that the Bounds exception is mentioned (as far as I can see). There is no exception declaration for Bounds in the PIDL. This raises the questions:
    1) Does Bounds have data members or not?
    2) At what scope should Bounds be defined?
    Given that the Bounds exception is also used by the
    Request interface, I suspect what is meant is CORBA::Bounds.
    The TypeCode interface also uses a Bounds exception. It is explicitly
    declared in the scope of the TypeCode interface (page 17-15):
    It would be nice to only have one of these, probably CORBA::Bounds, and
    to add the missing declaration.

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

    resolved, close issue

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

Read-only restrictions on parameters

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

    Summary: A variable-length in parameter is read-only in the
    server, and a variable-length out parameter or return value is read-only
    in the client. I believe the restriction is too harsh to be useful, and the optimization
    permitted by the restriction is not worth it.

  • Reported: CPP 1.0b1 — Mon, 5 Jan 1998 05:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    Clarifying text added, fixed

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

C++ mapping: missing from_wchar and to_wchar

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

    Summary: The C++ mapping states that "wchar" is not required map onto a
    unique C++ type. Yet in 18.17.4, the mapping fails to define the
    from_wchar and to_wchar struct types and associated <<= and >>=
    operators for inserting and extract wide chars into anys. This
    also needs to be fixed in appendix A.6 of section 18.

  • Reported: CPP 1.0b1 — Tue, 2 Dec 1997 05:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    No Data Available

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

C++ mapping for IN object references

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

    Summary: According to C++ mapping spec in the POA document (table 2, section 16.18.1) the signature for an object reference in argument should be "objref_ptr", not the more likely "const objref_ptr". this is an conflict with the convention for all other in args except numeric, and is in contrast with the table 3, that specifies "const objref_var&".

  • Reported: CPP 1.0b1 — Wed, 19 Nov 1997 05:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    Duplicate of issue 188 - closed

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

IDL generated C++ types and stream operators

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

    Summary: Most ORBs provide overloaded operators to inject String_var values into ostream, istream, on ifstream. Problem: C++ does not make these operators mandatory, so every time I use one of them, I am writing non-portable and proprietary code. Nail those operators down and make them mandatory in the spec

  • Reported: CPP 1.0b1 — Wed, 24 Sep 1997 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    Fixed, requirements added

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

Wide string allocation (2)

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

    Summary: There is no statement about the terminating zero value. Is room allocated for it or not?For symmetrie with string_alloc() I suggest that wstring_alloc() also should allocate more room.

  • Reported: CPP 1.0b1 — Wed, 17 Sep 1997 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    Fixed with issue 722

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

Why does get_principal() take an Environment parameter

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

    Summary: When this IDL is mapped into C++ for a non-EH target compiler, won"t this method end up having 2 environment parameters?. This is only IDL in current spec that takes environment parameter

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

    Duplicate of issue 191 - closed

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

POA_*_tie classes in 18.1.4 can"t be supported

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

    Summary: If C++ compiler doesn"t support namespaces or templates defined inside classes, POA_*_tie classes in 18.1.4 cannot be supported within specified scopes.

  • Reported: CPP 1.0b1 — Fri, 11 Jul 1997 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    resolved, close issue

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

Boolean type left undefined by C++ mapping

  • Key: CPP11-214
  • Legacy Issue Number: 594
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: CORBA::Boolean can be mapped to totally non-sensical things such as structs, class, type double, type long etc. There are no guarantees about size of underlying type given to implementor

  • Reported: CPP 1.0b1 — Wed, 18 Jun 1997 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    resolved, close issue

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

Defect with anonymus types in union mapping

  • Key: CPP11-213
  • Legacy Issue Number: 482
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: There are some serious inconsistencies in the union mapping. Spec. (page 16-18, para4 and page 16-19, para 1) The 2 paragraphs appear to be in conflict with each other.

  • Reported: CPP 1.0b1 — Sat, 25 Jan 1997 05:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    Fixed as suggested by submitter

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

Section 18.1.2: _this() and IMPLICIT_ACTIVATION need clarification

  • Key: CPP11-220
  • Legacy Issue Number: 637
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Section states that _this() can implicitly activate servant if IMPLICIT_ACTIVATION applies. _this() does not have a way to specify which POA is to be used for the activation

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

    resolved, close issue

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

PortableServer:ObjectId_tow_wstring() and string_to_ObjectId()

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

    Summary: PortableServer::ObjectId_to_wstring() and string_to_ObjectId() are written (*in section 18.4) using the "wchar_t" type. Shouldn"t they use the CORBA::wchar type instead?

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

    Fixed in CORBA 2.2 editing process

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

Section 8.2: set_exception() supported by BOA?

  • Key: CPP11-216
  • Legacy Issue Number: 605
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The BOA interface defined a method called set_exception(). This is not present in the IDL in section 17.17. Does the BOA support this method or not?

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

    clarified

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

Section 17..13.1 release()method should be added to mappping

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

    Summary: The Object IDL contains a release() mmethod that is not mapped in the C++ mapping. This method should be added in the mapping

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

    clarified

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

Wide string allocation (1)

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

    Summary: There is no wstring_dup(). For symmetrie with string_dup(), I would suggest to create wstring_dup() as well

  • Reported: CPP 1.0b1 — Wed, 17 Sep 1997 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    closed issue, fixed

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

Bounded strings

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

    Summary: The C++ mapping basically ignores bounded strings and maps them to char* What should happen if I assign a string that is too long to a bounded string? No statement is made

  • Reported: CPP 1.0b1 — Thu, 18 Sep 1997 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    resolved, close issue

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

Interpretation of _narrow semantics

  • Key: CPP11-212
  • Legacy Issue Number: 456
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Section 16.3.4: Question on how to use _narrow with C++ bindings. Should D::_narrow work? Does answer depend on interpretation of "actual (run-time) type"?

  • Reported: CPP 1.0b1 — Sat, 16 Nov 1996 05:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    fixed, close issue

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

Distinction between _var and _ptr types

  • Key: CPP11-183
  • Legacy Issue Number: 189
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: A_var may be identical to A_ptr, so a conforming program cannot overload operations using these types solely. This may clash with statement of different behaviour between the two.

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

    fixed

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

Return value of maximum() for unbounded sequences

  • Key: CPP11-182
  • Legacy Issue Number: 185
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Return value of maximum() for unbounded sequences must be specified.

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

    resolved, close issue

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

Sequence buffer types

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

    Summary: Sec 16.11 Pg 16-23 CORBA2.0 p. 39, Sec. 3.13 para 15 Why are you passing string buffers as char ** and object references as T_ptr*. There already is a type used for overloading assignment.

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

    Addressed by resolution to issue 75

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

Sequence lacks common features

  • Key: CPP11-194
  • Legacy Issue Number: 213
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Sec 16.11 Pg 16-23 CORBA2.0 p.38,sec 3.13 para 13 There is no auto extend, no inset,append, delete. It doesn"t seem like a sequence. Seems more like a resizable array. Could call it so.

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

    Beyond scope of RTF - closed

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

get_principal () needs an environment parameter

  • Key: CPP11-185
  • Legacy Issue Number: 191
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: get principal() needs an Environment parameter, but object implementations using C++ EH do not have them. Spec should clarify this.

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

    resolved, close issue

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

Names of anonymous types

  • Key: CPP11-184
  • Legacy Issue Number: 190
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The spec does not define how anonymous types defined within constructed types should be named (as the C mapping does)

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

    Duplicate of issue 52

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

Bounded sequence problem (Section 16.11 p. 16-23)

  • Key: CPP11-181
  • Legacy Issue Number: 178
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: "Default constructor for a bounded sequence always allocates a contents vector.."-> Bad effect for sequences such as CORBA::ReferenceDatawhich allocates 1024 octets of storage

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

    resolved, close issue

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

Problem with Any::to_object memory management

  • Key: CPP11-180
  • Legacy Issue Number: 154
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Section 16.14.5-implies that a CORBA::Object reference extracted from Any must share memory with actual interface stored in Any.Better: results of Any::to_object require explicit release()

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

    resolved, close issue

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

C++ mapping complexity

  • Key: CPP11-189
  • Legacy Issue Number: 207
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: [Sec 16.9 Pg 16-15 CORBA2.0 p. 32, Sec. 3.11 A comment nothing can be done about at thisstage. This section is way too complex. Goal is not to be natural C++ programmers !!!!

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

    Beyond scope of RTF - closed

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

string and objrev members of constructed types

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

    Summary: Implementation dependent: Type of string & object reference members of struct, union, sequence

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

    Withdrawn by submitter

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

State of release flag for sequence

  • Key: CPP11-191
  • Legacy Issue Number: 210
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Sec 16.11 Pg 16-22 CORBA2.0 If release is FALSE under these circumstances, old storage will not be freed before reallocation is performed. After realloc release TRUE or FALSE?

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

    Addressed by resolution to issue 75

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

Sequence implementation

  • Key: CPP11-190
  • Legacy Issue Number: 209
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: {sec 16.11 Pg 16-22 CORBA2.0 p.38, Sec 3.13 para 7: Must an implementation REALLY implement a sequence as a contigous chunk of memory?

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

    Addressed by resolution to issue 75

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

References returned from sequence operator[] after realloc

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

    Summary: Sec 16.11 Pg 16-23 CORBA2.0 What happens to refs returned by operator[] when a realloc occurs? Are these invalid?

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

    clarified

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

Sequence maximum() call

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

    Summary: Sec 16.11 Pg 16-22 CORBA2.0 p.38 Section 3.13 para11: It"s not clear how maximum()call is supposed to be used.

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

    Duplicate of issue 185 - closed

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

fixed- vs. variable-length types

  • Key: CPP11-187
  • Legacy Issue Number: 200
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Sec 16.8 Pg 16-22 CORBA2.0, p. 28, Section 3.10, para 2: Devastating to programmers. Simple change to IDL an IDL file will require a complete rewrite of application code

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

    Duplicate of issue123

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

Implementation dependency for _var and _ptr

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

    Summary: Implementation dependent: Implementation scheme for Interface _var & _ptr types

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

    Duplicate of issue189

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

Any string extractor

  • Key: CPP11-179
  • Legacy Issue Number: 150
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Does the Any string extractor (>>=) return a pointer that is still managed by the Any or a copy? The spec appears to be silent about this.

  • Reported: CPP 1.0b1 — Wed, 2 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    Clarifying text added

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

Adding T_copy function

  • Key: CPP11-178
  • Legacy Issue Number: 148
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: It would be useful if the C++ mapping for IDL arrays also generated a T_copy() function to go along with T_alloc(), T_dup(), and T_free().

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

    Fixed as suggested by submitter

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

Potential interop. problem in CORBA 2.3: pseudo-operation marshalling

  • Key: CPP11-135
  • Legacy Issue Number: 2338
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Existing CORBA 2.2 compatible CORBA clients will fail when invoking
    the non_existent pseudo-operation with a compliant CORBA 2.3 server.
    We have observed this problem in practice with at least one other
    commercial Java ORB, who changed from the Corba 2.2 marshalling to the
    Corba 2.3 marshalling when they changed the version of their product,
    thereby breaking our existing customer"s code.

    Section 15.4.1.2 (p. 15-31) of ptc/98-12-04 CORBA 2.3a defines the CDR
    marshalling for pseudo-operation non_existent in Object
    pseudo-interface to be _non_existent. The spec is worded in such a way
    that it implies that this marshalling applies for all GIOP clients,
    not just GIOP 1.2 client

    However, p. 13-23 of the CORBA 2.2 specification defines the mapping
    of the same pseudo-operation as _not_existent.

  • Reported: CORBA 2.2 — Fri, 22 Jan 1999 05:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    see below

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

Clarification of OBV GIOP encoding rules

  • Key: CPP11-134
  • Legacy Issue Number: 2326
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The last sentence of section 15.3.7 "The abstract encoding of value type
    always includes RepositoryId information." needs to appear somewhere in
    section 15.3.4.1.

  • Reported: CORBA 2.2 — Thu, 21 Jan 1999 05:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    see above

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

Mapping for wide strings

  • Key: CPP11-141
  • Legacy Issue Number: 1384
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: the spec doesn"t say what the type CORBA::WChar should map to. Presumably,
    it should be wchar_t? If so, I think this should be stated.

    It is important to nail this down because of overloading ambiguities. For
    example, if CORBA::WChar * is allowed to be the same as char *, then
    we cannot use the overloaded <<= operator to insert unbounded wide strings
    into an Any.

  • Reported: CPP 1.0b1 — Tue, 19 May 1998 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    Fix the mapping to specify what WChar maps to.

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

Old References in C++ mapping

  • Key: CPP11-140
  • Legacy Issue Number: 1095
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: orbos/98-01-11 contains some stale references. For example, on page 20-18:

    ...
    private:
    // hidden assignment operators for var types to
    // fulfill the fules specified in
    // Section 19.3.2
    };

    The definition for the A_out type is the same as the one shown
    in Section 19.3.6.

    These should now refer to Section 20.

  • Reported: CPP 1.0b1 — Mon, 23 Mar 1998 05:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    Close without change. Already fixed.

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

Semantics of >>= operator in C++ mapping

  • Key: CPP11-139
  • Legacy Issue Number: 932
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: According to the IIOP protocol specification, it is possible to receive
    an any with a TypeCode which doesn"t include names, member names and
    repository ids.
    However, it is not clear what the behaviour of the >>= operator is in the C++
    mapping for these cases. What happens if I receive an any value from
    a remote ORB which didn"t encode names, member names and repository ids ? Is
    it posible to extract its value using the so-called "type-safe" operator >>= ?

  • Reported: CPP 1.0b1 — Wed, 28 Jan 1998 05:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    closed with no change

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

Errors in example code for boxed struct

  • Key: CPP11-153
  • Legacy Issue Number: 2226
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: On page 82 in 98-09-03 (Nov 6 1998), the sample code for a boxed
    struct is using the type "BoxedS" where "S" should be used.
    Specifically, the _value() and _boxed_XXX() functions.

  • Reported: CPP 1.0b1 — Fri, 20 Nov 1998 05:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    Modify the sample code as indicated.

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

Object reference members, _var, and widening

  • Key: CPP11-152
  • Legacy Issue Number: 2215
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: I recently encountered an issue regarding the assignment of
    Object_vars (shorthand for any object reference _var) to object
    reference members. While the spec explicitly forbids implicit widening
    when assigning Object_vars, it does not explicitly forbid it when
    assigning object reference members.

  • Reported: CPP 1.0b1 — Mon, 16 Nov 1998 05:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    Clarify the text

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

98-09-03, exception inconsistency

  • Key: CPP11-151
  • Legacy Issue Number: 2097
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: In 98-09-03, SystemException has a pure virtual _raise() member
    (Section 20.18). That member is not shown in Section 20.40.8.

    Also, I think UserException also should have the pure virtual _raise()
    member, but neither the text in Section 20.18 nor the summary in
    Section 20.40.9 shows it.

  • Reported: CPP 1.0b1 — Mon, 19 Oct 1998 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    Close as duplicate of 1923.

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

Is SystemException supposed to be concrete?

  • Key: CPP11-150
  • Legacy Issue Number: 1923
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The CORBA 2.2 C++ binding has the SystemException class defined as a
    concrete class, because it redefines _raise() as a non-pure virtual.

    This seems to be a bad idea to me. It would be better to leave _raise()
    as a pure virtual so that SystemException cannot be instantiated. This
    prevents accidental programming errors in catching SystemExceptions by
    value, which slices off the real exception type.

  • Reported: CPP 1.0b1 — Wed, 2 Sep 1998 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    Add pure virtual _raise functions to CORBA::SystemException and CORBA::UserException.

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

DSI C++ issue

  • Key: CPP11-149
  • Legacy Issue Number: 1777
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Section 20.36.1, page 20-118 of orbos/98-07-12 says:

    "Similarly, data allocated by the DIR and handed to the ORB (the NVList
    parameters, the result value, and exception values) are freed by the ORB
    rather
    than by the DIR."

    However, the signatures for the set_result() and set_exception() functions of
    ServerRequest take arguments of type const Any&. How can the ORB adopt the
    result and exception data from a const Any? Unless I am missing something,
    either these signatures have to be changed to Any&, or the quoted sentence has
    to change to remove the text "the result value, and exception values".

  • Reported: CPP 1.0b1 — Wed, 5 Aug 1998 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    Change the text as suggested.

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

resolve_initial_references missing from Orb interface

  • Key: CPP11-145
  • Legacy Issue Number: 1686
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Are you looking at CORBA 2.2, document orbos/98-02-01?

    Section 20.31.4 covers ORB_init and friends. The POA is an ordinary IDL
    interface that just follows the ordinary C++ mapping rules, so it needs no
    special mention. The C++ server side is explained in 20.33 through 20.38.

    You are correct that resolve_initial_references is missing from the ORB
    interface. This was because it used to be covered in another section, and
    it appears to have been inadvertantly dropped by the editors at the OMG.
    Juergen, this should be logged as a cxx_revision issue. However,
    resolve_initial_references just follows the regular C++ mapping rules, so
    there"s really no harm in it being missing.

  • Reported: CPP 1.0b1 — Wed, 15 Jul 1998 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    Add the missing text.

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

Section 7.3.5 ValueBase editorial changes

  • Key: CPP11-144
  • Legacy Issue Number: 1657
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The C++ language mapping for ValueBase is missing return
    values on _add_ref and _remove_ref.

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

    Fix the code.

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

C++ mapping for strings

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

    Summary: The C++ mapping requires that strings are to be mapped to char *.

    Unfortunately, with ANSI C++ compilers, this creates problems if
    string literals are involved.

  • Reported: CPP 1.0b1 — Tue, 30 Jun 1998 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • 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 and WChar issue

  • Key: CPP11-142
  • Legacy Issue Number: 1386
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The C++ mapping requires that attempt to insert a Boolean, Octet, or
    Char value into an any must generate a compile-time error:

    CORBA::Any a;
    CORBA::Char c = "x";
    a <<= c; // Compile-time error

    The spec says nothing about WChar and WChar *. This implies that no such
    guarantee exists. However, I don"t think it would hurt to spell this out:

    CORBA::Any a;
    CORBA::WChar wc = L"x";
    a <<= wc; // Undefined behavior

  • Reported: CPP 1.0b1 — Tue, 19 May 1998 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    closed, fixed

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

New C++ issue about T_out classes

  • Key: CPP11-148
  • Legacy Issue Number: 1776
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary:
    In 20.9.2, the T_out class has a copy constructor and assignment
    operator that take non-const references to a T_out argument. These
    should be changed to const references instead because the T_out class
    still works correctly with the change, and many compilers issue errors
    or warnings about non-const references arguments bound to temporary
    values.

  • Reported: CPP 1.0b1 — Wed, 5 Aug 1998 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    fixed, issue closed

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

from_string issue

  • Key: CPP11-147
  • Legacy Issue Number: 1747
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The latest C++ mapping (document orbos/98-05-08) defines the
    Any::from_string type as

    struct from_string {
    from_string(char* s, ULong b, Boolean nocopy = FALSE) : val(s),
    bound(b) {}
    ...
    };

    In ANSI C++, this disallows the following code:

    any <<= Any::from_string("string literal");

    This is because string literals in ANSI C++ are const char[], not char[].
    Therefore, from_string should have an additional constructor to allow
    insertion of a const char* as well.

  • Reported: CPP 1.0b1 — Tue, 28 Jul 1998 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    Close as duplicate of 2453.

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

void * functions for Any

  • Key: CPP11-146
  • Legacy Issue Number: 1700
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The mapping for Any currently requires:

    Any(TypeCode_ptr tc, void *value, Boolean release = FALSE);
    void replace(TypeCode_ptr tc, void *value, Boolean release = FALSE);
    const void *value() const;

    The meaning of the void * parameters is never defined (and cannot ever
    be defined because it would have to mandate a particular binary layout).

    This means these three functions have completely undefined semantics. Even
    for basic types, such as CORBA::Long, I cannot assume that the void *
    will point directly at the long value, because the mapping implementation
    is free to make the pointer point at some other value internal to an Any.

    Proposal: Remove these three functions from the mapping. If vendors want
    to retain them for backward compatibility reasons, they can.
    However, functions with completely undefined semantics that are
    inherently non-portable have no place in a standard mapping.

  • Reported: CPP 1.0b1 — Mon, 20 Jul 1998 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    Leave the original text in place. Add a sentence saying that DynAny should be used instead.

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

Alias type codes in any values

  • Key: CPP11-138
  • Legacy Issue Number: 801
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: I believe the spec should be updated to explicitly require the following
    to be safe: a1.replace(a1.type(), a1.value(), false);
    In other words, an Any should be obliged to detect assignment to self
    for the passed void *. Reason: The above is the only way I can see
    to get a tk_alias type code into an any, so the receiver can tell the
    difference between a date and an address.

  • Reported: CPP 1.0b1 — Fri, 12 Dec 1997 05:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    Close issue with no change – already resolved in section 20.16.8.

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

Missing Mappings for Object

  • Key: CPP11-137
  • Legacy Issue Number: 800
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The C++ mapping currently lack mappings for is_a(), is_equivalent(),
    hash(), and non_existent(). These need to be added. The question is, which of these operations can validly be invoked on
    a nil reference, because that affects the mapping. My thinking is that
    all of these should be allowed for nil references.

  • Reported: CPP 1.0b1 — Fri, 5 Dec 1997 05:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    closed with no change

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

Signature of _narrow in exceptions

  • Key: CPP11-246
  • Legacy Issue Number: 1937
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The mapping shows the signature for the _narrow static member
    functions in exceptions as

    static SystemException * _narrow(Exception *);

    I think we should change this to

    static SystemException * _narrow(const Exception *);

    Otherwise, I cannot catch an exception as const and then narrow it
    without a cast.

  • Reported: CPP 1.0b1 — Mon, 7 Sep 1998 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    No Data Available

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

C++ issue to coordinate with proposed resolution of issue 752

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

    Summary: In coordination with the proposed resolution to the ORB Portability RTF
    Issue #752, add the following operations to PortableServer::ServantBase
    in section 20.34.1:

    class ServantBase

    { ... public: ... virtual InterfaceDef_ptr _get_interface() throw(SystemException); virtual Boolean _is_a(const char * logical_type_id) throw(SystemException); virtual Boolean _non_existent() throw(SystemException); ... }

    ;

    and change the last paragraph of section 20.34.1 to:

    The default implementation of the _default_POA() function provided by
    ServantBase returns an object reference to the root POA of the default
    ORB in this process — the same as the return value of an invocation of
    ORB::resolve_initial_references("RootPOA") on the default ORB. Classes
    derived from ServantBase can override this definition to return the POA
    of their choice, if desired.

    and add the following text at the end of section 20.34.1:

    ServantBase provides default implementations of the _get_interface(),
    _is_a(), and _non_existent() standard object reference operations that
    can be overridden by the object implementation if the default behavior
    is not adequate. These functions are called just like normal skeleton
    operations by the POA, so the programmer can use _this() and and the
    PortableServer::Current interface in the function bodies.

    The default implementation of the _get_interface() and _is_a() functions
    provided by ServantBase uses the interface associated with the skeleton
    class if it is static to determine its return value. If the skeleton is
    dynamic (see 20.36) it uses the _primary_interface() function to
    determine its return value.

    The default implementation of the _non_existent() function simply
    returns false.

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

    :ServantBase

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

Missing text describing fixed point constant mapping

  • Key: CPP11-244
  • Legacy Issue Number: 1538
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: There is no text in the C++ language mapping that describes how to map a
    fixed point constant declaration.

  • Reported: CPP 1.0b1 — Tue, 23 Jun 1998 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    No Data Available

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

Missing constructor for Fixed

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

    Summary: Type Fixed has constructors for LongDouble and int. This causes
    a few initialization problems. For example:

    Fixed<8,2> x = 6.75;
    Fixed<8,2> y = 10L;
    Fixed<8,2> z = 10U;

    None of these will compile because of the ambiguity as to whether to use
    the int or the LongDouble constructor.

    I think Fixed will need additional constructors to allow initialization
    from float, double, long and unsigned values.

  • Reported: CPP 1.0b1 — Thu, 19 Mar 1998 05:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:
  • Updated: Fri, 6 Mar 2015 20:58 GMT

fixed_digits and fixed_scale member functions

  • Key: CPP11-233
  • Legacy Issue Number: 1072
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Page 20-34 of CORBA 2.2 shows member functions of the Fixed template:

    CORBA::UShort fixed_digits() const;
    CORBA::Short fixed_scale() const;

    There are no semantics specified for these. I assume they return the
    number of the respective digits passed to the template? For example, given

    Fixed<5,2> x;

    assert(x.fixed_digits() == 5);
    assert(x.fixed_scale() == 2);

    Is this the correct interpretation? If so, the spec should say so (otherwise,
    I might, for example, expect that fixed_digits returns 3 and fixed_scale
    return 2).

  • Reported: CPP 1.0b1 — Thu, 19 Mar 1998 05:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    No Data Available

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

C++ Any mapping proposed change

  • Key: CPP11-243
  • Legacy Issue Number: 1319
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Add the following operation to CORBA::Any:

    class Any

    { ... void type(TypeCode_ptr); ... }

    ;

    This will replace the internal typecode in the any with the specified
    typecode. If the new typecode is not equivalent to the old typecode (as
    defined by TypeCode::equivalent), then implementation will raise the
    BAD_TYPECODE system exception.

  • Reported: CPP 1.0b1 — Tue, 12 May 1998 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    No Data Available

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

How to put a generic CORBA exception into an Any

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

    Summary: There doesn"t appear to be any way to place an arbitrary exception into
    an Any with the current C++ mapping. This is necessary to make the DSI
    usefulThe spec needs to be extended to provide an inserter function to insert
    a CORBA::Exception into an Any. I know that this has potential issue
    for the inserter function to determine the correct typecode for the
    exception, but I can"t think of any other way to get an exception into
    the Any when all I"ve got is a CORBA::Exception * without having to
    enumerate each possible exception by calling _narrow.

  • Reported: CPP 1.0b1 — Wed, 29 Apr 1998 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    No Data Available

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

macros for fixed arithmetic results

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

    Summary: The fixed mapping says on page 20-35 of orbos/98-01-11:

    One way to do this is to declare the result types with a macro
    that evaluates to the approate values, based on the digits and
    scale of the operands:

    // Example of Fixed result type declaraction
    // Fixed<_FIXED_ADD_TYPE(d1,s1,d2,s2)> -> Fixed<dr,sr>

    I think the name of the macro for each rule needs to be nailed down.

  • Reported: CPP 1.0b1 — Wed, 18 Mar 1998 05:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    No Data Available

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

Typos on p 20-34 of orbos/98-01-11

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

    Summary: page 20-34 of orbos/98-01-11 contains a few typos:

    1)
    template<CORBA::UShort d, Short s>

    should be

    template<CORBA::UShort d, CORBA::Short s>

    2)
    operator LongDouble() const;

    should be

    operator CORBA::LongDouble() const;

    3)

    template<unsigned short d1, short s1, unsigned short d2, short s2)

    should use CORBA types and use a closing ">" instead of ")":

    template<
    CORBA::UShort d1,
    CORBA::Short s1,
    CORBA::UShort d2,
    CORBA::Short s2
    > // Note closing ">"

  • Reported: CPP 1.0b1 — Wed, 18 Mar 1998 05:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    No Data Available

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

Fixed types in orbos/98-01-11

  • Key: CPP11-230
  • Legacy Issue Number: 1056
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: On page 20-36, near the top, the mapping says:

    A T_out type for a Fixed type is defined as typedef to a
    reference to the Fixed type, with the digits and scale added to
    the name to disambiguate it. For example, the name of the T_out
    type for the type Fixed<5,2> is Fixed_5_2_out:

    // C++
    typedef Fixed<5, 2>& Fixed_5_2_out;

    This doesn"t appear to work for fixed types with negative scale. For example:

  • Reported: CPP 1.0b1 — Tue, 17 Mar 1998 05:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    No Data Available

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

CORBA::ORB::InvalidName ambigious in C++ mapping

  • Key: CPP11-229
  • Legacy Issue Number: 933
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: In section 5.6:

    // PIDL
    module CORBA {
    interface ORB {
    exception InvalidName {};
    };
    };

    In section A.24:

    // C++
    class ORB {
    public:
    class InvalidName

    {...}

    ;
    };

    The C++ mapping should be clarified to show that this is indeed a user
    exception.

  • Reported: CPP 1.0b1 — Fri, 30 Jan 1998 05:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    No Data Available

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

C++ Fixed Type (03)

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

    Summary: 3) Page 20-35: the +=, -=, *=, and /= operators are required by the
    C++ language to be member functions, not global functions. They
    should be moved into the Fixed class and should return a reference to
    *this, not a value.

  • Reported: CPP 1.0b1 — Tue, 31 Mar 1998 05:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    No Data Available

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

Fixed type (02)

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

    Summary: 2) Page 20-35: the semantics of the istream extraction and ostream
    insertion functions are totally unspecified – what formats are used
    to read and write Fixed types?

  • Reported: CPP 1.0b1 — Tue, 31 Mar 1998 05:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    No Data Available

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

_out parameter typo

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

    Summary: orbos/98-01-11 contains a typo on page 20-20.

    The last line of Table 19-1 shows CORBA::Octet in the "C++ Out Type"
    column. This should be CORBA::Octet_out instead.

  • Reported: CPP 1.0b1 — Fri, 17 Apr 1998 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    No Data Available

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

Typo in orbos/98-01-11

  • Key: CPP11-240
  • Legacy Issue Number: 1148
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Page 20-74, para 1:

    ... original specified except the first oneA caller is ...

    Should be

    ... original specified except the first one. A caller is ...

  • Reported: CPP 1.0b1 — Fri, 17 Apr 1998 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    No Data Available

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

C++ Fixed type issue (01)

  • Key: CPP11-236
  • Legacy Issue Number: 1124
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: 1) Page 20-34: the unary + and - operators in the Fixed class should
    return by value, not by reference.

  • Reported: CPP 1.0b1 — Tue, 31 Mar 1998 05:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    No Data Available

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

C++ mapping for fixed is broken (01)

  • Key: CPP11-235
  • Legacy Issue Number: 1092
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: 1. If the C++ target environment does not support namespaces and/or
    nested template class definitions, then it is impossible to implement
    the Fixed template type as part of the CORBA module.

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

    No Data Available

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

String member initialization

  • Key: CPP11-239
  • Legacy Issue Number: 1128
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: orbos/98-01-11 doesn"t initialize string members if they are inside
    a sequence or array.

    For consistency, it would be better to adopt the following:

    • A plain String_var is default-constructed to contain a
      null pointer (like all other _var types).
    • If a structure, exception, sequence, or array contains
      a string, that string is initialized to the empty string
      when default-constructed. In case of a sequence of strings,
      this means that strings are default-constructed to the
      empty string when the sequence is extended.
  • Reported: CPP 1.0b1 — Wed, 1 Apr 1998 05:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    No Data Available

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

Access to sequence elements

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

    Summary: At present sequence elements can only be accessed through operator[]. Public accessors be provided to allow a sequence to simultaneously be viewed as alinked list.

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

    Duplicate of issue 75 - closed

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

Any and IN_COPY_VALUE

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

    Summary: Binding spec states that implementation af Any must not store its value as reference or pointer to value passed into insertion operator <<= Any return pointer must not be NULL pointer...

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

    clarifying text added

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

operator>>= on strings and object references

  • Key: CPP11-200
  • Legacy Issue Number: 236
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Sec 16.12.2 Pg 16-27 CORBA2.0 Sun wants to add para.: Extraction operator>>= doesn"t free old storage, doesn"t pass old string to string_free, doesn"t invoke release on old object reference.

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

    Clarifying text added

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

A_ptr and A_var should be distinct types

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

    Summary: Sec 16.2.1 Pg 16-4 CORBA2.0 A_ptr and A_var need not be distinct. Since these types have distinct semantics, they need to be distinct (Section 3.5.1 para 4)

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

    Duplicate of issue 189 - closed

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

Default constructor for String_var

  • Key: CPP11-211
  • Legacy Issue Number: 269
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: C++ mapping currently specifies that the default constructor for CORBA::String_var initializes the string to NULL Pointer. This is very inconvenient, in particular for structures

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

    Fixed as suggested by submitter

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

explicit copy/adopt for String_var

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

    Summary: Copying + adopting performed by String_var::operator= are very error-prone.Better to have explicit functions to copy, adopt,reference.(e.g void String_var::copy(const char*);

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

    handled by Portability submission - closed

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

TypeCode interpreter

  • Key: CPP11-209
  • Legacy Issue Number: 262
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Sec 4.10 describes mapping for TypeCode. Sun proposes the following typecode interpreter interface: (available in /archives/issues/issue261)

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

    Fixed with issue 251

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

Any release flag and operator<<=

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

    Summary: Sec 3.16.2 para 11 describes lifetime of inserted value. Any should take over the inserted value(Sun) Avoids unnecessary copy for structured types listed in table 2

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

    requested functionality added

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

to/from string for Any type safety

  • Key: CPP11-205
  • Legacy Issue Number: 249
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: We sure could use any_to/from_string<nnn> classes so that the type safe any api could be used for all IDL types

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

    Requested functionality added

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

nested ptr and var types

  • Key: CPP11-204
  • Legacy Issue Number: 248
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: ptr and var types for objrefs should be nested inside interface class, e.g A::ptr and A::var. Would make writing templates using these types easier.

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

    resolved, close issue

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

Typo in table 3?

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

    Summary: Pg 16-46 table 24 CORBA2.0 Shouldn"t arrays be by & for inout? This looks like a typo.

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

    clarified

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

Sequence creation

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

    Summary: Sec 16.11.2 Pg 16-25 CORBA2.0 How do I know how sequence was created. Must my code carry arround an extra piece of information saying how sequence was created?

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

    clarified

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

Accessors for release flag of sequence

  • Key: CPP11-207
  • Legacy Issue Number: 256
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Sec 3.13.describes mapping for sequence.Accessor functions should be provided for release flag.Add following member functions: void release(Boolean), Boolean release() --pure accessors

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

    Duplicate of issue 75 - closed

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

T_copy for string and array

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

    Summary:

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

    Duplicate of issue 148 - closed

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

_var types for fixed-length types

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

    Summary: As a convenience for managing this pointer, the mapping also provides another class of each variable-length type. It also provides one for fixed-length types. You should say so

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

    clarified

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

TypeCode mapping update for CORBA 2.)

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

    Summary: It seems that the TypeCode mapping needs to be updated to reflect the TypeCode definition in Interface Repository Spec (p 64)

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

    TypeCode interface updated

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

Interface issue

  • Key: CPP11-165
  • Legacy Issue Number: 2376
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The interface between application programmer and CORBA components (BOA, stubs, skeletons etc.) should be as simple as possible (but, naturally, not more simple). I am afraid, that introduction of the new classes to C++ mapping like A_out is not the best way to simplify their life to the creators of the final applications - the application programmers. It is naturally, when creator of the CORBA implementation use very advanced and sophisticated constructions of the programming language, but let he/she left application creators their invention to study application problems, not those advanced features of the programming environment. How many application programmers understand well such construction like "reference to pointer"?
    Naturally, if the new constructions would bring some new principal features to the problem, they may be accepted, but I am afraid, that the only reason of the A_out class is to ensure freeing of memory occupied by the old data of the corresponding variables. But the same service may be done by the first statement of the (generated) stub.

  • Reported: CPP 1.0b1 — Tue, 2 Feb 1999 05:00 GMT
  • Disposition: Resolved — CPP 1.0
  • 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

Transfer of C++ codes

  • Key: CPP11-164
  • Legacy Issue Number: 2375
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: During my study of the specification CORBA 2.2, I tried to transfer C++ codes on pages 20-12, 20-13 and 20-11 to the C++ source, add some dummy declarations and definitions of such classes as Object and tried to compile it. I obtained error message from the definition of the constructor A_out::A_out(A_var& p) : ptr_(p.ptr_) ... due to unauthorized access to protected member A_var::ptr_. This was no conceptual problem to introduce access function A_var::ptr() in similar manner like has been introduces function A_out::ptr() and correct the problem, another way is definition of some classes as friend ... . But my reliance to document containing such mistakes was lost. Please, can you pay more attention to testing and preparing of the concluding documents?

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

    Closed without change

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

ORB mapping re Policy

  • Key: CPP11-163
  • Legacy Issue Number: 2355
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: 1. ORB pidl on 20-130 of ptc/98-09-03 is missing the create_policy
    pseudo-operation.

    2. Sometimes I think the traditional style of PIDL mapping used for the Java,
    C++, and draft Lisp mappings, wherein each PIDL pseudo-operation is
    explicitly listed in each mapping, is risky - insofar as version
    mismatches between the Core Pseudo-IDL and the pseudo-IDL used in the
    mapping document can and frequently do arise.

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

    Add the missing operation.

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

Access to sequence buffers

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

    Summary: We would like to see an enhancement which allows access to sequence buffers once they have been constructed.

  • Reported: CPP 1.0b1 — Tue, 13 Aug 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    Fixed

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

Omission in union C++ mapping

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

    Summary: Several problems exist with the definition of union constructors.

  • Reported: CPP 1.0b1 — Thu, 11 Jul 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    fixed by adding clarifying text

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

Any inserters for strings need to use const pointers

  • Key: CPP11-167
  • Legacy Issue Number: 2453
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The inserter helper functions for string and wstring on type Any should
    have const pointers as the constructor parameter, otherwise I can"t
    insert string literals with an ANSI C++ compiler.

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

    Make the suggested fixes.

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

C++ keyword mapping ambiguous

  • Key: CPP11-166
  • Legacy Issue Number: 2443
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The last para of section 20.1.2 says:

    To avoid C++ compilation problems, every use in OMG IDL of a
    C++ keyword as an identifier is mapped into the same name preceded
    by the prefix "cxx". For example, an IDL interface named
    "try" would be named "_cxx_try" when its name is mapped into C++.

    This is ambiguous because it doesn"t make it clear what the names of types
    derived from that interface shold be.

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

    Clarify the text.

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

Extraction from Any by pointer

  • Key: CPP11-158
  • Legacy Issue Number: 2335
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: the mapping currently specifies that for char * and WChar *, the following
    extraction operators must be defined on type Any:

    class Any

    { Boolean operator>>=(const Any &, char * &); Boolean operator>>=(const Any &, WChar * &); // ... }

    ;

    For user-defined complex types and other variable-length types, the mapping
    requires:

    class Any

    { Boolean operator>>=(const Any &, T * &); // ... }

    ;

    This means that a conforming ORB need not compile the following:

    CORBA::Any a = ...;
    const char * p;
    a >>= p; // No matching operator

    This is a Bad Thing (TM), in my opinion. The reason is that when I extract
    something by pointer, first, the Any retains ownership and, second,
    I must treat the pointed-to memory as read-only.

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

    fixed, issue closed

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

C++ spec uses reserved names in global namespace

  • Key: CPP11-157
  • Legacy Issue Number: 2288
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The C++ language mapping generates typecode names for global IDL type
    definitions that start with an underscore. The C++ standard reserves
    global symbols that start with an underscore for the compiler
    implementation. We need to resolve this conflict.

  • Reported: CPP 1.0b1 — Tue, 29 Dec 1998 05:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    Close with no change

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

string allocation functions -- description ambiguous

  • Key: CPP11-156
  • Legacy Issue Number: 2286
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: the text for string_alloc et al. says:

    The string_alloc function dynamically allocates a string,
    or returns a null pointer if it cannot perform the allocation.

    [ ... ]

    The string_alloc, string_dup, and string_free functions may not
    throw CORBA exceptions.

    I think the second sentence is a little misleading. What is meant is that
    these functions cannot throw any exceptions at, not that they won"t throw
    CORBA excecptions but are allowed to throw others, such as bad_alloc.

    I suggest to change the second sentence to read:

    The string_alloc, string_dup, and string_free functions may not
    throw exceptions.

  • Reported: CPP 1.0b1 — Thu, 24 Dec 1998 05:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    Clarify the text.

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

String sequence and allocbuff

  • Key: CPP11-155
  • Legacy Issue Number: 2234
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The allocbuf function allocates a vector of T elements that can be
    passed to the T
    *data constructor and to the replace() member function. The length of
    the vector
    is given by the nelems function argument. The allocbuf function
    initializes each
    element using its default constructor, except for strings and wide
    strings, which are
    initialized to null pointers, and object references, which are
    initialized to suitably-typed
    nil object references. A null pointer is returned if allocbuf for some
    reason
    cannot allocate the requested vector.

    Since in the latest mapping the elements of string sequences are now
    initialized as empty strings, wouldn"t it be more logical if allocbuf
    would also initialize the elements of the returned string vector with
    empty strings instead of null pointers?

  • Reported: CPP 1.0b1 — Tue, 1 Dec 1998 05:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    closed

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

_raise() should be const

  • Key: CPP11-154
  • Legacy Issue Number: 2231
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The CORBA::Exception::_raise() virtual member function should have the
    const qualifier. Since it effectively throws a copy of the exception,
    there isn"t any reason why you shouldn"t be able to call it on a const
    Exception.

  • Reported: CPP 1.0b1 — Tue, 1 Dec 1998 05:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    Make _raise a const member function.

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

boxed types for floating point values

  • Key: CPP11-160
  • Legacy Issue Number: 2350
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: In ptc/98-08-03 p.20-80:

    For all the integer types, boolean, octet, char, wchar and
    enumerated types, value box classes provide.

    1. The phrase "integer types" should presumably read "integer types except for
    fixed" in view of the separate mapping for fixed type on p. 20-85. It
    is true that "integer type" can mean signed_int or unsigned_int, in
    contexts such as Corba 2.3a grammar, but the phrase here seems
    potentially ambigous.

    2. The phrase should be extended to include floating point types
    (including float, double, and long double).

  • Reported: CPP 1.0b1 — Thu, 28 Jan 1999 05:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    Clarify the text.

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

Any inserters and extractors

  • Key: CPP11-159
  • Legacy Issue Number: 2346
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: the 1.4 version of the C++ mapping has an internal inconsistency. In
    sections 20.16.2 and 20.16.3, the inserters and extractors for built-in
    types that don"t require a from_* or to_* helper class are shown
    as non-member functions of type Any.

    However, section 20.39.5 shows the the inserters and extractors as
    member functions of type Any.

    Section 20.39.5 is wrong and needs be updated to reflect the signatures
    in 20.16.

  • Reported: CPP 1.0b1 — Wed, 27 Jan 1999 05:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    closed issue

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

CustomMarshal mapping type

  • Key: CPP11-162
  • Legacy Issue Number: 2354
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: ptc/98-09-03, p. 20-96: In "The C++ mappings for the IDL
    CORBA::CustomerMarshal..." change Customer to Custom.

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

    Fix the typo.

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

CORBA2.3 C++ mapping for the TypeCode class (section 20.31.2)

  • Key: CPP11-161
  • Legacy Issue Number: 2351
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Issue: The CORBA2.3 C++ mapping for the TypeCode class
    (section 20.31.2) has not been updated.

    Suggested Resolution: Add get_compact_typecode() and valuetype/
    valuebox operations. Also, remove the param_count and parameter
    methods which were deprecated in CORBA2.2 and eliminated in
    CORBA2.3.

  • Reported: CPP 1.0b1 — Thu, 28 Jan 1999 05:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    This issue has already been resolved.

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

C++ classes for modules

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

    Summary: Does the standard require an implementation to use C++ classes for modules if there is no namespace support? Or is it simply a suggestion?

  • Reported: CPP 1.0b1 — Tue, 3 Sep 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    clarified

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

Defining an operator for struct/union/sequence _var types

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

    Summary: If no operator *() is defined for struct, union, or sequence _var types, some pieces of code will break.

  • Reported: CPP 1.0b1 — Thu, 29 Aug 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    withdrawn by submitter

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

T__alloc in C mapping

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

    Summary: Is it intended that use of T__alloc functions are the only conformant way to allocate values of (variable length) type T? Or can a conformant app also declare them on the stack?

  • Reported: CPP 1.0b1 — Tue, 27 Aug 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    clarified

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

Memory Management Clarification

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

    Summary: Should fields of a struct persist across a deep copy?

  • Reported: CPP 1.0b1 — Fri, 6 Sep 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    No Data Available

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

Union discriminators in C++

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

    Summary: Is a modifier function required under the C++ mapping of unions, and if it is, can it be used to set the discriminator to an illegal value?

  • Reported: CPP 1.0b1 — Fri, 6 Sep 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    clarified

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

In String Argument Passing Question

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

    Summary: To be compliant, does a client have to pass a string_alloc"ed string to a CORBA operation that takes an in string parameter? If so, why should the ORB care how the client created storage?

  • Reported: CPP 1.0b1 — Fri, 6 Sep 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    clarified

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

inserter and extractor functions for exceptions

  • Key: CPP11-177
  • Legacy Issue Number: 142
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The spec is silent about whether to generate Any inserter and extractor (<<= and >>=) functions for exceptions, although they appear necessary for properly storing and manipulating exceptions.

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

    added clarifying texed, fixed

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

Union problem

  • Key: CPP11-176
  • Legacy Issue Number: 134
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Is this legal: union X switch(boolean)

    {case TRUE: short a; case FALSE: long b;default: double c;}

    ;? If no, why? If yes, what does _d() return if the union was set with the c() access function?

  • Reported: CPP 1.0b1 — Tue, 24 Sep 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    fixed

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

GIOP fragment alignment issue for CORBA 2.3

  • Key: CPP11-129
  • Legacy Issue Number: 1982
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary:
    The following issue should be fixed prior to publishing CORBA 2.3.

    Section 15.4.8 Fragment Message, page 15-40, of ptc/98-08-03, says:

    > A primitive data type of 8 bytes or smaller should never be broken across two
    > fragments.

    This text has been in the specification since GIOP 1.1.

    Section 15.4.1 GIOP Message Header, page 15-29, of ptc/98-08-03,
    contains new text under the "message size" bullet:

    > For GIOP version 1.2, if the second least significant bit of flags is 1, the
    > message_size value must be evenly divisible by 8.

  • Reported: CORBA 2.2 — Sun, 20 Sep 1998 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    resolved

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

COMM_FAILURE and completion_status

  • Key: CPP11-128
  • Legacy Issue Number: 1978
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Page 15-43 of 98-08-13:
    As Bob Kukura pointed out, COMPLETED_MAYBE could well be wrong. In particular,
    if the connection goes down in the middle of a series of fragments that
    make up the reply, or in between reads by the client of parts of the
    message from a socket, the client can actually conclude reliably
    that the status should be COMPLETED_YES.

    I would suggest to strike the last clause of this para. This would also
    bring things in line with the additions made to the exception section in
    the IDL chapter.

  • Reported: CORBA 2.2 — Fri, 18 Sep 1998 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    agree to remove the last sentence of 15.5.1.1

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

Typo in page 15-44

  • Key: CPP11-127
  • Legacy Issue Number: 1975
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Page 15-44, second para after bullet list, the word LOCATION_FORWARD
    appears in the wrong font (in two places).

  • Reported: CORBA 2.2 — Fri, 18 Sep 1998 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    duplicate of issue # 2045

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

CloseConnection

  • Key: CPP11-126
  • Legacy Issue Number: 1968
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: There are quite a few words about CloseConnection in the GIOP 1.2 draft.
    The major change is that either end of a connection can send the message
    for a bi-directional connection.

    However, the spec doesn"t say that a client must send a CloseConnection
    message to the server before closing down. It just says that it may.

    Similarly, CloseConnection is only partially defined for the server side,
    as far as I can see.

  • Reported: CORBA 2.2 — Fri, 18 Sep 1998 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    resolved

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

How to handle unexpected exceptions?

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

    Summary: If I invoke an operation and the result is an exception that is not
    defined as part of the operation"s definition, what should happen? It
    seems obvious that a different exception needs to be raised but which
    one? MARSHAL?

  • Reported: CORBA 2.2 — Thu, 2 Apr 1998 05:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    Clarify to Be consistent with behaviour for system exceptions. Raise UNKNOWN exception

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

IIOP server-initiated connection closure problem

  • Key: CPP11-124
  • Legacy Issue Number: 543
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: On several operating systems the client"s writing of Request message after CloseConnection message can cause the unread CloseConnection message to be discarded from buffer

  • Reported: CORBA 2.0 — Wed, 16 Apr 1997 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    resolved, see above

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

Move recently added text to correct place

  • Key: CPP11-133
  • Legacy Issue Number: 2324
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The recently addded fourth bullet on page 15-18 "For value types that have
    an RMI: rep id, ORBs must include at least the most derived rep id, in the
    value type encoding." should be moved back to be a paragraph on page 15-15,
    preceding the paragraph that starts "If the receiving context ...".

    Its current placement is incorrect because this section (15.3.4.4)
    describes chunking, and this bullet has nothing to do with chunking but
    concerns how much type information needs to be specified in the encoding
    (the subject of section 15.3.4.1).

  • Reported: CORBA 2.2 — Thu, 21 Jan 1999 05:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    To accept proposed change

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

OBV GIOP clarification needed

  • Key: CPP11-132
  • Legacy Issue Number: 2315
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: On page 15-15 of the 2.3a core chapters, I am having trouble
    understanding the wording in the first two bullets. The definition
    of what the different bit values mean is clear enough, but the
    rationale for when they are used is not.

    Specifically, I don"t understand the subtle difference between
    "the actual parameter is the same type as the formal argument"
    (first bullet) and "the actual value"s most derived type is the
    same as the static type of the position currently being marshaled"
    (second bullet). Are these different cases? If so, what is the
    difference?

  • Reported: CORBA 2.2 — Wed, 20 Jan 1999 05:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    resolved see above

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

Tagged Component interactions

  • Key: CPP11-131
  • Legacy Issue Number: 2068
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The Tagged Components TAG_SSL_SEC_TRANS and TAG_IIOP_ALTERNATE_ADDRESS
    both allow an IIOP profile to have an extra port in the IOR. The
    words around SSL_SEC_TRANS say something like "to be used instead
    of the one in the profile proper". Whereas the words around
    ALTERNATE_ADDRESS are deliberately vague.

    So what should a client-side ORB do with one of these? It could
    view the IOR as broken, it could treat the ALTERNATE_ADDRESS
    component as invalid or it could treat the port in the ALTERNATE_
    ADDRESS component as either for TCP connection requests >or< for
    SSL connection requests. It could even look for a second
    SSL_SEC_TRANS component.

  • Reported: CORBA 2.2 — Fri, 9 Oct 1998 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    resolved, see above

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

Obsolete text in ptc/98-08-13.pdf

  • Key: CPP11-130
  • Legacy Issue Number: 2045
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: In section 15.7, the second two paragraphs:

    "IIOP 1.0 is based on GIOP 1.0.

    IIOP 1.1 can be based on either GIOP 1.0 or GIOP 1.1. An IIOP 1.1 client
    can either support both GIP 1.0 and 1.1, or GIOP 1.1 only. An IIOP 1.1
    server must support both GIOP 1.0 and GIOP 1.1. An IIOP 1.1 server must
    be able to receive both GIOP 1.0 and GIOP 1.1 requests and reply using
    the same GIOP revision as invoked."

    only refer to GIOP 1.0 and 1.1, not 1.2. In light of the note in
    section 15.7.2, these two paragraphs are obsolete and could be removed,
    since the note covers the same information in a more generic way.

  • Reported: CORBA 2.2 — Tue, 6 Oct 1998 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    resolved

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