${taskforce.name} Avatar
  1. OMG Task Force

C++ Mapping RTF — Closed Issues

  • Key: CPP11
  • Issues Count: 265
Open Closed All
Issues resolved by a task force and approved by Board

Issues Summary

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

Issues Descriptions

20.17.9 Valuetype Inheritance

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

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

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

    Consider this example:

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

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

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

sequence max < length

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

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

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

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

    No Data Available

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

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

Add _narrow() operation to each POA servant

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

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

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

    // IDL
    interface A { };

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

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

    ;

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

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

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

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

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

freebuf and destruction of elements

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

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

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

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

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

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

C++: ostream insertion

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

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

    try

    { // do some operations }

    catch (CORBA::Exception & ex)

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

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

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

    closed issue, duplicate of 266

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

_var types for fixed-length underlying types

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

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

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

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

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

    duplicate of issdue 1521...close issue

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

string sequences and empty strings

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

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

    I therefore raise this herewith as an official issue.

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

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

    closed and fixed

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

Incorrect types for type-safe Any extraction

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

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

    Proposal:

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

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

    No Data Available

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

"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

Unknown parts of an IOR and interoperability

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

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

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

    a) obliged to accept that reference as a valid parameter

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

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

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

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

    issue split into issues 3234 and 3235

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

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

Fixed(const char *) constructor problem

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

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

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

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

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

    This means that the following call is illegal:

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

    Even though this can be rewritten (legally) as:

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

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

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

    closed/resolved

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

Editorial typo in Section 1.36.3 of C++ mapping

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

    The code example has a "ServantBaseBase_var".

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

    closed, editorial fix

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

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

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

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

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

    Close as duplicate of 2354.

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

Object _out class copy constructor & assignment op wrong

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

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

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

    closed/resolved

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

CORBA 2.3 Editorial problem in TypeCode

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

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

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

    editorial fix...isssue closed

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

Contents of string members (02)

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

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

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

    closed/resolved

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

Contents of string members (01)

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

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

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

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

    closed/resolved

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

String extractor semantics undefined?

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

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

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

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

    The same applies to wide strings.

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

    closed/resolved

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

Exception constructors should be protected

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

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

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

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

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

Exception::_raise() should be const?

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

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

    class Exception

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

    ;

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

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

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

Union string member mapping defect?

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

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

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

    closed/resolved

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

Unary operators for Fixed class have wrong return types

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

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

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

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

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

1 of 4 issues with Abstract interfaces

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

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

    // IDL

    interface A {
    };

    interface B : A {
    };

    // C++

    class MyA : public virtual POA_A {
    };

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

    However, this paradigm breaks when using abstract interfaces:

    // IDL
    abstract interface A {
    };

    interface B : A {
    };

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

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

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

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

    resolved/closed

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

NamedValue not only an NVList element

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

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

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

    editorial fix, issue closed

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

4 of 4 issues with Abstract interfaces

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

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

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

    closed/resolved

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

don't understand the last paragraph of 1.18.2:

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

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

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

    // IDL
    abstract interface A {
    };

    interface I : A {
    };

    valuetype V1 : supports A {
    };

    valuetype V2 : supports I {
    };

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

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

    see below

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

Extraction operator for system exceptions?

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

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

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

    // assume a contains a system exception...

    a >>= sep;

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

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

    I would like to suggest adding the following extraction operator:

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

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

    closed/resolved

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

Need Any::to_value operation?

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

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

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

    closed/resolved

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

2 of4 issues with Abstract interfaces

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

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

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

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

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

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

    closed/resolved

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

Supporting typedefs for _var types?

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

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

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

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

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

    No Data Available

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

Any::to_abstract_base needs statement about memory management

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

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

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

    closed/resolved

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

Standard object operations & DynamicImplementation

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

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

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

    closed/resolved

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

Inconsistency in 1.7 and 1.9 of mapping

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

    Minor editorial issue:

    In Section 1.9.2, "T_out Types":

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

    { ... }
    };

    In Section 1.7, "Mapping for String Types":

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

    };

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

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

    closed/resolved

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

Typographical problems

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

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

    Perhaps the example should read:

    Foo* some_function (/.../)

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

    Updated the example code as suggested

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

allocbuf() for bounded sequences?

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

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

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

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

    closed/resolved

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

Fixed::round and truncate issue

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

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

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

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

    closed/resolved

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

operator>> for String_var

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

    Summary: The C++ mapping says:

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

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

    CORBA::String_var str;
    cin >> str;

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

    closed/resolved

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

Valuetypes and _out classes in C++ mapping

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

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

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

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

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

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

generate concrete classes and factories for valuetypes without initializer

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

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

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

    Similarly, concrete factories could be generated for
    value boxes

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

    resolved/closed

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

add a _var type for each servant type

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

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

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

    see below

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

tie doesn"t do ref counting

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

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

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

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

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

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

Misleading text for DSI invoke() and _primary_interface()

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

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

    The paragraph should be reworded to say:

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

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

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

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

