C++ Language Mapping Avatar
  1. OMG Specification

C++ Language Mapping — Closed Issues

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

Issues Summary

Key Issue Reported Fixed Disposition Status
CPP1116-19 Add mapping for @optional CPP11 1.5 CPP 1.6 Resolved closed
CPP1116-20 Impact of @final on union/struct mapping CPP11 1.5 CPP 1.6 Closed; No Change closed
CPP1116-11 Add IDL::traits<>::bit_bound CPP11 1.5 CPP 1.6 Resolved closed
CPP1116-12 Invalid constructor in example code CPP11 1.5 CPP 1.6 Resolved closed
CPP1116-18 Use IDL::traits<>::make_reference instead of CORBA::make_reference CPP11 1.5 CPP 1.6 Resolved closed
CPP1116-15 The page footers of https://www.omg.org/spec/CPP11/1.5/PDF (ptc-20-11-02.pdf) all say v1.4 CPP11 1.5 CPP 1.6 Duplicate or Merged closed
CPP1116-6 Struct inheritance mapping strange CPP11 1.5 CPP 1.6 Resolved closed
CPP1116-5 Incorrect footer CPP11 1.5 CPP 1.6 Closed; No Change closed
CPP1116-7 IDL::traits missing for enum type for bitmask and use a C++11 strong enum CPP11 1.5 CPP 1.6 Resolved closed
CPP1116-10 Remove std namespace from example code CPP11 1.5 CPP 1.6 Duplicate or Merged closed
CPP1116-9 Why not map bitset inheritance to struct inheritance CPP11 1.5 CPP 1.6 Closed; No Change closed
CPP1116-14 Missing override CPP11 1.5 CPP 1.6 Resolved closed
CPP1116-8 Remove std namespace from example code CPP11 1.5 CPP 1.6 Closed; No Change closed
CPP1116-13 Missing override CPP11 1.5 CPP 1.6 Resolved closed
CPP1116-3 Annotation for union discriminator name CPP11 1.5 CPP 1.6 Deferred closed
CPP1116-4 Add mapping for IDL4.2 standardized annotations CPP11 1.4 CPP 1.6 Deferred closed
CPP1116-1 Replace ServantBase with Servant CPP11 1.4 CPP 1.6 Resolved closed
CPP1114-29 Use C++11 using instead of typedef in all C++11 example code CPP11 1.3 CPP11 1.4 Resolved closed
CPP1115-18 IDL4 Extended Data-Types: struct inheritance CPP11 1.4 CPP11 1.5 Resolved closed
CPP1115-4 Add support for int8 CPP11 1.4 CPP11 1.5 Resolved closed
CPP1115-9 Example V_factory should list deleted assignment/copy CPP11 1.4 CPP11 1.5 Resolved closed
CPP1115-7 Copy/move assignment operators should be deleted CPP11 1.4 CPP11 1.5 Duplicate or Merged closed
CPP1115-6 valuebox should be final CPP11 1.4 CPP11 1.5 Resolved closed
CPP1115-5 Copy/move assignment operators should be deleted CPP11 1.4 CPP11 1.5 Resolved closed
CPP1115-8 Missing deleted assignment/copy operators CPP11 1.4 CPP11 1.5 Resolved closed
CPP1115-3 Operations tagged with override shouldn't have virtual CPP11 1.4 CPP11 1.5 Resolved closed
CPP1115-2 _default_POA should use override CPP11 1.4 CPP11 1.5 Resolved closed
CPP1115-1 Add support for bitset/bitfield/bitmask CPP11 1.4 CPP11 1.5 Resolved closed
CPP1114-31 Add Delegation-Based Interface Implementation CPP11 1.3 CPP11 1.4 Resolved closed
CPP1114-14 Remove the setter operation for the discriminator of a union CPP11 1.3 CPP11 1.4 Resolved closed
CPP1114-12 Bullets before IDL::traits::narrow(ap) lost CPP11 1.3 CPP11 1.4 Resolved closed
CPP1114-9 OBV_Example constructor CPP11 1.3 CPP11 1.4 Resolved closed
CPP1114-8 Text alignment CPP11 1.3 CPP11 1.4 Resolved closed
CPP1114-7 Typo fixes CPP11 1.3b1 CPP11 1.4 Resolved closed
CPP1114-13 Only single argument constructors have to be explicit CPP11 1.3 CPP11 1.4 Closed; No Change closed
CPP1114-4 Errors in IDL Built-in Annotations Usage Table CPP11 1.2 CPP11 1.4 Closed; Out Of Scope closed
CPP1114-3 Make mapping of sequences more flexible CPP11 1.1 CPP11 1.4 Resolved closed
CPP1114-2 IDL2C++11 issue : CORBA dependency of the C++11 mapping CPP11 1.1 CPP11 1.4 Closed; Out Of Scope closed
CPP1114-1 In-place construction of structure types CPP11 1.0 CPP11 1.4 Closed; No Change closed
CPP1114-11 Reduce indent CPP11 1.3 CPP11 1.4 Resolved closed
CPP1114-10 Alignment _is_a and _non_existent CPP11 1.3 CPP11 1.4 Resolved closed
CPP1114-5 Structure mapping change should be reverted CPP11 1.2 CPP11 1.4 Closed; No Change closed
CPP1114-6 Fixed is now broken CPP11 1.2 CPP11 1.4 Resolved closed
CPP1113-11 Errors in IDL Built-in Annotations Usage Table CPP11 1.2 CPP11 1.3 Deferred closed
CPP1113-6 IDL2C++11 issue : CORBA dependency of the C++11 mapping CPP11 1.1 CPP11 1.3 Deferred closed
CPP1113-7 Make mapping of sequences more flexible CPP11 1.1 CPP11 1.3 Deferred closed
CPP1113-5 In-place construction of structure types CPP11 1.0 CPP11 1.3 Deferred closed
CPP1113-10 Example C++ code in mapping for constants should use C++11 uniform initialization CPP11 1.2 CPP11 1.3 Resolved closed
CPP1113-1 IDL2C++11 mapping lacks support for the new IDL type map CPP11 1.1 CPP11 1.3 Resolved closed
CPP1113-9 Fix assignment operator of ColorValue CPP11 1.2 CPP11 1.3 Resolved closed
CPP1113-8 CORBA::make_reference shouldn't explicitly imply perfect forwarding CPP11 1.2 CPP11 1.3 Resolved closed
CPP1113-4 Handle possible exception what conflict and improve Exception introduction text CPP11 1.2 CPP11 1.3 Resolved closed
CPP1113-3 Trivial grammatic fix in 6.14.1 CPP11 1.2 CPP11 1.3 Resolved closed
CPP1113-2 minor accessors of SystemException should use pass by value, minor should be uint32_t CPP11 1.2 CPP11 1.3 Resolved closed
CPP1113-13 Only a namespace level swap should be provided CPP11 1.2 CPP11 1.3 Resolved closed
ITCR-57 Fix unclarity in IDL Union description CPP11 1.1 CPP11 1.2 Resolved closed
ITCR-54 Update normative reference to point to CORBA 3.3 CPP11 1.1 CPP11 1.2 Resolved closed
ITCR-38 IDL2C++11 mapping lacks support for the new IDL type map CPP11 1.1 CPP11 1.2 Deferred closed
ITCR-28 Servant argument passing not precise enough CPP11 1.1 CPP11 1.2 Resolved closed
ITCR-39 Missing public specifier CPP11 1.1 CPP11 1.2 Resolved closed
ITCR-42 replace POA_B by adequate skeleton CPP11 1.1 CPP11 1.2 Resolved closed
ITCR-41 _this for skeleton, not for implementation CPP11 1.1 CPP11 1.2 Resolved closed
ITCR-44 Skeleton class as consistent template parameter for CORBA::servant_traits CPP11 1.1 CPP11 1.2 Closed; No Change closed
ITCR-43 abstract interfaces with corrected skeleton name CPP11 1.1 CPP11 1.2 Duplicate or Merged closed
ITCR-3 Errors on code snippet related to skeleton classes CPP11 1.0 CPP11 1.2 Resolved closed
ITCR-1 In-place construction of structure types CPP11 1.0 CPP11 1.2 Deferred closed
ITCR-12 Clarify valuetype factory mapping CPP11 1.1 CPP11 1.2 Resolved closed
ITCR-11 Valuebox should also have swap support CPP11 1.1 CPP11 1.2 Closed; No Change closed
ITCR-8 provide unique class name as mapping of PortableServer::Servant CPP11 1.1 CPP11 1.2 Duplicate or Merged closed
ITCR-7 Constructor declarations in Servant code are wrong CPP11 1.1 CPP11 1.2 Resolved closed
ITCR-6 Destructors of strong reference types should be public CPP11 1.1 CPP11 1.2 Resolved closed
ITCR-17 Mention move constructor with abstract CPP11 1.1 CPP11 1.2 Resolved closed
ITCR-16 usage of OBV trait should be improved CPP11 1.1 CPP11 1.2 Resolved closed
ITCR-10 Add missing default initialization for valuetypes CPP11 1.1 CPP11 1.2 Resolved closed
ITCR-9 wrong return type for Foo::some_function() CPP11 1.1 CPP11 1.2 Resolved closed
ITCR-5 Question on unions default member CPP11 1.1 CPP11 1.2 Resolved closed
ITCR-4 Code fragment should use skel class CPP11 1.0 CPP11 1.2 Closed; No Change closed
ITCR-15 Move constructor of ValueBase incorrect CPP11 1.1 CPP11 1.2 Resolved closed
ITCR-14 Missing move assignment operator in class ColorValue CPP11 1.1 CPP11 1.2 Resolved closed
ITCR-19 fixed member types use incorrect type CPP11 1.1 CPP11 1.2 Resolved closed
ITCR-18 Destructor should just be virtual CPP11 1.1 CPP11 1.2 Resolved closed
ITCR-2 IDL2C++11 issue : CORBA dependency of the C++11 mapping CPP11 1.1 CPP11 1.2 Deferred closed
ITCR-13 Make mapping of sequences more flexible CPP11 1.1 CPP11 1.2 Deferred closed
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
CPP1111-25 Reduce dependency on CORBA CPP11 1.0 CPP11 1.1 Resolved closed
CPP12-43 Typedefs for struct members? CPP 1.1 CPP 1.2 Resolved closed
CPP12-42 Deprecated Ref identifier CPP 1.1 CPP 1.2 Resolved closed
CPP12-40 Server-side exception specifications and ISO C++ std::exception CPP 1.1 CPP 1.2 Resolved closed
CPP12-41 There is an incorrect page reference CPP 1.1 CPP 1.2 Resolved closed
CPP12-39 Remnant of read-only return values and out params CPP 1.1 CPP 1.2 Resolved closed
CPP12-38 Backward compatibility with C CPP 1.1 CPP 1.2 Resolved closed
CPP12-37 Non-exception neutral code in C++ mapping. CPP 1.1 CPP 1.2 Resolved closed
CPP12-36 Need for TIE template for skeletons for valuetypes that support CPP 1.1 CPP 1.2 Resolved closed
CPP12-35 _name & _rep_id pure virtual? CPP 1.1 CPP 1.2 Resolved closed
CPP12-34 Requiring ref counting in ServantBase CPP 1.1 CPP 1.2 Resolved closed
CPP12-33 CORBA::Fixed needs a to_string() conversion function CPP 1.1 CPP 1.2 Resolved closed
CPP12-32 Another issue with String_var CPP 1.1 CPP 1.2 Resolved closed
CPP12-31 Missing conversion operator on String_var CPP 1.1 CPP 1.2 Resolved closed
CPP12-30 Any extraction widening to ValueBase CPP 1.1 CPP 1.2 Resolved closed
CPP12-29 Null assignment to String_var? CPP 1.1 CPP 1.2 Resolved closed
CPP12-28 _name and _rep_id CPP 1.1 CPP 1.2 Resolved closed
CPP12-27 Do valuetype POA servants get tie templates? CPP 1.1 CPP 1.2 Resolved closed
CPP12-25 Problem with OBV_ valuetype class constructor CPP 1.1 CPP 1.2 Resolved closed
CPP12-26 Problem with type specific valuetype factories in CORBA 2.3.1 C++ mapping CPP 1.1 CPP 1.2 Resolved closed
CPP12-23 C++ Value Type issue (02) CPP 1.1 CPP 1.2 Resolved closed
CPP12-24 Obsolete text in 1.40.3 CPP 1.1 CPP 1.2 Resolved closed
CPP12-22 Valuebox for object reference underspecified CPP 1.1 CPP 1.2 Resolved closed
CPP12-21 C++ valuetype issue (01) CPP 1.1 CPP 1.2 Resolved closed
CPP12-20 Valuetype code typo in CORBA 2.3 C++ mapping CPP 1.1 CPP 1.2 Resolved closed
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
CPP1111-24 Remove user defined literal support CPP11 1.0 CPP11 1.1 Resolved closed
CPP1111-23 Add namespace level swap CPP11 1.0 CPP11 1.1 Resolved closed
CPP1111-20 Small typos in servant reference section CPP11 1.0 CPP11 1.1 Resolved closed
CPP1111-19 Replace all _downcase/downcase with narrow CPP11 1.0 CPP11 1.1 Resolved closed
CPP1111-22 Relax constructor argument rules CPP11 1.0 CPP11 1.1 Resolved closed
CPP1111-21 Remove final for structured types CPP11 1.0 CPP11 1.1 Resolved closed
CPP1111-2 typo exists in section 6.21 CPP11 1.0b2 CPP11 1.1 Resolved closed
CPP1111-1 RFP requirement on DDS-PSM-Cxx compatibility is violated CPP11 1.0b2 CPP11 1.1 Resolved closed
CPP1111-3 Lack of factory reference type CPP11 1.0b2 CPP11 1.1 Resolved closed
CPP1111-14 Early detection of bound violation on bounded types CPP11 1.0 CPP11 1.1 Resolved closed
CPP1111-13 std::ostream insertion underspecified CPP11 1.0 CPP11 1.1 Resolved closed
CPP1111-5 Add missing implicit widening to any CPP11 1.0b2 CPP11 1.1 Resolved closed
CPP1111-4 Add support for _this on local objects CPP11 1.0b2 CPP11 1.1 Resolved closed
CPP1111-12 Missing specification of assignment operators of valuetypes CPP11 1.0b2 CPP11 1.1 Resolved closed
CPP1111-11 Meaning of (u)intN_t types unclear CPP11 1.0b2 CPP11 1.1 Resolved closed
CPP1111-10 Fixed type mapping should provide (explicit) operator bool CPP11 1.0b2 CPP11 1.1 Resolved closed
CPP1111-9 Invalid struct initialization example CPP11 1.0b2 CPP11 1.1 Resolved closed
CPP1111-15 CORBA::Exception should not use std::string type for name and repo_id CPP11 1.0 CPP11 1.1 Resolved closed
CPP1111-8 Remove _narrow methods CPP11 1.0b2 CPP11 1.1 Resolved closed
CPP1111-7 Extend IDL type traits for template meta programming CPP11 1.0b2 CPP11 1.1 Resolved closed
CPP1111-17 Use () instead of (void) CPP11 1.0 CPP11 1.1 Resolved closed
CPP1111-16 Minor typos CPP11 1.0 CPP11 1.1 Resolved closed
CPP1111-18 Introduce trait for local interface base type CPP11 1.0 CPP11 1.1 Resolved closed
CPP1111-6 Font issue CPP11 1.0b2 CPP11 1.1 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
CPP13-72 ORB interface destroy() operation issue CPP 1.1 CPP 1.3 Resolved closed
CPP13-71 _ptr_type and _var_type typedefs CPP 1.0b1 CPP 1.3 Resolved closed
CPP13-76 make it possible to write more generic C++ code CPP 1.2 CPP 1.3 Resolved closed
CPP13-75 Servant_var + spec typo? CPP 1.2 CPP 1.3 Resolved closed
CPP13-79 valuetype classes should add _out_type typedef CPP 1.2 CPP 1.3 Resolved closed
CPP13-78 Interface should add _out_type typedef CPP 1.2 CPP 1.3 Resolved closed
CPP13-77 C++ keywords should be updated CPP 1.2 CPP 1.3 Resolved closed
CPP13-74 Section 4.5.4: parameter to _narrow CPP 1.2 CPP 1.3 Resolved closed
CPP13-73 Context PIDL mapping bug CPP 1.1 CPP 1.3 Resolved closed
CPP13-80 get_policy should return Policy, not Policy_ptr CPP 1.2 CPP 1.3 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
CPP12-9 Escaped keyword mapping? CPP 1.1 CPP 1.2 Resolved closed
CPP12-8 Local interfaces issue 1 CPP 1.1 CPP 1.2 Resolved closed
CPP12-16 implementing local interfaces in C++ CPP 1.1 CPP 1.2 Resolved closed
CPP12-15 Initialized T_var? CPP 1.1 CPP 1.2 Resolved closed
CPP12-14 Missin operations in Object interface, ptc/01-06-07 CPP 1.1 CPP 1.2 Resolved closed
CPP12-19 String_var and C++ implicit conversions CPP 1.1 CPP 1.2 Resolved closed
CPP12-18 need mapping for get_orb and get_component on CORBA::Object CPP 1.1 CPP 1.2 Resolved closed
CPP12-17 No Mapping for Local interface in C++ CPP 1.1 CPP 1.2 Resolved closed
CPP12-11 Bug on _var references CPP 1.1 CPP 1.2 Resolved closed
CPP12-10 Dangling reference CPP 1.1 CPP 1.2 Resolved closed
CPP12-7 Structure member ordering CPP 1.1 CPP 1.2 Resolved closed
CPP12-6 semantics of valuetype _downcast operation unclear CPP 1.1 CPP 1.2 Resolved closed
CPP12-13 ValueRefCountBase::_add_ref CPP 1.1 CPP 1.2 Resolved closed
CPP12-12 C++ mapping for CORBA::LocalObject CPP 1.1 CPP 1.2 Resolved closed
CPP12-3 LocalObject CPP 1.1 CPP 1.2 Resolved closed
CPP12-2 mapping of local interfaces CPP 1.1 CPP 1.2 Resolved closed
CPP12-5 How to create a local object reference? CPP 1.1 CPP 1.2 Resolved closed
CPP12-4 CORBA::Object & LocalObject CPP 1.1 CPP 1.2 Resolved closed