Valuetypes and arbitrary graphs

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

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

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

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

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

    Close as duplicate of 2309.

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

Factories for StringValue and WStringValue

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

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

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

    Close no change. Valueboxes do not have factories.

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

_primary_interface

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

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

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

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

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

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

    Already resolved.

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

The C++ mapping for valuetype _narrow should not _add_ref

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

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

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

    Already resolved.

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

Valuetype argument passing

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

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

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

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

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

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

Add AbstractBase base type to IDL language?

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

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

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

    close with no change

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

narrow abstract interface class to concrete object?

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

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

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

    closed/resolved

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

Sequences and get_buffer()

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

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

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

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

    get_buffer() is not possible for recursive sequences anyway.

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

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

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

sequence allocbuf parameter != 0

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

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

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

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

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

Any missing LongLong operators, etc?

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

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

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

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

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

Exception id for each exception type

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

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

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

    closed/resolved

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

Accessor for exception id

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

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

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

    closed/resolved

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

operator<< for ostreams and Exceptions

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

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

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

    closed/resolved

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

C++ semantics vs. IDL semantics

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

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

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

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

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

ANy release flag and operator

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

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

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

    close with no change

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

Legal IDL cannot map to C++

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

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

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

    close with no change

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

Double underscore identifier mapping

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

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

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

    closed with no change

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

make String_var reference but not adopt

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

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

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

    close with no change

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

buffer classes for sequences

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

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

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

    closed with no change

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

u++ binding for ServerRequest pseudo object

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

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

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

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

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

[q] intf name == op name

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

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

    { void Foo(in long 1); }

    ;

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

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

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

TypeCode for each basic and IDL defined types

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

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

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

    Close with no change

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

Accessors for the Any release flag

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

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

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

    Close with no change

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

Constructor taking discriminant as argument

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

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

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

    Close with no change

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

Name field for SystemExceptions

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

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

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

    closed/resolved

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

union accessors

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

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

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

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

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

callee-allocated storage modification

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

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

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

    Already resolved.

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

accessor members for structs

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

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

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

    Closed with no change

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

allocbuf and initialization of elements

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

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

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

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

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

Allocated storage for out and return strings

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

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

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

    close with no change

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

accessor function on SystemException

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

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

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

    Close with no change.

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

void* from Any for constructed types

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

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

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

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

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

handling void* from Any

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

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

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

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

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

Mapping for IDL context

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

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

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

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

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

union accessors require temporaries

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

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

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

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

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

anonymus types

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

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

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

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

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

C++ namespaces

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

    Summary: Implementation dependent: Namespaces available/not available

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

    Close no change. Issue withdrawn by submitter.

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

Multiple inheritance of C++ Servants is ill-defined

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

    Summary: Please find example/discussion in corresponding archive file

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

    closed and resolved

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

Blocking semantics of get_next_response not well specified

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

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

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

    resolved, issue closed

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

Section 16.2, Section 16.6: editorial

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

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

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

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

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

No conversion defined from a B_var to an A_ptr

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

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

    // IDL

    interface A {
    };

    interface B : A {
    };

    // C++

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

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

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

    close with no change

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

ServantBase mappings

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

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

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

    resolved and closed in ptc/1998-09-03

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

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

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

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

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

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

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

Implementation problem with policy objects using root POA

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

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

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

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

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

Interface definition must be standardized

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

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

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

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

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

String_var and Any_var are missing the T_ptr definition

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

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

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

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

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

C and C++ Mapping question

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

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

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

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

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

inout strings modifiable?

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

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

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

    resolverd and closed

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

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

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

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

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

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

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

IDL from Ennvironment has invalid attribute

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

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

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

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

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

const method qualification should be removed

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

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

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

    close with no change

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

Storage ownership issue

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

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

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

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

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

Global functions vs. T_var namespace

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

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

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

    closed/resolved

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

Array slice example

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

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

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

    resolved/closed

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

Semantics of sequence length() operation

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

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

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

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

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

Implementation description

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

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

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

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

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

Detection of initialization of T_var

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

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

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

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

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

example incorrect?

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

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

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

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

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

Levels of portability conformance requested

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

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

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

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

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

Copying of out parameters

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

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

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

    Already resolved.

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

C vs. C++ coding style

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

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

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

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

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

Autoextension of sequences

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

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

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

    resolved and closed

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

Pointers vs. values

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

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

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

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

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

Assignment to T_var

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

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

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

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

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

Array_forany

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

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

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

    closed/resolved

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

Problems with deactivate_object()

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

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

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

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

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

Do POA servant classes need to use virtual inheritance?

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

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

    // IDL
    interface A

    { void op(); }

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

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

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

    resolved

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

Spec does not mention the existance of an Any_out class

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

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

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

    resolved and closed

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

_var & _out types problems (01)

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

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

    typedef T &T_out;

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

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

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

    see below

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

Spec is too verse in defini