Issues Descriptions

Add mapping for @optional

  • Key: CPP1116-19
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The specification should specify the mapping of @optional, maybe maybe to IDL::optional which could be an using of std::optional with C+17, only for C11/C+14 at that moment the API of IDL::optional should be specified

  • Reported: CPP11 1.5 — Thu, 19 Aug 2021 08:21 GMT
  • Disposition: Resolved — CPP 1.6
  • Disposition Summary:

    Map optional struct members

    Unlike other standardized annotations that are impact the middleware platform, the IDL @optional annotation impacts the language mapping.

  • Updated: Thu, 31 Mar 2022 19:32 GMT

Impact of @final on union/struct mapping

  • Key: CPP1116-20
  • Status: closed   Implementation work Blocked
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The @extensibilty(FINAL) or @final annotation is one of the new annotations in IDL4.2, see 8.3.16 of IDL4.2. Should the generated class for a struct/union which is annotated with @final be generated as a C++11 final class or not? So

    struct Foo final {}

    or

    struct Foo {}

  • Reported: CPP11 1.5 — Fri, 3 Sep 2021 11:32 GMT
  • Disposition: Closed; No Change — CPP 1.6
  • Disposition Summary:

    Extensibility annotations do not impact the language mapping

    The concept of type extensibility is defined in IDL4.2 as "specifying how
    the element is allowed to evolve." The language mappings determine how each IDL source file is mapped. In terms of this "evolution," the mapping is just capturing a single point in time. Neither of the IDL4-specific mappings (C# or Java) map extensibility to a programming language feature.

  • Updated: Thu, 31 Mar 2022 19:32 GMT

Add IDL::traits<>::bit_bound

  • Key: CPP1116-11
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    For template programming it could be helpful to have a IDL::traits<>::bit_bound trait of type std::integral_constant which returns the bit_bound set in IDL for a bitmask

  • Reported: CPP11 1.5 — Thu, 22 Apr 2021 09:32 GMT
  • Disposition: Resolved — CPP 1.6
  • Disposition Summary:

    Add traits member specification to Bit Masks section

    Specify the bit_bound member of IDL::traits for Bit Masks

  • Updated: Thu, 31 Mar 2022 19:32 GMT

Invalid constructor in example code

  • Key: CPP1116-12
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The example code has

    OBV_Example (int16_t, int32_t, std::string, IDL::traits<Example>::ref_type;

    But this is not correct, it should be

    OBV_Example (int16_t, int32_t, std::string, IDL::traits<Example>::ref_type);

  • Reported: CPP11 1.5 — Thu, 22 Apr 2021 12:05 GMT
  • Disposition: Resolved — CPP 1.6
  • Disposition Summary:

    Fix invalid example code

    A closing parenthesis was missing from the example code.

  • Updated: Thu, 31 Mar 2022 19:32 GMT

Use IDL::traits<>::make_reference instead of CORBA::make_reference

  • Key: CPP1116-18
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    For creating a client side reference the specification uses currently CORBA::make_reference but this logic is not really CORBA specific and in a LwCCM system which only uses local interfaces the usage of CORBA is polluting user code. One of the key concepts of IDL to C++11 is that the user doesn't need to remember any special naming rules so we don't want to tie a factory function to some implementation name. The IDL to C++11 specification already uses the IDL::traits<> concept which is specialized based on the IDL type. We propose to extend the IDL::traits<> for interfaces/valuetypes for a make_reference factory method so that user code given an interface A can create an object reference using IDL::traits<A>::make_reference.

    In the specification we propose the following changes:
    6.7.1, replace CORBA::make_reference with IDL::traits<>::make_reference
    6.18.7.1 replace CORBA::make_reference <StringValue> with IDL::traits<StringValue>::make_reference
    6.18.10.2 replace CORBA::make_reference<> with IDL::traits<>::make_reference
    6.25 replace CORBA::make_reference<> with IDL::traits<>::make_reference and CORBA::make_reference <MyLocalIF> (); with IDL::traits<MyLocalIF>::make_reference ();

    The CORBA::make_reference() can be easily kept by an implementation for backwards compatibility but this proposal enables the user to write code that is more CORBA independent

  • Reported: CPP11 1.5 — Tue, 15 Jun 2021 09:24 GMT
  • Disposition: Resolved — CPP 1.6
  • Disposition Summary:

    Move make_reference into the traits class

    The CORBA::make_reference function template as currently specified is a top-level member of the CORBA namespace. Some uses of IDL (and this mapping) are non-CORBA, for example lightweight CCM/UCM or DDS. This change moves make_reference into the traits which lives in the IDL top-level namespace.

  • Updated: Thu, 31 Mar 2022 19:32 GMT

The page footers of https://www.omg.org/spec/CPP11/1.5/PDF (ptc-20-11-02.pdf) all say v1.4

  • Key: CPP1116-15
  • Status: closed  
  • Source: Micro Focus ( Simon McQueen)
  • Summary:

    Page footers look like:

    C++11 Language Mapping, v1.4 iii

  • Reported: CPP11 1.5 — Wed, 5 May 2021 11:25 GMT
  • Disposition: Duplicate or Merged — CPP 1.6
  • Disposition Summary:

    This issue is a duplicate of issue 5

    Apols for not checking before raising.

  • Updated: Thu, 31 Mar 2022 19:32 GMT
  • Attachments:

Struct inheritance mapping strange

  • Key: CPP1116-6
  • Status: closed   Implementation work Blocked
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The spec says the following:

    The constructor which “accepts values for each struct member in the order they are specified in IDL” also accepts, as its first parameter, an object of the mapped base type (passed by const reference)

    As user of a IDL inherited struct I would expect I can pass the members of the base type after the members of the inherited struct, not an instance of the base type. So, when there is a 2DPoint with members X and Y and a 3DPoint derived from that with member Z, I would expect to call a constructor with Z, X, Y .

    Also the spec should require that a the inheriting constructor concept should be supported (see https://arne-mertz.de/2015/08/new-c-features-inherited-and-delegating-constructors/), so we can initialize a 3DPoint with only X and Y where Z receives its default value.

    The remark of "passed by const reference" which is now part of the spec should be removed, that is an implementation decision, it could be that pass by value is more performant (see for example https://abseil.io/tips/117)

    An example would be really helpful in this case, provide an example IDL construct with the example C++11 code expected.

  • Reported: CPP11 1.5 — Thu, 22 Apr 2021 08:57 GMT
  • Disposition: Resolved — CPP 1.6
  • Disposition Summary:

    Update struct inheritance mapping

    The section "Structures with Single Inheritance" needs a minor update and an example

  • Updated: Thu, 31 Mar 2022 19:32 GMT

Incorrect footer

  • Key: CPP1116-5
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    In the footer it says "C++11 Language Mapping, v1.4", but it should be "C++11 Language Mapping, v1.5"

  • Reported: CPP11 1.5 — Thu, 22 Apr 2021 08:33 GMT
  • Disposition: Closed; No Change — CPP 1.6
  • Disposition Summary:

    No RTF change needed

    Footer is correct in formal/21-05-01 (IDL-to-C++11 1.5).

  • Updated: Thu, 31 Mar 2022 19:32 GMT

IDL::traits missing for enum type for bitmask and use a C++11 strong enum

  • Key: CPP1116-7
  • Status: closed   Implementation work Blocked
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The IDL to C++11 tries to prevent the user from remembering all kind of special naming rules. The spec now uses "<Bitmask>Bits" but that is something we want to prevent, we propose to use a IDL::traits<>::bits which can be used as a generic way to use this special "<Bitmask>Bits" type in code. It could happen that there is also a user type "<Bitmask>Bits" in IDL, how is this now handled? When IDL::traits<>::bits is used the naming of the implied type is an implementation decision

    Also a C++11 strong enum should be used instead of an old enum to prevent the enumerator values to pollute the containing namespace, the current approach doesn't work when there are 2 bitmasks with the same set of enumerators, the code below doesn't compile

    enum MyBitMaskBits : std::uint8_t

    { flag0 = 1, flag1 = 2, flag4 = 16, f6 = 64};
    enum MyBitMask2Bits : std::uint8_t { flag0 = 1, flag1 = 2, flag4 = 16, f6 = 64}

    ;

  • Reported: CPP11 1.5 — Thu, 22 Apr 2021 09:08 GMT
  • Disposition: Resolved — CPP 1.6
  • Disposition Summary:

    Update bitmask IDL traits

    Update IDL traits for bitmask types.

  • Updated: Thu, 31 Mar 2022 19:32 GMT

Remove std namespace from example code

  • Key: CPP1116-10
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    We propose to replace std::uint8_t in the example code with uint8_t, for all integer types the spec doesn't list the std namespace

  • Reported: CPP11 1.5 — Thu, 22 Apr 2021 09:31 GMT
  • Disposition: Duplicate or Merged — CPP 1.6
  • Disposition Summary:

    Duplicates issue 8

    Duplicate of issue 8

  • Updated: Thu, 31 Mar 2022 19:32 GMT

Why not map bitset inheritance to struct inheritance

  • Key: CPP1116-9
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    Why is bitset inheritance not mapped to struct inheritance, that would simplify the code for BitSet2 in this example.

  • Reported: CPP11 1.5 — Thu, 22 Apr 2021 09:27 GMT
  • Disposition: Closed; No Change — CPP 1.6
  • Disposition Summary:

    No change needed

    Using struct inheritance would mean that the last member of the base couldn't share the same byte with the first member of the derived. Essentially this is a difference between what C++ inheritance of structs means when structs have bitfields and the semantics defined by IDL.

  • Updated: Thu, 31 Mar 2022 19:32 GMT

Missing override

  • Key: CPP1116-14
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The destructor should change from

    virtual ~V_factory();

    to

    ~V_factory() override;

    The virtual is redundant, that is already in the base

  • Reported: CPP11 1.5 — Thu, 22 Apr 2021 12:07 GMT
  • Disposition: Resolved — CPP 1.6
  • Disposition Summary:

    Update the code in 6.18.10.2

    Modern C++ usage is to prefer the override keyword to virtual.

  • Updated: Thu, 31 Mar 2022 19:32 GMT

Remove std namespace from example code

  • Key: CPP1116-8
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    We propose to replace std::uint8_t in the example code with uint8_t, for all integer types the spec doesn't list the std namespace

  • Reported: CPP11 1.5 — Thu, 22 Apr 2021 09:12 GMT
  • Disposition: Closed; No Change — CPP 1.6
  • Disposition Summary:

    No change needed

    The identifier uint8_t is defined by the ISO C++ standard as a member of namespace std, so this spec uses the namespace as well.

  • Updated: Thu, 31 Mar 2022 19:32 GMT

Missing override

  • Key: CPP1116-13
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    In the example code the destructor should change from

    virtual ~ColorValue();

    to

    ~ColorValue() override;

  • Reported: CPP11 1.5 — Thu, 22 Apr 2021 12:06 GMT
  • Disposition: Resolved — CPP 1.6
  • Disposition Summary:

    Update the code in 6.18.7.2

    Modern C++ usage is to prefer the override keyword to virtual.

  • Updated: Thu, 31 Mar 2022 19:32 GMT

Annotation for union discriminator name

  • Key: CPP1116-3
  • Status: closed  
  • Source: Airbus Group ( Oliver Kellogg)
  • Summary:

    For the switch of unions, the C++ mapping uses the name _d.
    It would be desirable to permit names that reflect the users' application domain.
    Example:

      enum environment_t { air, water, land };
    
      union env_info_t switch (@switchname("environment") environment_t) {
        case air:
          air_info_t air_info;
        case water:
           [...]
      };
    

    The @switchname annotation would cause a getter/setter of the given name to be generated in addition to the _d() accessors.
    In the above example:

      void environment(environment_t);  // alias for _d(environment_t)
      environment_t environment() const;  // alias for _d()
    
  • Reported: CPP11 1.5 — Thu, 1 Apr 2021 14:23 GMT
  • Disposition: Deferred — CPP 1.6
  • Disposition Summary:

    Depends on an IDL spec change

    Defer until the IDL 4.3 RTF resolves IDL43-42.

  • Updated: Thu, 31 Mar 2022 19:32 GMT

Add mapping for IDL4.2 standardized annotations

  • Key: CPP1116-4
  • Status: closed   Implementation work Blocked
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    IDL4.2 defines in section 8.3 a set of standardized annotations where it looks some of them impact the IDL to C++11 language mapping like @optional, @final, @range, @default and maybe others. There should be a new paragraph in the IDL to C++11 language mapping which describes how these standardized annotations map to C++11, like @optional to std::optional, @final to final, etc

  • Reported: CPP11 1.4 — Thu, 1 Apr 2021 16:24 GMT
  • Disposition: Deferred — CPP 1.6
  • Disposition Summary:

    Defer work on this issue

    IDL 4.2 has 24 Standardized Annotations which vary widely in terms of their applicability to a language mapping. Since other RTF issues request specific annotations that are more urgent, defer this broad issue to the next RTF.

  • Updated: Thu, 31 Mar 2022 19:32 GMT

Replace ServantBase with Servant

  • Key: CPP1116-1
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    In the TIE chapter replace ServantBase with Servant, ServantBase is from the old IDL to C++ spec, in C++11 this should be Servant, see CPP1115-2

  • Reported: CPP11 1.4 — Fri, 30 Oct 2020 15:03 GMT
  • Disposition: Resolved — CPP 1.6
  • Disposition Summary:

    Replace ServantBase with Servant

    The term ServantBase appears in section 6.26.8, this is a holdover from the original IDL-to-C++ mapping. The term Servant should now replace it.

  • Updated: Thu, 31 Mar 2022 19:32 GMT

Use C++11 using instead of typedef in all C++11 example code

  • Key: CPP1114-29
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    C++11 introduced the "using" keyword (see https://en.cppreference.com/w/cpp/language/type_alias) as alternative way to specify a type alias. In terms of C++11 support usage it would be a good thing to update all example C++11 code within the specification to use "using" instead of "typedef"

  • Reported: CPP11 1.3 — Mon, 29 Oct 2018 10:56 GMT
  • Disposition: Resolved — CPP11 1.4
  • Disposition Summary:

    Use the C++11 type alias feature in examples

    C++11 has type aliasing with the "using" keyword, which is typically preferred to using the "typedef" syntax inherited from C.

  • Updated: Wed, 3 Nov 2021 16:29 GMT

IDL4 Extended Data-Types: struct inheritance

  • Key: CPP1115-18
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Adam Mitz)
  • Summary:

    The IDL to C++11 language mapping section 6.31 should be extended for struct inheritance as it is now part of IDL4 (Building Block Extended Data-Types)

  • Reported: CPP11 1.4 — Fri, 9 Oct 2020 13:31 GMT
  • Disposition: Resolved — CPP11 1.5
  • Disposition Summary:

    Support for struct inheritance

    Add mapping for IDL4 struct inheritance

  • Updated: Mon, 29 Mar 2021 12:21 GMT

Add support for int8

  • Key: CPP1115-4
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    Add support for int8 which is a new type, the other (u)int(8/16/32/64) are just aliases so don't need to be in the language mapping

  • Reported: CPP11 1.4 — Tue, 22 Sep 2020 06:20 GMT
  • Disposition: Resolved — CPP11 1.5
  • Disposition Summary:

    Add int8/uint8 mapping

    Add a new subsection in 6.31 for IDL int8/uint8

  • Updated: Mon, 29 Mar 2021 12:21 GMT

Example V_factory should list deleted assignment/copy

  • Key: CPP1115-9
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The V_factory should have deleted assignment/copy so add
    private:
    V_factory (const V_factory&) = delete;
    V_factory (V_factory&&) = delete;
    V_factory& operator =(const V_factory&) = delete;
    V_factory& operator =(V_factory&&) = delete;

    In the text change
    Each generated factory class has a protected virtual destructor, a protected default constructor.
    to
    Each generated factory class has a protected virtual destructor, a protected default constructor, deleted copy/move constructors, and deleted copy/move assignment operators

  • Reported: CPP11 1.4 — Mon, 28 Sep 2020 14:49 GMT
  • Disposition: Resolved — CPP11 1.5
  • Disposition Summary:

    Add deleted special member functions to type-specific value factories

    Use the "= delete" feature of C++11.

  • Updated: Mon, 29 Mar 2021 12:21 GMT

Copy/move assignment operators should be deleted

  • Key: CPP1115-7
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    ValueBase has only a protected copy/move copy constructor to allow a derived class to make a copy, the assignment operators are deleted, because of this also for a valuebox the assignment operators should be deleted, so the 3rd bullet should be updated from

    Protected copy and move assignment operators

    to

    Private deleted copy and move assignment operators

    And in the code example

    ColorValue& operator=(const ColorValue&);
    ColorValue& operator=(ColorValue&&);

    to

    ColorValue& operator=(const ColorValue&) = delete;
    ColorValue& operator=(ColorValue&&) = delete;

  • Reported: CPP11 1.4 — Mon, 28 Sep 2020 14:36 GMT
  • Disposition: Duplicate or Merged — CPP11 1.5
  • Disposition Summary:

    Duplicates issues CPP1115-5

    This appears to be a duplicate

  • Updated: Mon, 29 Mar 2021 12:21 GMT

valuebox should be final

  • Key: CPP1115-6
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The valuebox created should be using final, so add to the bullets of 6.18.7.2 a first bullet saying "Must be final" and change in the code
    class ColorValue : public ValueBase
    to
    class ColorValue : public ValueBase final

  • Reported: CPP11 1.4 — Mon, 28 Sep 2020 14:22 GMT
  • Disposition: Resolved — CPP11 1.5
  • Disposition Summary:

    Use the C++ final specifier on value box classes

    Make use of the "final" capability of C++11

  • Updated: Mon, 29 Mar 2021 12:21 GMT

Copy/move assignment operators should be deleted

  • Key: CPP1115-5
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    ValueBase has only a protected copy/move copy constructor to allow a derived class to make a copy, the assignment operators are deleted, because of this also for a valuebox the assignment operators should be deleted, so the 3rd bullet should be updated from

    Protected copy and move assignment operators

    to

    Private deleted copy and move assignment operators

    And in the code example

    ColorValue& operator=(const ColorValue&);
    ColorValue& operator=(ColorValue&&);

    to

    ColorValue& operator=(const ColorValue&) = delete;
    ColorValue& operator=(ColorValue&&) = delete;

  • Reported: CPP11 1.4 — Mon, 28 Sep 2020 14:06 GMT
  • Disposition: Resolved — CPP11 1.5
  • Disposition Summary:

    Value box classes shouldn't be assignable

    Update to work with ValueBase

  • Updated: Mon, 29 Mar 2021 12:21 GMT

Missing deleted assignment/copy operators

  • Key: CPP1115-8
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    ValueFactoryBase should have deleted assignment/copy operators so add to the code part

    private:
    ValueFactoryBase (ValueFactoryBase&&) = delete;
    ValueFactoryBase (const ValueFactoryBase&) = delete;
    ValueFactoryBase& operator =(const ValueFactoryBase&) = delete;
    ValueFactoryBase& operator =(ValueFactoryBase&&) = delete;

  • Reported: CPP11 1.4 — Mon, 28 Sep 2020 14:38 GMT
  • Disposition: Resolved — CPP11 1.5
  • Disposition Summary:

    Add deleted special member functions to ValueFactoryBase

    Use the C++11 "= delete" feature for ValueFactoryBase.

  • Updated: Mon, 29 Mar 2021 12:21 GMT

Operations tagged with override shouldn't have virtual

  • Key: CPP1115-3
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    Any C++11 operation in the spec which uses override shouldn't have virtual, that is redundant and shouldn't be done, so for example

    virtual void val2 (int32_t) override;

    Should be

    void val2 (int32_t) override;

    Easiest is to search for override and check that any operation that has override doesn't have virtual

  • Reported: CPP11 1.4 — Fri, 18 Sep 2020 08:23 GMT
  • Disposition: Resolved — CPP11 1.5
  • Disposition Summary:

    Remove uses of the C++ virtual keyword that aren't needed

    Member functions declared with "override" should not also have "virtual"

  • Updated: Mon, 29 Mar 2021 12:21 GMT

_default_POA should use override

  • Key: CPP1115-2
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The operation _default_POA currently declared as

    IDL::traits<PortableServer::POA>::ref_type _default_POA()

    Should be

    IDL::traits<PortableServer::POA>::ref_type _default_POA() override

    Also the formatting of the constructor of the TIE template should be changed, hard to read. Initializing the members could use std::move so change

    : tied_object_(t), poa_(poa)

    to

    : tied_object_(std::move(t)), poa_(std::move(poa))

  • Reported: CPP11 1.4 — Fri, 18 Sep 2020 07:43 GMT
  • Disposition: Resolved — CPP11 1.5
  • Disposition Summary:

    Updated code for Delegation-Based Interface Implementation

    Update code to reflect C++ best practices

  • Updated: Mon, 29 Mar 2021 12:21 GMT

Add support for bitset/bitfield/bitmask

  • Key: CPP1115-1
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The IDL to C++11 language mapping section 6.31 should be extended for bitset/bitfield/bitmask from IDL4 (Building Block Extended Data-Types)

  • Reported: CPP11 1.4 — Fri, 18 Sep 2020 07:03 GMT
  • Disposition: Resolved — CPP11 1.5
  • Disposition Summary:

    Bitset and Bitmask mapping

    Bitsets and bitmasks are "top-level" IDL4 extended data types that can each be mapped to C++11.

  • Updated: Mon, 29 Mar 2021 12:21 GMT

Add Delegation-Based Interface Implementation

  • Key: CPP1114-31
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The current IDL to C++11 language mapping only describes an inheritance based interface implementation in chapter 6.26.6. The IDL to C++ language mapping also described a delegation based implementation. We propose to add a delegation based implementation to the IDL to C++11 specification.

    I will attach a proposal new chapter 6.26.7, only the formatting of IDL and C++ types has to be done in the final document, especially types in the text itself need to be formatted. In the first paragraph there is a number 126, that has to be updated.

  • Reported: CPP11 1.3 — Wed, 31 Oct 2018 12:43 GMT
  • Disposition: Resolved — CPP11 1.4
  • Disposition Summary:

    Mapping for implementing interfaces via delegation

    This issue adds the mapping for implementing interfaces via delegation, a feature of the IDL-to-C++ mapping that has been lacking in this spec.

  • Updated: Mon, 1 Apr 2019 18:18 GMT
  • Attachments:

Remove the setter operation for the discriminator of a union

  • Key: CPP1114-14
  • Status: closed  
  • Source: ZettaScale Technology ( Erik Hendriks)
  • Summary:

    The C++11 mapping of an IDL union seems to follow that of the classic C++ mapping, where the discriminator does not only have a getter-operation, but also a setter operation. This operation has been added for situations where more than one case label applies to to the same union branch, and the setter operation for that union branch implicitly sets the discriminant value to the first case label that was specified. If you want to pick another value, you should do so by invoking the setter function for the discriminant.

    However, this setter operation is confusing to many users, and some seem to think you need to use it every time you passed a value into a branch different than the current branch. On top of that. it seems cumbersome to have to make two separate method invocations to request a single modification that is intended to set branch value and corresponding discriminator value atomically.

    Much better would be to take the route that has been adopted in the Java language mapping for the union: if there is more than one case label that applies to a union branch, you add an overloaded setter method for that branch that does not only allow you to pass the value for that branch, but also the value for the discriminator. This overloaded setter function will than validate whether the discriminant value you pass actually applies to the branch that you are trying to set.

  • Reported: CPP11 1.3 — Tue, 25 Sep 2018 20:14 GMT
  • Disposition: Resolved — CPP11 1.4
  • Disposition Summary:

    Unions: Provide a way to set both the discriminator and value at the same time

    Enhance the mapping of IDL union to allow setting the discriminator at the same time a new union element value is provided. This change maintains compatibility for applications written to the current spec version.

  • Updated: Mon, 1 Apr 2019 18:18 GMT

Bullets before IDL::traits::narrow(ap) lost

  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    Compared to V1.2 in 6.7.6 four bullets before IDL::traits<A>::narrow(ap) got removed

  • Reported: CPP11 1.3 — Fri, 30 Mar 2018 09:53 GMT
  • Disposition: Resolved — CPP11 1.4
  • Disposition Summary:

    Make part of 6.7.6 a bulleted list

    This was somehow lost between v1.2 and v1.3.

  • Updated: Mon, 1 Apr 2019 18:18 GMT

OBV_Example constructor

  • Key: CPP1114-9
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The OBV_Example constructor has multiple arguments and shouldn't be explicit. Also a closing ) is lacking from the example code. The operations for val2 should also use "override"

  • Reported: CPP11 1.3 — Fri, 30 Mar 2018 09:40 GMT
  • Disposition: Resolved — CPP11 1.4
  • Disposition Summary:

    Update OBV_Example class in 6.18.4

    Updates as suggested, making the C++ example code consistent with the prose of 6.18.2 and common conventions.

  • Updated: Mon, 1 Apr 2019 18:18 GMT

Text alignment

  • Key: CPP1114-8
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The operation "virtual int16_6& val1() = 0;" is not aligned correctly in the code example

  • Reported: CPP11 1.3 — Fri, 30 Mar 2018 09:38 GMT
  • Disposition: Resolved — CPP11 1.4
  • Disposition Summary:

    Fix C++ code in 6.18.4

    Fixing a minor typo/formatting bug in this section.

  • Updated: Mon, 1 Apr 2019 18:18 GMT

Typo fixes

  • Key: CPP1114-7
  • Status: closed  
  • Source: Airbus Group ( Oliver Kellogg)
  • Summary:

    Section 6.11 on page 11, 2nd paragraph:

    Implementations of the bounded wide string are under no oblication to perform a bounds check [...]

    obligation

    Table 6.10 on page 14, bottom row, right column

    dimensions std::integral_constant type of value_type uint32_t indicating the
    number of dimensaions of the array

    [...] dimensions of the array

    Section 6.18.7.2 page 30 top, continuation of code from p.29

    protected:
          ColorValue();
          xplicit ColorValue(Color);
    

    explicit ColorValue(Color);

    Section 6.19.1 on page 34, code for class AbstractBase

    class AbstractBase {
          public:
                virtual IDL::traits<Object>::ref_type _to_object();
                virtual IDL::traits<ValueBase>::ref_type _to_value();
          protected:
                AbstractBase();
                bstractBase(const AbstractBase&);
    

    AbstractBase(const AbstractBase&);

    Section 6.22.2 on page 40 top (code continued from p.39)

                int16_t fixed_scale() const;
                Visibility member_visibility(uin32_t index) const;
    

    Type of index argument should be uint32_t.

  • Reported: CPP11 1.3b1 — Sat, 3 Mar 2018 13:21 GMT
  • Disposition: Resolved — CPP11 1.4
  • Disposition Summary:

    Fix typos

    The submitted issue (CPP1114-7) lists a few other typos, but those are already fixed in formal/18-01-06.

  • Updated: Mon, 1 Apr 2019 18:18 GMT

Only single argument constructors have to be explicit

  • Key: CPP1114-13
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    For struct/exception/valuetype the spec describes that a constructor accepting values for all members has to generated as explicit constructor, but it only has to be explicit when there is one (1) member, when there are >1 member the constructor doesn't need to be explicit. This has to be updated in the text and examples

  • Reported: CPP11 1.3 — Tue, 7 Aug 2018 10:48 GMT
  • Disposition: Closed; No Change — CPP11 1.4
  • Disposition Summary:

    Reporter of the Issue has asked for it to be withdrawn

    Closing this one by request of Reporter.

  • Updated: Mon, 1 Apr 2019 18:18 GMT

Errors in IDL Built-in Annotations Usage Table

  • Key: CPP1114-4
  • Status: closed  
  • Source: Real-Time Innovations ( Fernando Garcia-Aranda)
  • Summary:

    In the submission document, Table 21 "IDL Built-in Annotations" does not list where the annotation @hashid can be applied.

    Also, the @id annotation is can be applied to both Structure members and union members (except union discriminator), so it should be moved to the second row on the table.

  • Reported: CPP11 1.2 — Thu, 16 Mar 2017 00:36 GMT
  • Disposition: Closed; Out Of Scope — CPP11 1.4
  • Disposition Summary:

    Issue was added to the wrong RTF

    This issue is not in IDL-to-C++11.

  • Updated: Mon, 1 Apr 2019 18:18 GMT

Make mapping of sequences more flexible

  • Key: CPP1114-3
  • Legacy Issue Number: 19499
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    In 6.12 we define:

    An unbounded sequence is mapped to a C++ std::vector.

    For example a sequence of octets is now not optimal, in order for implementations to optimize sequences but users not to harm we propose to change this definition to

    An unbounded sequence is mapped to a type delivering C++ std::vector semantics.

  • Reported: CPP11 1.1 — Tue, 1 Jul 2014 04:00 GMT
  • Disposition: Resolved — CPP11 1.4
  • Disposition Summary:

    Flexible mapping for sequence and map types

    Allow implementations more flexibility: in certain cases when the spec currently requires use of a C++ standard library type, the implementation should be able to use a substitute type that's interface-compatible.

  • Updated: Mon, 1 Apr 2019 18:18 GMT

IDL2C++11 issue : CORBA dependency of the C++11 mapping

  • Key: CPP1114-2
  • Legacy Issue Number: 18533
  • Status: closed  
  • Source: THALES ( Nawel Hamouche)
  • Summary:

    A big effort have been done to remove CORBA dependency from the IDL2C++11 mapping, but it still specifies a CORBA semantic to the IDL
    interfaces and user exceptions. In 6.6.4, it is said "Conceptually, the Object class in the CORBA module is the base interface type for all objects;" this assertion breaks all that efforts. I think the semantic of IDL interfaces should be abstracted by defining a middleware-independent Object type as the super type of all IDL interfaces, it could be IDL::Object. Likewise, CORBA::UserException and CORBA::SystemException could be abstracted by defining IDL::UserExeption and IDL::SystemException.
    Looking to the IDL3.5 specification, it is true that this specification is still tied to CORBA, but special care has been done to separate between the syntactical construct and its semantic. For instance, it is said 'See the CORBA 3.2 specfication Section 10.2 “Semantics of Abstract Interfaces” for CORBA implementation semantics associated with abstract interfaces.'. It means that there could be other semantics than CORBA.
    I would suggest the following changes in the IDL2CPP11 specification :

    • To introduce IDL::Object, IDL::LocalObject, IDL::UserExeption and IDL::SystemException.
    • To not consider an IDL interface as a CORBA Object and rephrase section 6.6.4 accordingly.
    • To not consider a user exception as a CORBA exeption and rephrase section 6.19 accordingly.
    • To group all CORBA-dependent mappings and APIs in one section "CORBA mapping". This section would include :
      6.16 Mapping for the Any Type
      6.17 Mapping for Valuetypes
      6.18.1 Abstract Interface Base
      6.21 TypeCode
      6.22 ORB
      6.23 Object
      6.24 LocalObject
      ... until 6.28
  • Reported: CPP11 1.1 — Thu, 7 Mar 2013 05:00 GMT
  • Disposition: Closed; Out Of Scope — CPP11 1.4
  • Disposition Summary:

    IDL v4 is a standalone specification

    This specification has no normative reference for IDL v4.

    I have implementation experience applying portions of this spec to a non-CORBA middleware (which happens to be a DDS implementation). Those sections of this spec that apply (6.3, 6.4, 6.5, 6.6, 6.8-16, 6.30-31) do not use the CORBA module/namespace.

  • Updated: Mon, 1 Apr 2019 18:18 GMT

In-place construction of structure types

  • Key: CPP1114-1
  • Legacy Issue Number: 17420
  • Status: closed  
  • Source: Real-Time Innovations ( Sumant Tambe)
  • Summary:

    There are two main motivations:

    (1) Performance: IDL types may be large and not all IDL types may have C++11 mapping with efficient move constructors. For example, an IDL structure containing an array does not have an efficient move-ctor. Current mapping for an IDL struct type (section 6.13.1) requires an explicit constructor accepting values for each member by value in the order they are specified in IDL. Although this method is sufficient in most cases, it is not optimal. Particularly, the types that don't support efficient move-ctor.

    (2) Usability: Often C+11 standard library containers could be constructed using several alternatives. For instance, a string member in a struct may be constructed using any of its 9 constructors or a vector may be constructed using any of its 7 constructors. Currently, the IDL2C+11 specification allows construction of members of a structure using only two kinds of constructors: copy-ctor and move-ctor. (due to the pass-by-value rule mentioned above)

    Resolution: The IDL2C++11 mapping of structures could be enhanced to construct large objects in-place. Provide a way to construct the member objects of a struct in-place using a perfect-forwarding constructor. The intent is to support all the ways of constructing all the member objects from the constructor of the parent object. Moreover, a perfect-forwarding constructor may eliminate the need for a move, which may lead to some performance improvements.

    The solution relies on an idiom known as piecewise_construct idiom. It relies on a perfect-forwarding constructor that takes as many tuples as there are members in a struct. Each tuple encapsulates the parameters to construct one member. Tuples are needed because member ctor could take several parameters and the user may be interested in using them. For instance, using an allocator for std::vector. The user of the struct calls std::forward_as_tuple for each member object to group the parameters in a tuple. The special constructor simply forwards the tuples to the respective member.

    The C++ standard library uses this idiom for std::map and std::unordered_map to construct complex objects in-place using the emplace operations. However, more general uses have been identified: http://cpptruths.blogspot.com/2012/06/perfect-forwarding-of-parameter-groups.html

  • Reported: CPP11 1.0 — Mon, 11 Jun 2012 04:00 GMT
  • Disposition: Closed; No Change — CPP11 1.4
  • Disposition Summary:

    Existing alternatives for struct construction appear to be sufficient

    Since the issue has been unresolved for a number of RTFs I'm proposing we close it now.
    The proposed enhancement could be provided by implementations as an extension to the spec-mandated behavior.
    I don't argue that there is some benefit from this approach, but there is also implementation complexity: when generating a struct constructor, the tool will need to know, for each struct member, which constructor parameters that member can take. Those parameters can vary based on versions of the C++ standard library (for types like std::string, vector, array, map).

  • Updated: Mon, 1 Apr 2019 18:18 GMT

Reduce indent

  • Key: CPP1114-11
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    Reduce the indent of public, should start on the first line, makes it all more readable

  • Reported: CPP11 1.3 — Fri, 30 Mar 2018 09:52 GMT
  • Disposition: Resolved — CPP11 1.4
  • Disposition Summary:

    Update source code formatting

    Remove extra indenting that can force line wrapping and make embedded source code hard to read.

  • Updated: Mon, 1 Apr 2019 18:18 GMT

Alignment _is_a and _non_existent

  • Key: CPP1114-10
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    There are tabs between bool and the method names, they should be removed

  • Reported: CPP11 1.3 — Fri, 30 Mar 2018 09:48 GMT
  • Disposition: Resolved — CPP11 1.4
  • Disposition Summary:

    Update code in 6.26.2

    Minor formatting change as suggested.

  • Updated: Mon, 1 Apr 2019 18:18 GMT

Structure mapping change should be reverted

  • Key: CPP1114-5
  • Status: closed   Implementation work Blocked
  • Source: Self ( Jonathan Biggar)
  • Summary:

    The C++11 IDL language mapping for IDL struct datatypes was changed to a Java-style getter & setter interface. This should be reverted for the following reasons:

    1. The original struct mapping (just use data members) performs better at compile and runtime. The new mapping compiles slower by changing each data member to 4! different accessor functions, and at runtime is slower due to the need for the function call. (Modern compilers cannot optimize this call away without global optimization, which is not generally available in C++ implementations, or else the accessor functions must all be defined inline for the compiler to optimize away the function call.)

    2. Java style getter and setter interfaces are not considered good C++ style by the experts. https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#c131-avoid-trivial-getters-and-setters

    3. The change breaks massive amount of user code for no benefit.

  • Reported: CPP11 1.2 — Mon, 6 Nov 2017 01:15 GMT
  • Disposition: Closed; No Change — CPP11 1.4
  • Disposition Summary:

    Structure mapping shouldn't change within a minor revision of IDL-to-C++11

    Keep in mind that IDL-to-C++ and IDL-to-C++11 are independent specifications. In cases where IDL-to-C++11 takes a different approach to mapping the same IDL features, this isn't a "change" from the spec's point of view.

    However, I'm sympathetic to the notion that it could be a "change" from an implementer/user's point of view as a single IDL translation tool that previously used just IDL-to-C++ could, in a new version, use IDL-to-C++11 (either exclusively or as an option). Since I help maintain some IDL translation tools that do this, I've had to deal with this myself.

    One thing to note is that nothing in IDL-to-C++11 prevents the implementation from providing public data members in mapped structs. Unfortunately the names of those data members would be non-standard. Also, as described in the comments on the parent issue, direct data member usage makes upcoming IDLv4 features like @min/@max harder to support.

  • Updated: Mon, 1 Apr 2019 18:18 GMT

Fixed is now broken

  • Key: CPP1114-6
  • Status: closed   Implementation work Blocked
  • Source: Self ( Jonathan Biggar)
  • Summary:

    The fixed type was changed from the old C++ mapping, removing the non-template Fixed class and mandating that Fixed be implemented as a template. These changes disrupted the careful design of Fixed support for C++ in several ways:

    1. There is now no information or guidance about what type is used when declaring a fixed constant in IDL.

    2. The original specification was careful to not mandate whether the C++ mapping used a template definition to enforce constant digits and scale values for fixed point data defined in IDL, yet specifically states that the user should only use the typedefs generated by the IDL compiler Thus the current specification unnecessarily limits implementation choice for fixed point support for no useful implementation purpose.

    3. Removal of the non-template Fixed class makes it harder for the implementation to meet the "double precision (62 digit)" arithmetic guarantee.

    The C++ mapping for Fixed should be restored use the language of the old C++ 1.3 language mapping.

  • Reported: CPP11 1.2 — Mon, 6 Nov 2017 00:58 GMT
  • Disposition: Resolved — CPP11 1.4
  • Disposition Summary:

    Updates to the mapping of the IDL Fixed data type

    Change the mapping of the IDL fixed type data to allow some more implementation flexibility and familiarity from the IDL-to-C++ mapping.

  • Updated: Mon, 1 Apr 2019 18:18 GMT

Errors in IDL Built-in Annotations Usage Table

  • Key: CPP1113-11
  • Status: closed  
  • Source: Real-Time Innovations ( Fernando Garcia-Aranda)
  • Summary:

    In the submission document, Table 21 "IDL Built-in Annotations" does not list where the annotation @hashid can be applied.

    Also, the @id annotation is can be applied to both Structure members and union members (except union discriminator), so it should be moved to the second row on the table.

  • Reported: CPP11 1.2 — Thu, 16 Mar 2017 00:36 GMT
  • Disposition: Deferred — CPP11 1.3
  • Disposition Summary:

    This Issue was not resolved in this Task Force and was automatically deferred to the next Task Force

  • Updated: Tue, 19 Dec 2017 20:21 GMT

IDL2C++11 issue : CORBA dependency of the C++11 mapping

  • Key: CPP1113-6
  • Legacy Issue Number: 18533
  • Status: closed  
  • Source: THALES ( Nawel Hamouche)
  • Summary:

    A big effort have been done to remove CORBA dependency from the IDL2C++11 mapping, but it still specifies a CORBA semantic to the IDL
    interfaces and user exceptions. In 6.6.4, it is said "Conceptually, the Object class in the CORBA module is the base interface type for all objects;" this assertion breaks all that efforts. I think the semantic of IDL interfaces should be abstracted by defining a middleware-independent Object type as the super type of all IDL interfaces, it could be IDL::Object. Likewise, CORBA::UserException and CORBA::SystemException could be abstracted by defining IDL::UserExeption and IDL::SystemException.
    Looking to the IDL3.5 specification, it is true that this specification is still tied to CORBA, but special care has been done to separate between the syntactical construct and its semantic. For instance, it is said 'See the CORBA 3.2 specfication Section 10.2 “Semantics of Abstract Interfaces” for CORBA implementation semantics associated with abstract interfaces.'. It means that there could be other semantics than CORBA.
    I would suggest the following changes in the IDL2CPP11 specification :

    • To introduce IDL::Object, IDL::LocalObject, IDL::UserExeption and IDL::SystemException.
    • To not consider an IDL interface as a CORBA Object and rephrase section 6.6.4 accordingly.
    • To not consider a user exception as a CORBA exeption and rephrase section 6.19 accordingly.
    • To group all CORBA-dependent mappings and APIs in one section "CORBA mapping". This section would include :
      6.16 Mapping for the Any Type
      6.17 Mapping for Valuetypes
      6.18.1 Abstract Interface Base
      6.21 TypeCode
      6.22 ORB
      6.23 Object
      6.24 LocalObject
      ... until 6.28
  • Reported: CPP11 1.1 — Thu, 7 Mar 2013 05:00 GMT
  • Disposition: Deferred — CPP11 1.3
  • Disposition Summary:

    Deferred

    Deferred to future RTF

  • Updated: Tue, 19 Dec 2017 20:21 GMT

Make mapping of sequences more flexible

  • Key: CPP1113-7
  • Legacy Issue Number: 19499
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    In 6.12 we define:

    An unbounded sequence is mapped to a C++ std::vector.

    For example a sequence of octets is now not optimal, in order for implementations to optimize sequences but users not to harm we propose to change this definition to

    An unbounded sequence is mapped to a type delivering C++ std::vector semantics.

  • Reported: CPP11 1.1 — Tue, 1 Jul 2014 04:00 GMT
  • Disposition: Deferred — CPP11 1.3
  • Disposition Summary:

    Deferred

    Deferred

  • Updated: Tue, 19 Dec 2017 20:21 GMT

In-place construction of structure types

  • Key: CPP1113-5
  • Legacy Issue Number: 17420
  • Status: closed  
  • Source: Real-Time Innovations ( Sumant Tambe)
  • Summary:

    There are two main motivations:

    (1) Performance: IDL types may be large and not all IDL types may have C++11 mapping with efficient move constructors. For example, an IDL structure containing an array does not have an efficient move-ctor. Current mapping for an IDL struct type (section 6.13.1) requires an explicit constructor accepting values for each member by value in the order they are specified in IDL. Although this method is sufficient in most cases, it is not optimal. Particularly, the types that don't support efficient move-ctor.

    (2) Usability: Often C+11 standard library containers could be constructed using several alternatives. For instance, a string member in a struct may be constructed using any of its 9 constructors or a vector may be constructed using any of its 7 constructors. Currently, the IDL2C+11 specification allows construction of members of a structure using only two kinds of constructors: copy-ctor and move-ctor. (due to the pass-by-value rule mentioned above)

    Resolution: The IDL2C++11 mapping of structures could be enhanced to construct large objects in-place. Provide a way to construct the member objects of a struct in-place using a perfect-forwarding constructor. The intent is to support all the ways of constructing all the member objects from the constructor of the parent object. Moreover, a perfect-forwarding constructor may eliminate the need for a move, which may lead to some performance improvements.

    The solution relies on an idiom known as piecewise_construct idiom. It relies on a perfect-forwarding constructor that takes as many tuples as there are members in a struct. Each tuple encapsulates the parameters to construct one member. Tuples are needed because member ctor could take several parameters and the user may be interested in using them. For instance, using an allocator for std::vector. The user of the struct calls std::forward_as_tuple for each member object to group the parameters in a tuple. The special constructor simply forwards the tuples to the respective member.

    The C++ standard library uses this idiom for std::map and std::unordered_map to construct complex objects in-place using the emplace operations. However, more general uses have been identified: http://cpptruths.blogspot.com/2012/06/perfect-forwarding-of-parameter-groups.html

  • Reported: CPP11 1.0 — Mon, 11 Jun 2012 04:00 GMT
  • Disposition: Deferred — CPP11 1.3
  • Disposition Summary:

    Deferred

    Without specific spec wording from someone who has implemented it, I don't think we can standardize this feature.

  • Updated: Tue, 19 Dec 2017 20:21 GMT

Example C++ code in mapping for constants should use C++11 uniform initialization

  • Key: CPP1113-10
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The mapping for constants should use uniform initialization in section 6.8 instead of using the assignment. The code
    const std::string name = "testing";
    static constexpr float pi = 3.14159;

    Should be
    const std::string name

    {"testing"}

    ;
    static constexpr float pi

    {3.14159}

    ;

  • Reported: CPP11 1.2 — Tue, 10 Nov 2015 07:56 GMT
  • Disposition: Resolved — CPP11 1.3
  • Disposition Summary:

    IDL constants should use C++ direct list initializaiton

    When IDL constants are mapped to C++, they become namespace or class scoped const (or constexpr) objects. Use direct list initialization to give these objects values.

  • Updated: Tue, 19 Dec 2017 20:10 GMT

IDL2C++11 mapping lacks support for the new IDL type map

  • Key: CPP1113-1
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The DDS-XTypes specification extends the IDL type system which will be integrated into the IDL4 specification. The IDL2C++11 mapping should be extended with a new section describing the support for the IDL map type.

  • Reported: CPP11 1.1 — Tue, 26 Aug 2014 11:43 GMT
  • Disposition: Resolved — CPP11 1.3
  • Disposition Summary:

    Import the mapping of IDL Map from XTypes 1.2

    XTypes 1.2 (beta) ptc/17-03-06 section 7.5.1.3.4 maps the IDL Map type to "Modern C++", that mapping can be used by this spec directly

  • Updated: Tue, 19 Dec 2017 20:10 GMT

Fix assignment operator of ColorValue

  • Key: CPP1113-9
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The code example as part of 6.18.7.2 has:
    ColorValue& operator=(const Color&);

    but this should be
    ColorValue& operator=(const ColorValue&);

  • Reported: CPP11 1.2 — Mon, 3 Aug 2015 17:32 GMT
  • Disposition: Resolved — CPP11 1.3
  • Disposition Summary:

    Fix argument type of copy assignment operator in 6.18.7.2

    Looks to be a typo in the original spec. The class name is ColorValue which should be used here

  • Updated: Tue, 19 Dec 2017 20:10 GMT

CORBA::make_reference shouldn't explicitly imply perfect forwarding

  • Key: CPP1113-8
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    In section 6.7.1 in the 4th paragraph the CORBA::make_reference<> is mentioned, but it ends using "using perfect forwarding". Where this is probably the best way to implement this, it shouldn't be mandated by the specification. Propose to remove "using perfect forwarding" from the text of this paragraph

  • Reported: CPP11 1.2 — Fri, 22 May 2015 14:03 GMT
  • Disposition: Resolved — CPP11 1.3
  • Disposition Summary:

    Relax requirement for perfect forwarding in 6.7.1

    The C++ idea of "perfect forwarding" doesn't need to be specified here. An implementation may decide to use it.

  • Updated: Tue, 19 Dec 2017 20:10 GMT

Handle possible exception what conflict and improve Exception introduction text

  • Key: CPP1113-4
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    Because of the mapping of Exception to something derived from std::exception where is a possible conflict when the user has an exception member with the member name "what" because std::exception provides an operation what(). We propose to change the start of section 6.20 to the text below instead of the first two bullets currently in the specification

    An OMG IDL exception is mapped to a C++ class that derives from the standard UserException class. Each OMG IDL exception member maps to a set of corresponding member methods as described in “Mapping for Structured Types” on page 14. When the IDL exception member identifier is "what", the string “cxx” is prepended to the identifier to resolve a conflict with the std::exception what() operation.

    The copy constructor, move constructor, copy assignment operator, move assignment operator, and destructor automatically copy, move, or free the storage associated with the exception. For convenience, the mapping also defines an explicit constructor with one parameter for each exception member in the order they are specified in IDL—this constructor initializes the exception members to the given values. The default constructor initializes all members to their default values as described in “Mapping for Structured Types” on page 14.

  • Reported: CPP11 1.2 — Mon, 13 Apr 2015 08:36 GMT
  • Disposition: Resolved — CPP11 1.3
  • Disposition Summary:

    Possible name conflict involving "what" and exceptions.

    See Johnny's comment on issue #4

  • Updated: Tue, 19 Dec 2017 20:10 GMT

Trivial grammatic fix in 6.14.1

  • Key: CPP1113-3
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    In 6.14.1 (mapping for struct type) the second sentence is

    Additionally to the methods as described in “Mapping for Structured Types” on page 14 an explicit constructor accepting values for struct each member in the order they are specified in IDL.

    This should be

    Additionally to the methods as described in “Mapping for Structured Types” on page 14 an explicit constructor accepting values for each struct member in the order they are specified in IDL.

    The order of "struct" and "each" should be swapped

  • Reported: CPP11 1.2 — Sun, 12 Apr 2015 17:43 GMT
  • Disposition: Resolved — CPP11 1.3
  • Disposition Summary:

    Edit section 6.14.1 for clarity

    Updated prose description of mapped struct, C++ remains unchanged.

  • Updated: Tue, 19 Dec 2017 20:10 GMT

minor accessors of SystemException should use pass by value, minor should be uint32_t

  • Key: CPP1113-2
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    For SystemException class on page 36 mentions

    const int32_t& minor() const;
    void minor(const int32_t&);

    But this is a basic type which we pass by value. Also minor should be an uint32_t, the code should list

    uint32_t minor() const;
    void minor(uint32_t);

    Also the CompletionStatus is returned by value, no need for a const, so change

    const CompletionStatus completed() const;

    to

    CompletionStatus completed() const;

    As last the constructor

    explicit SystemException(int32_t minor, CompletionStatus status);

    Should be

    SystemException(uint32_t minor, CompletionStatus status);

  • Reported: CPP11 1.2 — Sun, 12 Apr 2015 17:35 GMT
  • Disposition: Resolved — CPP11 1.3
  • Disposition Summary:

    SystemException updates

    Proposed resolution is included in Issue #2 description

  • Updated: Tue, 19 Dec 2017 20:10 GMT

Only a namespace level swap should be provided

  • Key: CPP1113-13
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The specification mentions that besides a namespace level swap a specialization of std::swap<> has to be provided, but that shouldn't, see http://en.cppreference.com/w/cpp/concept/Swappable. Only a namespace level swap should be enough. This impacts the text of section 6.7.1, the example and text of 6.14.1, example of 6.14.2

  • Reported: CPP11 1.2 — Mon, 19 Jun 2017 14:05 GMT
  • Disposition: Resolved — CPP11 1.3
  • Disposition Summary:

    Remove std::swap requirement

    Overload swap() in the appropriate namespace, do not do anything with std::swap.

  • Updated: Tue, 19 Dec 2017 20:10 GMT

Fix unclarity in IDL Union description

  • Key: ITCR-57
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    In section 4 of paragraph 6.14.2 it says " If a modifier for a union member with multiple legal discriminant values is used to set the value of the discriminant, the union implementation will take the first discriminant specified in IDL.". It is not the "first discriminant" but the "first discriminant value". This is triggered by the resolution of ITCR-5

  • Reported: CPP11 1.1 — Tue, 13 Jan 2015 15:50 GMT
  • Disposition: Resolved — CPP11 1.2
  • Disposition Summary:

    Clarify discriminant

    The text should be clear to refer to "discriminant value"

  • Updated: Wed, 8 Jul 2015 11:43 GMT

Update normative reference to point to CORBA 3.3

  • Key: ITCR-54
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The IDL to C++11 language mapping refers to CORBA v3.2, in the meantime CORBA v3.3 is there, so update the normative reference in section 3 to point to CORBA 3.3

  • Reported: CPP11 1.1 — Tue, 13 Jan 2015 08:08 GMT
  • Disposition: Resolved — CPP11 1.2
  • Disposition Summary:

    Update reference

    Update the reference to CORBA 3.3, there are no changes in CORBA 3.3 that impact IDL2C++11 but it is good to refer to the latest version of the CORBA specification

  • Updated: Wed, 8 Jul 2015 11:43 GMT

IDL2C++11 mapping lacks support for the new IDL type map

  • Key: ITCR-38
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The DDS-XTypes specification extends the IDL type system which will be integrated into the IDL4 specification. The IDL2C++11 mapping should be extended with a new section describing the support for the IDL map type.

  • Reported: CPP11 1.1 — Tue, 26 Aug 2014 11:43 GMT
  • Disposition: Deferred — CPP11 1.2
  • Disposition Summary:

    Defer to future RTF

    We propose to defer this to the next RTF because we haven't been able to prototype this in order to validate some ideas we had. Especially the needed IDL::traits<> has to be tested and tried

  • Updated: Wed, 8 Jul 2015 11:43 GMT

Servant argument passing not precise enough

  • Key: ITCR-28
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    Section 6.26.4 describes the argument passing for Servant, but this should use CORBA::servant_traits<PortableServer::Servant>::ref_type instead of CORBA::servant_traits<T>::ref_type

  • Reported: CPP11 1.1 — Thu, 21 Aug 2014 11:06 GMT
  • Disposition: Resolved — CPP11 1.2
  • Disposition Summary:

    Servant argument passing not precise enough

    The servant argument passing should be corrected as proposed by the issue

  • Updated: Wed, 8 Jul 2015 11:43 GMT

Missing public specifier

  • Key: ITCR-39
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The last code example of section 6.26.6 lacks the public specifier for the class MyA. Instead of "class MyA : virtual" it should be "class MyA : public virtual"

  • Reported: CPP11 1.1 — Wed, 10 Dec 2014 12:05 GMT
  • Disposition: Resolved — CPP11 1.2
  • Disposition Summary:

    Add missing public specifier

    The issue is correct, the code example should use "public virtual" instead of just "virtual"

  • Updated: Wed, 8 Jul 2015 11:43 GMT

replace POA_B by adequate skeleton

  • Key: ITCR-42
  • Legacy Issue Number: 19678
  • Status: closed  
  • Source: langensoft.com ( T. Langen)
  • Summary:

    drop POA_B for skeleton class deriveved from abstract class and replace it adequately:

    // C++
    class A

    { ... }

    class B_skel : public virtual ... /* maybe PortableServer::Servant */,
    protected virtual A

    { ... }

    ;

  • Reported: CPP11 1.1 — Wed, 10 Dec 2014 05:00 GMT
  • Disposition: Resolved — CPP11 1.2
  • Disposition Summary:

    Remove usage of B_Skel and remove mentioning of PortableServer::ServantBase

    The report is correct, POA_B is a left over of the old IDL to C++ language mapping. At the same time we want to remove the mandatory inheritance of PortableServer::ServantBase, that is something for the vendor to decide, not important for the user.

  • Updated: Wed, 8 Jul 2015 11:43 GMT

_this for skeleton, not for implementation

  • Key: ITCR-41
  • Legacy Issue Number: 19672
  • Status: closed  
  • Source: langensoft.com ( T. Langen)
  • Summary:

    _this() method example should be given for the skeleton (eg. A_skel), not for implementation (A_impl):

    // C++
    class A_skel
    : public virtual PortableServer::Servant

    { IDL::traits<A>::ref_type _this(); ... }
  • Reported: CPP11 1.1 — Mon, 8 Dec 2014 05:00 GMT
  • Disposition: Resolved — CPP11 1.2
  • Disposition Summary:

    Correct code example for _this

    The code example defines the _this in the wrong class, it should be done in the skeleton class, not in the user implementation class. Because the example inheritance of the skeleton classes is up to the vendor also the inheritance of CORBA::servant_traits<A>::base_type should be removed and replaced with three dots. As last is the override something that should be removed.

  • Updated: Wed, 8 Jul 2015 11:43 GMT

Skeleton class as consistent template parameter for CORBA::servant_traits

  • Key: ITCR-44
  • Legacy Issue Number: 19697
  • Status: closed  
  • Source: langensoft.com ( T. Langen)
  • Summary:

    Instead of the IDL interface class, the skeleton class should be used as template parameter for CORBA::servant_traits<>.

    Rationale:

    1. The servant which the traits describe is realized by an instance of a class derived from the skeleton class which in turn (directly or indireclty) inherits PortableServer::Servant but not necessarily the interface class.

    PortableServant::Server < ... < CORBA::servant_traits<A_skel>::base_type < A_impl

    instead of

    PortableServant::Server < ... < CORBA::servant_traits<A>::base_type < A_impl

    (A, A_skel and A_impl are arbitrary names denoting the interface, the skeleton and the implementation class, resp.).

    2. In chapter 6.26.4 "Servant argument passing", we have CORBA::servant_traits<PortableServer::Servant>; this takes (the very basic) servant class as template parameter.

    CORBA::servant_traits<PortableServer::Servant>::ref_type < CORBA::servant_traits<A_skel>::ref_type

    instead of

    CORBA::servant_traits<PortableServer::Servant>::ref_type < CORBA::servant_traits<A>::ref_type

    3. In chapter 6.26.3 "Servant references" CORBA::make_reference<...> takes the implementation class as argument to create a CORBA::servant_traits<...>::ref_type. This would be more consistent with CORBA::make_reference<...> taking an interface class as parameter to create IDL::traits<...>::ref_type.

    CORBA::make_reference<A_impl> -> CORBA::servant_traits<A_skel>::ref_type

    like

    CORBA::make_reference<A> -> IDL::traits<A>::ref_type

    instead of

    CORBA::make_reference<A_impl> -> CORBA::servant_traits<A>::ref_type

    4. CORBA::servant_traits<...>::base_type is used as base class for implementation classes in §§ 6.26.6 and 6.26.7. Having CORBA::servant_traits<A_impl>::base_type instead of CORBA::servant_traits<A>::base_type is more consistent with the use of IDL::traits<LocalIF>::base_type denoting CORBA::LocalObject or something derived from CORBA::LocalObject.

    CORBA::servant_traits<A_skel>::base_type < A_impl

    like

    IDL::traits<LocalIF>::base_type < MyLocalIf

    instead of

    CORBA::servant_traits<A>::base_type < A_impl

    This affects all uses of servant_traits in §§ 6.26.3, 6.26.5, 6.26.6, 6.26.7.

    The disadvantage to be considered is that the naming of the skeleton class is not standardized, so implementation classes to be provided by a programmer using an IDL to C++11 framework package cannot longer inherit a well-specified base class like CORBA::servant_traits<A>::base_type. Instead something like CORBA::servant_traits<skeleton<A>>:base_type would be required where skeleton<...> is a framework-specific template.

  • Reported: CPP11 1.1 — Sat, 27 Dec 2014 05:00 GMT
  • Disposition: Closed; No Change — CPP11 1.2
  • Disposition Summary:

    Keep referring to A instead of A_skel

    One of the basic rules we defined for IDL2Cpp11 is that we don't want the user to remember all kind of rules to translate between the IDL name and some Cpp11 type. At the moment a IDL type is translated to multiple C++ types we are using the IDL traits. The concept of a skeleton exists in IDL2Cpp11 but the exact class of the skeleton is accessed by the user using the CORBA::servant_traits. The proposed change will complicate the life for the user without any benefit.

  • Updated: Wed, 8 Jul 2015 11:43 GMT

abstract interfaces with corrected skeleton name

  • Key: ITCR-43
  • Legacy Issue Number: 19686
  • Status: closed  
  • Source: langensoft.com ( T. Langen)
  • Summary:

    § 6.26.6, to the end, about abstract interfaces:

    I guess the C++ snippet should be like

    // C++
    class A

    { ... }

    class B_skel : public virtual ... /* maybe PortableServer::Servant */,
    protected virtual A

    { ... }

    ;

    dropping the old POA_B thing.

  • Reported: CPP11 1.1 — Mon, 15 Dec 2014 05:00 GMT
  • Disposition: Duplicate or Merged — CPP11 1.2
  • Disposition Summary:

    Duplicated issue

    This issue ITCR-43 looks to be a duplicate of ITCR-42

  • Updated: Wed, 8 Jul 2015 11:43 GMT

Errors on code snippet related to skeleton classes

  • Key: ITCR-3
  • Legacy Issue Number: 18761
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    There is an error in 6.25.6 related to the skeleton classes. The skeleton classes should derive from each other, not from the traits, so it should be as below, also C_skel is lacking.

    // C++
    class A_skel : public virtual PortableServer::ServantBase {};
    class B_skel : public virtual A_skel {};
    class C_skel : public virtual A_skel {};
    class D_skel : public virtual B_skel, public virtual C_skel {};

    The other code bits in this section also have to be checked and see if they are ok.

  • Reported: CPP11 1.0 — Thu, 6 Jun 2013 04:00 GMT
  • Disposition: Resolved — CPP11 1.2
  • Disposition Summary:

    Correct skeleton inheritance

    The traits shouldn't be used in this example, those are for user code.

  • Updated: Wed, 8 Jul 2015 11:43 GMT

In-place construction of structure types

  • Key: ITCR-1
  • Legacy Issue Number: 17420
  • Status: closed  
  • Source: Real-Time Innovations ( Sumant Tambe)
  • Summary:

    There are two main motivations:

    (1) Performance: IDL types may be large and not all IDL types may have C++11 mapping with efficient move constructors. For example, an IDL structure containing an array does not have an efficient move-ctor. Current mapping for an IDL struct type (section 6.13.1) requires an explicit constructor accepting values for each member by value in the order they are specified in IDL. Although this method is sufficient in most cases, it is not optimal. Particularly, the types that don't support efficient move-ctor.

    (2) Usability: Often C+11 standard library containers could be constructed using several alternatives. For instance, a string member in a struct may be constructed using any of its 9 constructors or a vector may be constructed using any of its 7 constructors. Currently, the IDL2C+11 specification allows construction of members of a structure using only two kinds of constructors: copy-ctor and move-ctor. (due to the pass-by-value rule mentioned above)

    Resolution: The IDL2C++11 mapping of structures could be enhanced to construct large objects in-place. Provide a way to construct the member objects of a struct in-place using a perfect-forwarding constructor. The intent is to support all the ways of constructing all the member objects from the constructor of the parent object. Moreover, a perfect-forwarding constructor may eliminate the need for a move, which may lead to some performance improvements.

    The solution relies on an idiom known as piecewise_construct idiom. It relies on a perfect-forwarding constructor that takes as many tuples as there are members in a struct. Each tuple encapsulates the parameters to construct one member. Tuples are needed because member ctor could take several parameters and the user may be interested in using them. For instance, using an allocator for std::vector. The user of the struct calls std::forward_as_tuple for each member object to group the parameters in a tuple. The special constructor simply forwards the tuples to the respective member.

    The C++ standard library uses this idiom for std::map and std::unordered_map to construct complex objects in-place using the emplace operations. However, more general uses have been identified: http://cpptruths.blogspot.com/2012/06/perfect-forwarding-of-parameter-groups.html

  • Reported: CPP11 1.0 — Mon, 11 Jun 2012 04:00 GMT
  • Disposition: Deferred — CPP11 1.2
  • Disposition Summary:

    Defer to future RTF

    The issues proposes an extension to the construction of structured types. A vendor could already add this as performance improvement without being it as part of the specification. Before adding this to the specification this addition first have to be shown in a concrete product to make sure it can be implemented and is usable for users. This hasn’t been done by any vendor yet which made us decide to defer this issue to a future RTF.

  • Updated: Wed, 8 Jul 2015 11:43 GMT

Clarify valuetype factory mapping

  • Key: ITCR-12
  • Legacy Issue Number: 19498
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The valuetype factory mapping is too focused on the implementation, it should just refer to IDL<T>::factory_type as base class for the user provided factory implementation and shouldn't refer to ValueFactoryBase, that is an internal detail.

    Ref devportal 3617

  • Reported: CPP11 1.1 — Wed, 20 Aug 2014 04:05 GMT
  • Disposition: Resolved — CPP11 1.2
  • Disposition Summary:

    Clarify valuetype factory mapping

    The current valuetype factory mapping ties the implementor of the specification to too much details, we should just mention the classes with their signatures and the traits.

  • Updated: Wed, 8 Jul 2015 11:43 GMT

Valuebox should also have swap support

  • Key: ITCR-11
  • Legacy Issue Number: 19260
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    For valueboxes the spec should also describe swap support, they are complete so they can support swap. To be added:

    A namespace level swap and a specialization of std::swap<> must be provided to exchange the values of two valueboxes in an efficient matter.

  • Reported: CPP11 1.1 — Wed, 26 Feb 2014 05:00 GMT
  • Disposition: Closed; No Change — CPP11 1.2
  • Disposition Summary:

    Valueboxes should have swap support

    The issue proposed the support of swap for valueboxes but valueboxes are valuetypes which are reference types which already have swap support, also the boxed type has swap support. It doesn't add any value to define swap support for valueboxes because that can't be used at all, it is the valuetype reference and the boxed type that can be swapped and they have already swap support

  • Updated: Wed, 8 Jul 2015 11:43 GMT

provide unique class name as mapping of PortableServer::Servant

  • Key: ITCR-8
  • Legacy Issue Number: 19035
  • Status: closed  
  • Source: langensoft.com ( T. Langen)
  • Summary:

    Both Servant and ServantBase for the same purpose are used in the declaration of the mapping of PortableServer::Servant.

    Throughout this chapter Servant should be used unambiguously.

  • Reported: CPP11 1.1 — Mon, 28 Oct 2013 04:00 GMT
  • Disposition: Duplicate or Merged — CPP11 1.2
  • Disposition Summary:

    Provide correct mapping for Servant

    Both Servant and ServantBase are used in 6.26.2, this should be Servant, but that has already been resolved as part of ITCR-7

  • Updated: Wed, 8 Jul 2015 11:43 GMT

Constructor declarations in Servant code are wrong

  • Key: ITCR-7
  • Legacy Issue Number: 18850
  • Status: closed  
  • Source: Remedy IT ( Marcel Smit)
  • Summary:

    The code on page 42 has a class named 'Servant' but the constructors in this piece of code are declared as 'ServantBase'. Also the =-operators are referring to 'ServantBase' instead of 'Servant'.

    The text that follows this piece of code also talks about 'ServantBase' (in bold) instead of 'Servant'

  • Reported: CPP11 1.1 — Fri, 2 Aug 2013 04:00 GMT
  • Disposition: Resolved — CPP11 1.2
  • Disposition Summary:

    Correct constructor declarations of Servant

    ServantBase is a left over of the old IDL to C++ specification, in IDL to C++11 we only should use Servant

  • Updated: Wed, 8 Jul 2015 11:43 GMT

Destructors of strong reference types should be public

  • Key: ITCR-6
  • Legacy Issue Number: 18849
  • Status: closed  
  • Source: Remedy IT ( Marcel Smit)
  • Summary:

    The spec dictates that the destructor of a strong reference type should be protected. Implementing this will lead to compile errors. Seems that this is a left over from the beta 1 spec.

  • Reported: CPP11 1.1 — Fri, 2 Aug 2013 04:00 GMT
  • Disposition: Resolved — CPP11 1.2
  • Disposition Summary:

    Destructor of reference types should be public

    Reference types just have a regular destructor, not protected, else they can't be put on the stack.

  • Updated: Wed, 8 Jul 2015 11:43 GMT

Mention move constructor with abstract

  • Key: ITCR-17
  • Legacy Issue Number: 19580
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    for 6.19.1 to the bullet list should be added

    a protected move constructor

  • Reported: CPP11 1.1 — Fri, 15 Aug 2014 04:00 GMT
  • Disposition: Resolved — CPP11 1.2
  • Disposition Summary:

    Correct constructors of AbstractBase

    As proposed by the submitter the move constructor should be mentioned, but also the copy/move assignment operators should be mentioned. The val argument name should be removed because it doesn't add any value

  • Updated: Wed, 8 Jul 2015 11:43 GMT

usage of OBV trait should be improved

  • Key: ITCR-16
  • Legacy Issue Number: 19577
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The specicification currently lists:

    The application developer then overrides the pure virtual functions corresponding to valuetype operations in a concrete class derived directly or indirectly from the OBV
    trait.

    It is not precise enough to juset say OBV traits, it should say

    The application developer then overrides the pure virtual functions corresponding to valuetype operations in a concrete class derived directly or indirectly from the IDL::traits<>::obv_type
    trait.

  • Reported: CPP11 1.1 — Wed, 13 Aug 2014 04:00 GMT
  • Disposition: Resolved — CPP11 1.2
  • Disposition Summary:

    Correct usage of OBV trait

    The concept of a OBV class is coming from the IDL to C++ language mapping, IDL to C++11 should use the concept of the obv_type trait

  • Updated: Wed, 8 Jul 2015 11:43 GMT

Add missing default initialization for valuetypes

  • Key: ITCR-10
  • Legacy Issue Number: 19207
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    In 6.18.2 Constructors, Assignment Operators, and Destructors the default constructor of the OBV classes is mentioned. This lacks a description that it should initialize members, proposal is to add to 6.18.2, OBV part, after the first sentence add:

    The default constructor initializes object
    reference members to appropriately-typed nil object references, basic datatypes to their default value as listed in
    Table 6.2, and enums to their first value. All other members are initialized using their default constructors.

  • Reported: CPP11 1.1 — Fri, 7 Feb 2014 05:00 GMT
  • Disposition: Resolved — CPP11 1.2
  • Disposition Summary:

    Add missing behavior of the default constructor

    As suggested by the submitter the behavior of the default constructor for the OBV classes should be mentioned

  • Updated: Wed, 8 Jul 2015 11:43 GMT

wrong return type for Foo::some_function()

  • Key: ITCR-9
  • Legacy Issue Number: 19036
  • Status: closed  
  • Source: langensoft.com ( T. Langen)
  • Summary:

    The return type should be

    IDL::traits<Test::Hello>::ref_type

    instead of

    CORBA::servant_traits<Test::Hello>::ref_type

  • Reported: CPP11 1.1 — Mon, 28 Oct 2013 04:00 GMT
  • Disposition: Resolved — CPP11 1.2
  • Disposition Summary:

    Correct return type of example method

    In the example code as part of section 6.23.3 the incorrect return type is given. The correction as suggested by the submitter is the correct one

  • Updated: Wed, 8 Jul 2015 11:43 GMT

Question on unions default member

  • Key: ITCR-5
  • Legacy Issue Number: 18832
  • Status: closed  
  • Source: THALES ( Nawel Hamouche)
  • Summary:

    In the section 6.14.2 on union mapping, it says :
    "If there is a default case specified, the union is initialized to this default case. In case the union has an implicit default member it is initialized to that case. In all other cases it is initialized as empty."

    I don't get the meaning of "empty" and it doesn't seem to be defined. For example, if we have a union with a boolean discriminator which defines the two cases true and false, what happens if we read one of the fields or if we call _d (with or without parameter)? Should they all throw BAD_PARAM?

  • Reported: CPP11 1.1 — Thu, 25 Jul 2013 04:00 GMT
  • Disposition: Resolved — CPP11 1.2
  • Disposition Summary:

    Improve description of union

    After some prototyping and looking at the normal C+11 unions we propose to initialize the union in all other cases to the first discriminant in IDL, this is matching C+11 unions

  • Updated: Wed, 8 Jul 2015 11:43 GMT

Code fragment should use skel class

  • Key: ITCR-4
  • Legacy Issue Number: 18762
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:



    The code snippet for the _this method should be using the A_skel class which is derived from PortableServer::ServantBase, not the impl class

  • Reported: CPP11 1.0 — Fri, 7 Jun 2013 04:00 GMT
  • Disposition: Closed; No Change — CPP11 1.2
  • Disposition Summary:

    Code fragment should use skel class

    After carefully reviewing the specification and comparing it with our implementation we came to the conclusion that this issue is not correct. The specification is correct and nothing has to be changed in this chapter.

  • Updated: Wed, 8 Jul 2015 11:43 GMT

Move constructor of ValueBase incorrect

  • Key: ITCR-15
  • Legacy Issue Number: 19576
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The listed move constructor of ValueBase is incorrect, it should be

    ValueBase(ValueBase&&);

  • Reported: CPP11 1.1 — Wed, 13 Aug 2014 04:00 GMT
  • Disposition: Resolved — CPP11 1.2
  • Disposition Summary:

    Correct move constructor of ValueBase

    Proposal is to accept the changed as made by submitter

  • Updated: Wed, 8 Jul 2015 11:43 GMT

Missing move assignment operator in class ColorValue

  • Key: ITCR-14
  • Legacy Issue Number: 19575
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The class ColorValue as example is missing the move assignment operator which should be:

    ColorValue(& operator= (ColorValue(&&)

  • Reported: CPP11 1.1 — Wed, 13 Aug 2014 04:00 GMT
  • Disposition: Resolved — CPP11 1.2
  • Disposition Summary:

    Correct provided signature for valuebox types

    Triggered by this issue we addressed the incorrectly provided signature for valuebox types. Also the argument name "val" got removed because it doesn't add any value and we don't want to propose a specific name (which could clash when the user for example defines a valuebox of type val)

  • Updated: Wed, 8 Jul 2015 11:43 GMT

fixed member types use incorrect type

  • Key: ITCR-19
  • Legacy Issue Number: 19582
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    In table 6.11 digits/scale are described, they should use uint16_t instead of uint32_t, see the above template, there also uint16_t is used

  • Reported: CPP11 1.1 — Mon, 18 Aug 2014 04:00 GMT
  • Disposition: Resolved — CPP11 1.2
  • Disposition Summary:

    Replace uint32_t with uint16_t as proposed

    Proposal is to replace uint32_t with uint16_t as proposed, the digits and scale are both uint16_t

  • Updated: Wed, 8 Jul 2015 11:43 GMT

Destructor should just be virtual

  • Key: ITCR-18
  • Legacy Issue Number: 19581
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    for 6.19.1 to the bullet list mentions

    a protected pure virtual destructor

    This should be

    a protected virtual destructor

    it is not pure, see the example later on

  • Reported: CPP11 1.1 — Fri, 15 Aug 2014 04:00 GMT
  • Disposition: Resolved — CPP11 1.2
  • Disposition Summary:

    Make destructor just virtual

    Proposal is to make the destructor of abstract base "protected virtual" as proposed by the submitter

  • Updated: Wed, 8 Jul 2015 11:43 GMT

IDL2C++11 issue : CORBA dependency of the C++11 mapping

  • Key: ITCR-2
  • Legacy Issue Number: 18533
  • Status: closed  
  • Source: THALES ( Nawel Hamouche)
  • Summary:

    A big effort have been done to remove CORBA dependency from the IDL2C++11 mapping, but it still specifies a CORBA semantic to the IDL
    interfaces and user exceptions. In 6.6.4, it is said "Conceptually, the Object class in the CORBA module is the base interface type for all objects;" this assertion breaks all that efforts. I think the semantic of IDL interfaces should be abstracted by defining a middleware-independent Object type as the super type of all IDL interfaces, it could be IDL::Object. Likewise, CORBA::UserException and CORBA::SystemException could be abstracted by defining IDL::UserExeption and IDL::SystemException.
    Looking to the IDL3.5 specification, it is true that this specification is still tied to CORBA, but special care has been done to separate between the syntactical construct and its semantic. For instance, it is said 'See the CORBA 3.2 specfication Section 10.2 “Semantics of Abstract Interfaces” for CORBA implementation semantics associated with abstract interfaces.'. It means that there could be other semantics than CORBA.
    I would suggest the following changes in the IDL2CPP11 specification :

    • To introduce IDL::Object, IDL::LocalObject, IDL::UserExeption and IDL::SystemException.
    • To not consider an IDL interface as a CORBA Object and rephrase section 6.6.4 accordingly.
    • To not consider a user exception as a CORBA exeption and rephrase section 6.19 accordingly.
    • To group all CORBA-dependent mappings and APIs in one section "CORBA mapping". This section would include :
      6.16 Mapping for the Any Type
      6.17 Mapping for Valuetypes
      6.18.1 Abstract Interface Base
      6.21 TypeCode
      6.22 ORB
      6.23 Object
      6.24 LocalObject
      ... until 6.28
  • Reported: CPP11 1.1 — Thu, 7 Mar 2013 05:00 GMT
  • Disposition: Deferred — CPP11 1.2
  • Disposition Summary:

    Defer to future RTF

    The IDLC+11 language mapping explicitly refers to CORBA v3.2 because there is no clean IDL specification yet. There should first be a clean IDL4 specification that is completely middleware agnostic and which gives generic guidelines for language mappings how to target specific middleware technologies like CORBA. After that someone has to implement this and see if there are no unforeseen issues, when that all has been done we can update the IDL2C+11 specification accordingly

  • Updated: Wed, 8 Jul 2015 11:43 GMT

Make mapping of sequences more flexible

  • Key: ITCR-13
  • Legacy Issue Number: 19499
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    In 6.12 we define:

    An unbounded sequence is mapped to a C++ std::vector.

    For example a sequence of octets is now not optimal, in order for implementations to optimize sequences but users not to harm we propose to change this definition to

    An unbounded sequence is mapped to a type delivering C++ std::vector semantics.

  • Reported: CPP11 1.1 — Tue, 1 Jul 2014 04:00 GMT
  • Disposition: Deferred — CPP11 1.2
  • Disposition Summary:

    Defer to future RTF

    Deferring to RTF because we haven't been able to prototype this in order to validate that there are no unforeseen problems.

  • Updated: Wed, 8 Jul 2015 11:43 GMT

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

Reduce dependency on CORBA

  • Key: CPP1111-25
  • Legacy Issue Number: 17534
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    This new language mapping has CORBA in several places. Part of it are really dependent on CORBA, but not all places. In order to make it more generable usable the spec has to be updated to reduce the dependency on CORBA by

    • Rename all CORBA::foo_traits<> to IDL::traits<>
    • Move CORBA::Fixed to IDL::Fixed
  • Reported: CPP11 1.0 — Wed, 1 Aug 2012 04:00 GMT
  • Disposition: Resolved — CPP11 1.1
  • Disposition Summary:

    As proposed by the issue we are removing the CORBA::foo_traits<> and use the generic new IDL::traits<>. This makes the client code independent on CORBA. We do keep the CORBA::make_reference to create a CORBA reference, CORBA::servant_traits<> for CORBA servant, and CORBA::Any

  • Updated: Fri, 6 Mar 2015 23:16 GMT

Typedefs for struct members?

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

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

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

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

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

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

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

    // IDL
    struct Foo

    { string s; }

    ;

    // C++

    namespace CORBA {
    // ...
    class string_mgr

    { /* ... */ }

    ; // Mapping-internal class

    typedef string_mgr string_member; // New standard name
    };

    struct Foo

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

    ;

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

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

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

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

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

    rejected

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

Deprecated Ref identifier

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

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

    Proposal:

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

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

    see below

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

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

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

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

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

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

    Proposal
    ========

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

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

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

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

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

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

    see below

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

There is an incorrect page reference

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

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

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

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

    see below

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

Remnant of read-only return values and out params

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

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

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

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

    I would suggest to modify this sentence to read:

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

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

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

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

    see below

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

Backward compatibility with C

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

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

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

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

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

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

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

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

Non-exception neutral code in C++ mapping.

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

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

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

    ~ServantBase_var ()

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

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

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

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

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

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

    The implementation above also prevents silly mistakes like:

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

    The destructor is a little trickier:

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

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

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

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

    see below

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

Need for TIE template for skeletons for valuetypes that support

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

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

    Proposal:

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

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

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

    duplicate of issue 3328 close issue

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

_name & _rep_id pure virtual?

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

    The definition for Exception in the current spec is:

    // C++
    class Exception

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

    ;

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

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

    rejected

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

Requiring ref counting in ServantBase

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

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

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

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

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

    1.3.1:

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

    1.3.6:

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

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

    Benefits of Proposed Resolution:

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

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

    Existing user code will still compile.

    Resolution:
    Revised Text:

    Replace the text in section 1.36.1 beginning with the sentence:

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

    and section 1.36.2 in its entirety with:

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

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

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

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

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

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

    ;

    }

    1.36.2 Servant No Reference Counting Mix-In

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

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

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

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

    see below

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

CORBA::Fixed needs a to_string() conversion function

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

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

    namespace CORBA {
    class Fixed

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

    ;
    }

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

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

    No Data Available

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

Another issue with String_var

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

    Why is it that String_var contains the following?

    operator char *();

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

    It seems that this operator is redundant?

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

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

    Remove operator char*() from class String_var.

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

Missing conversion operator on String_var

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

    Page 1-153, section 1.41.2:

    String_var has:

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

    What is missing here is:

    operator char*&();

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

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

    Add operator char*&() to class String_var.

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

Any extraction widening to ValueBase

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

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

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

    duplicate of issue 3092...closed

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

Null assignment to String_var?

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

    page 1-23 says:

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

    So, I can't explicitly initialize with null:

    T_var tv = 0;

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

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

    T_var tv = ...;
    tv = 0;

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

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

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

    see below

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

_name and _rep_id

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

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

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

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

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

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

    see below

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

Do valuetype POA servants get tie templates?

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

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

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

    see below

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

Problem with OBV_ valuetype class constructor

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

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

    // IDL
    valuetype A

    { octet o1; }

    ;

    valuetype B : A

    { octet o2; }

    ;

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

    // C++
    class OBV_B

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

    ;

    Proposal:

    Change the second paragraph of 1.17.2 to read:

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

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

    see below

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

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

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

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

    Proposal:

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

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

    No Data Available

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

C++ Value Type issue (02)

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

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

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

    see below

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

Obsolete text in 1.40.3

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

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

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

    see below

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

Valuebox for object reference underspecified

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

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

    Proposal:

    Add the following paragraph just before the example in 1.17.7.2:

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

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

    see below

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

C++ valuetype issue (01)

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

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

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

    see below

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

Valuetype code typo in CORBA 2.3 C++ mapping

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

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

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

    fixed editorially...issue closed

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

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

Remove user defined literal support

  • Key: CPP1111-24
  • Legacy Issue Number: 18660
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The fixed mapping uses operator"" and _fixed as user defined literal. This doesn't work with a C++ template, only with a class, so the usage of user defined literals should be removed

  • Reported: CPP11 1.0 — Fri, 12 Apr 2013 04:00 GMT
  • Disposition: Resolved — CPP11 1.1
  • Disposition Summary:

    The usage of operator”” and _fixed will be removed from the specification

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

Add namespace level swap

  • Key: CPP1111-23
  • Legacy Issue Number: 18656
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    Everywhere where a specialization of std::swap is mentioned also mention the need for a namespace level swap

  • Reported: CPP11 1.0 — Fri, 12 Apr 2013 04:00 GMT
  • Disposition: Resolved — CPP11 1.1
  • Disposition Summary:

    Accepting this issue as proposed

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

Small typos in servant reference section

  • Key: CPP1111-20
  • Legacy Issue Number: 18536
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    Two small typos in sectin 6.25.3:
    aks CORBA::weak_servant_reference<>
    to
    aka CORBA::weak_servant_reference<>

    Than
    Foo some_function()
    to
    Foo::some_function()

  • Reported: CPP11 1.0 — Fri, 8 Mar 2013 05:00 GMT
  • Disposition: Resolved — CPP11 1.1
  • Disposition Summary:

    Change text as proposed

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

Replace all _downcase/downcase with narrow

  • Key: CPP1111-19
  • Legacy Issue Number: 18527
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    As done for the interfaces already, we propose to remove _downcase/_narrow for abstract/valuetype and only support IDL::traits<>::narrow. In the spec this has to be updated in text and code.

  • Reported: CPP11 1.0 — Tue, 5 Mar 2013 05:00 GMT
  • Disposition: Resolved — CPP11 1.1
  • Disposition Summary:

    Accepting this issue as proposed

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

Relax constructor argument rules

  • Key: CPP1111-22
  • Legacy Issue Number: 18655
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    Currently the std::array doesn't have an efficient move constructor, passing an array by value to the constructor of a valuetype/struct isn't efficient. Instead of adding an exception to the spec we propose to relax the spec so that it just mentions that the constructor must be there, but not that arguments have to be passed by value, that is up to the implementor to decide

  • Reported: CPP11 1.0 — Fri, 12 Apr 2013 04:00 GMT
  • Disposition: Resolved — CPP11 1.1
  • Disposition Summary:

    We remove the restriction that the arguments have to be passed by value to the
    constructor of a structured type. This is a way implementations can deliver optimizations
    if needed. This change will not impact any user code in terms of portability

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

Remove final for structured types

  • Key: CPP1111-21
  • Legacy Issue Number: 18578
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The mapping defines the mapping of IDL struct/union to a final class. The work "final" should be removed from the IDL to C++11 language mapping because it will prevent the implementation of the DDSXTypes Type Extensibility.

  • Reported: CPP11 1.0 — Fri, 22 Mar 6013 04:00 GMT
  • Disposition: Resolved — CPP11 1.1
  • Disposition Summary:

    Accepting this issue as proposed

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

typo exists in section 6.21

  • Key: CPP1111-2
  • Legacy Issue Number: 18385
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The following typo error exists in section 6.21:

    Following text in spec
    ... TypeCode reference constants, <type> refer to the local name of the type ...
    should be
    ... TypeCode reference constants, <type> refers to the local name of the type ...

    Refs #2877

  • Reported: CPP11 1.0b2 — Wed, 23 Jan 2013 05:00 GMT
  • Disposition: Resolved — CPP11 1.1
  • Disposition Summary:

    The V1.0 spec doesn’t have this typo, so closing this with no change
    Disposition: Closed

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

RFP requirement on DDS-PSM-Cxx compatibility is violated

  • Key: CPP1111-1
  • Legacy Issue Number: 18149
  • Status: closed  
  • Source: ZettaScale Technology ( Angelo Corsaro)
  • Summary:

    The current mapping for struct violates the RFP requirements that mandated compatibility with the DDS-PSM-Cxx. Areas of incompatibilities include the use of the C++11 array type and the use of move operators.

  • Reported: CPP11 1.0b2 — Wed, 10 Oct 2012 04:00 GMT
  • Disposition: Resolved — CPP11 1.1
  • Disposition Summary:

    The revised submission explicitly mentioned that this requirement was not met because
    this is a C+11 language mappping, not focusing on C+03 which is the focus of the
    DDS-PSM-Cxx. Also in the mean time the DDS-PSM-Cxx has adopted the same
    mapping for arrays/enums and mentions move semantics when C++11 support is
    available. Given the fact this is a C++11 language mapping this issue has been closed
    without a change.
    Disposition: Closed, no change

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

Lack of factory reference type

  • Key: CPP1111-3
  • Legacy Issue Number: 18386
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The specification defines IDL::traits<A>::factory_type as C++ trait for getting the base C++ class for the factory. It does lack a trait for passing a reference for a certain factory around.

    To be added:
    For a valuetype A, a strong reference to its valuetype factory is known as IDL::traits<A>::factory_ref_type. The weak object reference to its valuetype factory is known as IDL::traits<A>::weak_factory_ref_type.

    Refs #2727

  • Reported: CPP11 1.0b2 — Wed, 23 Jan 2013 05:00 GMT
  • Disposition: Resolved — CPP11 1.1
  • Disposition Summary:

    Accepting this addition as proposed

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

Early detection of bound violation on bounded types

  • Key: CPP1111-14
  • Legacy Issue Number: 18453
  • Status: closed  
  • Source: Airbus Group ( Oliver Kellogg)
  • Summary:

    Addressee: IDL to C++11 1.1 RTF <idl2cpp11-rtf@omg.org>
    Nature: Enhancement
    Summary: Early detection of bound violation on bounded types

    In the IDL to C++11 Mapping v1.0 (formal/13-02-04), the sections
    6.9, 6.10, and 6.11 describe the mapping for string, wstring, and
    sequence types, respectively. These sections also address the bounded
    variant of those types:

    " Implementations must (at run time) detect attempts to pass a
    [string|wstring|sequence] value that exceeds the bound as a parameter
    across an interface. It must raise a BAD_PARAM system exception to
    signal the error. "

    In practice, the point at which such a value is passed into an interface
    method may be far away from the assignment causing a bound violation,
    which makes the error source hard to find.

    I propose doing a bound check not only at interface methods but also
    at the setter functions for struct, union, and valuetype members.

    The section quoted above could thus be extended as follows:

    " Implementations must (at run time) detect attempts to pass a
    [string|wstring|sequence] value that exceeds the bound as a parameter
    across an interface, or passed to a setter method of a struct, union,
    or valuetype. It must raise a BAD_PARAM system exception to
    signal the error. "

    Furthermore, the mapping standard does not define the bound check
    behavior for arrays and sequences of bounded types.
    IMHO the mapping standard should make explicit that the bound check
    shall be performed on each bounded-type element of an array or sequence.

    Example:

    // IDL
    typedef string<12> string12_t;
    typedef string12_t string_arr_t[2][3];
    typedef sequence<string12_t, 4> string_seq_t;
    struct struct_t

    { string_arr_t sarr; string_seq_t sseq; }

    The sarr() and sseq() setter methods generated for struct_t should
    iterate over their input parameter and perform the bound check on
    each element. Similar checks should happen in the explicit constructor
    which accepts values for each struct member.

  • Reported: CPP11 1.0 — Wed, 13 Feb 2013 05:00 GMT
  • Disposition: Resolved — CPP11 1.1
  • Disposition Summary:

    Adding the bounds check to the place where the bounded type is used leads to
    inconsistent behavior for users. After discussion we decided to map bounded types
    (string/wstring/sequence) to a distinct type and that this type could do a bounds check.
    The exact type doesn’t need to be standardized because bound types can only be used
    through a typedef in IDL and never are used directly by the programmer. Because the
    standard containers don’t have the concept of bounds enforcing a bound will be very
    hard to accomplish on all places.

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

std::ostream insertion underspecified

  • Key: CPP1111-13
  • Legacy Issue Number: 18433
  • Status: closed  
  • Source: gmail.com ( daniel.kruegler@gmail.com)
  • Summary:

    The wording in 6.29 says

    "For each IDL type (T) of type: [..] an ostream inserter with the following signature will be provided:

    // C++
    std::ostream& operator<<(std::ostream &, T);

    For all other types an ostream inserter with the following signature will be provided:

    // C++
    std::ostream& operator<<(std::ostream &, const T&);"

    1) This wording is not clear in which namespace the operator<< overload shall be provided. It could be within the global namespace or within the namespace of type T.

    The prototype implementation that I have seen provides these operators in the global namespace which makes them behave irregular:

    The reason is that overloaded operators such as these IO inserters are found by argument-dependent name-lookup. The lookup will consider all declarations that are found at the point of usage and will look in the associated namespaces of the operands to find them. Consider the following example:

    #include <iostream>
    #include <vector>
    #include <iterator>

    namespace n {
    struct A {};
    }
    std::ostream& operator<<(std::ostream& os, n::A)

    { return os; }


    int main() { std::vector<n::A> v; std::copy(v.begin(), v.end(), std::ostream_iterator<n::A>(std::cout)); }


    This program will not compile, because the involved template cannot "see" the operator<< overload. TRhis is so, because it is provided in the global namespace, but the operands are in namespace std:: and namespace n, resp. Adding overloads to namespace std is not valid, therefore the only option is to add the operator<< overload to namespace n:


    #include <iostream>
    #include <vector>
    #include <iterator>


    namespace n {
    struct A {};
    std::ostream& operator<<(std::ostream& os, n::A) { return os; }

    }

    int main()

    { std::vector<n::A> v; std::copy(v.begin(), v.end(), std::ostream_iterator<n::A>(std::cout)); }

    This works and lets the ostream operator<< of A::n behave normally.

    This example was intended to demonstrate that the provided operator<< overloads should be provided in the same namespace as the declared mapped types from the IDL (that is within the IDL module). The wording in 6.29 should be clarified in that regard.

    2) The second part of above wording,

    "For all other types an ostream inserter with the following signature will be provided:

    // C++
    std::ostream& operator<<(std::ostream &, const T&);"

    can be read to be applicable for the arithmetic IDL types (bool, short, wchar_t, char, double, uint32_t, ...) or typedefs thereof, but that surely cannot be intended, because that would result in a compiler ambiguity when user code would include such a mapping header and would attempt to print such an arithmetic type on any std::ostream, e.g.

    #include <iostream>
    #include "some_idl.h"

    int main()

    { std::cout << 12; // Error, ambiguity }

    The wording in 6.29 should make clear that no operator<< overloads shall be provided for the basic data types or for typedefs thereof.

  • Reported: CPP11 1.0 — Wed, 6 Feb 2013 05:00 GMT
  • Disposition: Resolved — CPP11 1.1
  • Disposition Summary:

    We had a detailed looked at the argument dependent lookup and what would technically
    be feasible. We also had users that wanted to define their own ostream operators and
    our spec defined methods were conflicting with that approach. Given that this feature
    was mostly focused on debugging systems, we decided to remove this section
    completely from the specification

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

Add missing implicit widening to any

  • Key: CPP1111-5
  • Legacy Issue Number: 18388
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The description for Any lacks the support for implicit widening as it was available with the C++ mapping. Proposal is to add implicit widening to section 6.16.3. The following text is proposed to be added:

    Any object reference, valuetype reference, or abstract references has to extractable as its base reference type from an Any.

    Also in the last sentence of 6.13, any as bold should be Any with a capital A

    Refs #2873

  • Reported: CPP11 1.0b2 — Wed, 23 Jan 2013 05:00 GMT
  • Disposition: Resolved — CPP11 1.1
  • Disposition Summary:

    Accepting this addition as proposed with the remark that 6.13 should be 6.17.3 and it
    talks about the Any C++ class, not the any IDL type.

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

Add support for _this on local objects

  • Key: CPP1111-4
  • Legacy Issue Number: 18387
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    With the new IDL2C+11 mapping we can't create object references with new, we have to use the CORBA::make_reference<> factory method. In a servant we can use _this to get a reference to itself, but that is not available for local objects. With the old C+ binding people could just use the C++ this to get a _ptr to a local object, but that is not possible with the C++11 binding in general.

    Proposal is to add to 6.24:

    In order to get an object reference referring to an already created local object the _this() method must be used.

    In the code part add as method

    class LocalIF

    { protected: IDL::traits<LocalIF>::ref_type _this (); }

    ;
    Refs #2804

  • Reported: CPP11 1.0b2 — Wed, 23 Jan 2013 05:00 GMT
  • Disposition: Resolved — CPP11 1.1
  • Disposition Summary:

    Accepting this addition as proposed

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

Missing specification of assignment operators of valuetypes

  • Key: CPP1111-12
  • Legacy Issue Number: 18418
  • Status: closed  
  • Source: gmail.com ( daniel.kruegler@gmail.com)
  • Summary:

    Section 6.17.2 is titled "Constructors, Assignment Operators, and Destructors" but does not say anything about assignment operators albeit the title promises to do so.

    The following examples seems to indicate that both assignment operators are supposed to be deleted. This should be spelled out.

    It also seems as if the maiing for interfaces as of 6.6 is intended to create class types with deleted copy/move assignment operators. This should also be made more clear.

  • Reported: CPP11 1.0b2 — Tue, 5 Feb 2013 05:00 GMT
  • Disposition: Resolved — CPP11 1.1
  • Disposition Summary:

    Accepting this issue as proposed

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

Meaning of (u)intN_t types unclear

  • Key: CPP1111-11
  • Legacy Issue Number: 18406
  • Status: closed  
  • Source: gmail.com ( daniel.kruegler@gmail.com)
  • Summary:

    Section 6.5 (Table 6.1) loosely describes that the OMG IDL integer types are mapped to "a basic C++11 type" denoted by

    int16_t int32_t int64_t uint16_t uint32_t uint64_t uint8_t

    It doesn't really say, what these typedefs are supposed to be. Furthermore 6.5 (Table 6.2) describes the names

    int16_t int32_t int64_t uint16_t uint32_t uint64_t uint8_t

    as "keywords from the C++11 specification (ISO/IEC 14882:011)".

    Surely there are no such keywords in C+11 (nor in C11 or C99) and never had been. What C+11 inherits from the C99 library specification are the typedefs

    std::int16_t std::int32_t std::int64_t std::uint16_t std::uint32_t
    std::uint64_t std::uint8_t

    from header <cstdint>, but those are not keywords and they are library components that belong to namespace std. I think that the specification of the basic integer type mapping (6.5) intends to refer to these typedefs from <cstdint>, but this should be made clear in 6.5.

    Also, section 6.30 should not declare them as C+11 keywords, even though these names need to be protected by a cxx prefix as described by 6.2. Presumably a better name is needed (e.g. "protected C+11 names" or some such)

  • Reported: CPP11 1.0b2 — Fri, 1 Feb 2013 05:00 GMT
  • Disposition: Resolved — CPP11 1.1
  • Disposition Summary:

    Accepting this issue as proposed

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

Fixed type mapping should provide (explicit) operator bool

  • Key: CPP1111-10
  • Legacy Issue Number: 18405
  • Status: closed  
  • Source: gmail.com ( daniel.kruegler@gmail.com)
  • Summary:

    Given the specification of the class template Fixed provides

    operator int64_t () const;
    operator long double() const;

    and

    bool operator!() const;

    This allows to test some Fixed instantiation within a boolean context as in a useful way as follows:

    typedef IDL::Fixed<5,2> F;
    F f = ...;
    if (!f)

    { ... }


    But the similar inverse form


    if (f) { ... }

    will cause an ambiguity error between the two conversion functions to int64_t and long double. User code is required to write the obfuscated form

    if (!!f)

    { ... }

    to realize the same thing. This is unfortunate and there is a simple means to solve this problem: The specification should add

    explicit operator bool() const;

    to the class template synopsis with the same semantics as negating operator!

  • Reported: CPP11 1.0b2 — Fri, 1 Feb 2013 05:00 GMT
  • Disposition: Resolved — CPP11 1.1
  • Disposition Summary:

    Accepting this issue as proposed. Also during the discussion it was proposed to add a
    namespace level to_string

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

Invalid struct initialization example

  • Key: CPP1111-9
  • Legacy Issue Number: 18404
  • Status: closed  
  • Source: gmail.com ( daniel.kruegler@gmail.com)
  • Summary:

    The example in the middle of the page starts with:

    // C++
    S s =

    {10};


    but the struct mapping (6.13.1 p.23) clearly says that "an explicit constructor accepting values for struct each member" shall be provided. Above initialization context is a copy-initialization context and would require a non-explicit constructor. The example should be fixed to use a direct-initialization context instead, either:


    // C++
    S s{10}

    ;

    or

    // C++
    S s = S

    {10}

    ;

  • Reported: CPP11 1.0b2 — Fri, 1 Feb 2013 05:00 GMT
  • Disposition: Resolved — CPP11 1.1
  • Disposition Summary:

    Accepting this issue as proposed

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

CORBA::Exception should not use std::string type for name and repo_id

  • Key: CPP1111-15
  • Legacy Issue Number: 18463
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    CORBA::Exception should not use std::string type for name and repo_id for 2 reasons:

    1. C++ standard conformance; member types like std::string are discouraged because their constructors may throw exceptions where std::exception and derivatives are expected not to throw exceptions themselves
    2. (minor) performance; using std::string these member values are unnecessarily copied while they immutable constant strings only ever read, never mutated

    Changing the members to const char* values makes CORBA::Exception and the CORBA::SystemException classes optimal and c++ standard conformant.

    This will not be the case for CORBA::UserException derivatives as these may have IDL defined attributes having IDL defined types which may definitely throw exceptions. However the ORB should be expected to handle situations where creating user exceptions unexpectedly throws another exception.

    Refs #2958

  • Reported: CPP11 1.0 — Mon, 18 Feb 2013 05:00 GMT
  • Disposition: Resolved — CPP11 1.1
  • Disposition Summary:

    Update exception as proposed. During the discussion also it was proposed to define
    what() as noexcept which also has been done

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

Remove _narrow methods

  • Key: CPP1111-8
  • Legacy Issue Number: 18392
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    Given interface T the specification defines IDL::traits<T>::narrow as a way to narrow to T. As convenience it also defined T::_narrow. The issue is that T::_narrow is implicitly linked to IDL::traits<T>::narrow and can cause confusion and possible misuse when other traits are added for more specific traits. We propose to remove T::_narrow from the specification completely, users must just use IDL::traits<T>::narrow

  • Reported: CPP11 1.0b2 — Tue, 29 Jan 2013 05:00 GMT
  • Disposition: Resolved — CPP11 1.1
  • Disposition Summary:

    Accepting this issue as proposed

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

Extend IDL type traits for template meta programming

  • Key: CPP1111-7
  • Legacy Issue Number: 18390
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The specification defines IDL::traits<> as type trait, but uses it only for reference types.

    We propose to extend IDL::traits<> as generic type trait for IDL2C++11. This type trait delivers traits with information coming from IDL.

    For example object reference traits it can also deliver local and abstract as traits, which are booleans that indicate whether the IDL type was local or abstract.

    For sequence we can add traits indicating the type of the element and in case of bounded sequences the bound.

    The proposal is to add a new paragraph which describes the IDL type traits that are all available as part of IDL::traits<> for a specific IDL type.

    Ref #2802

  • Reported: CPP11 1.0b2 — Wed, 23 Jan 2013 05:00 GMT
  • Disposition: Resolved — CPP11 1.1
  • Disposition Summary:

    Extending the IDL::traits<> with more types for template meta programming will be useful
    for the users that would like to program C++11 templates using the IDL defined types.
    Therefor a new set of type traits will be added to the specification.

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

Use () instead of (void)

  • Key: CPP1111-17
  • Legacy Issue Number: 18500
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The specification uses in some examples like in 6.13.1 the construct "(void)" for a method with no arguments. This is old style, it should use "()"

  • Reported: CPP11 1.0 — Mon, 25 Feb 2013 05:00 GMT
  • Disposition: Resolved — CPP11 1.1
  • Disposition Summary:

    Accepting this issue as proposed

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

Minor typos

  • Key: CPP1111-16
  • Legacy Issue Number: 18498
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    2.1 refers to ISO/IEC 14822:2011 (which should be 14882:2011)

    6.30 instead refers to ISO/IEC 14882:011 (again should be 14882:2011)

    the table in 6.30 contains typos (alinas, alineof, constrexpr), names
    that aren't keywords (int32_t, ...) and misses some keywords
    (noexcept, char16_t, char32_t).

  • Reported: CPP11 1.0 — Sun, 24 Feb 2013 05:00 GMT
  • Disposition: Resolved — CPP11 1.1
  • Disposition Summary:

    Accepting this issue as proposed

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

Introduce trait for local interface base type

  • Key: CPP1111-18
  • Legacy Issue Number: 18523
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The specification uses IDL::traits<T> for everything related to interface T, but for a local interface we just use T as base class. Proposal is to use IDL::traits<T>::base_type as base type trait for the local object implementation. This makes everything related to interfaces available through IDL::traits<T>

  • Reported: CPP11 1.0 — Mon, 4 Mar 2013 05:00 GMT
  • Disposition: Resolved — CPP11 1.1
  • Disposition Summary:

    Accepting this issue as proposed

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

Font issue

  • Key: CPP1111-6
  • Legacy Issue Number: 18389
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    In section 6.25.6, in the line:

    This guarantees that the POA skeleton class inherits only one version of each operation, and also allows optional
    inheritance of implementations. In this example, the implementation of interface B reuses the implementation of interface
    A:

    The font of A should also be IDL type just as B

  • Reported: CPP11 1.0b2 — Wed, 23 Jan 2013 05:00 GMT
  • Disposition: Resolved — CPP11 1.1
  • Disposition Summary:

    Accepting this addition as proposed

  • Updated: Fri, 6 Mar 2015 20:58 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