C++ Language Mapping Avatar
  1. OMG Specification

C++ Language Mapping — Closed Issues

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

Issues Summary

Key Issue Reported Fixed Disposition Status
CPP1117-8 Incorrect constructor referenced in Fixed description CPP11 1.6b1 CPP11 1.7 Resolved closed
CPP1117-9 Typo CPP11 1.6b1 CPP11 1.7 Resolved closed
CPP1117-13 Missing annotation mapping CPP11 1.6b1 CPP11 1.7 Resolved closed
CPP1117-7 Missing description related to union member modifier CPP11 1.6b1 CPP11 1.7 Resolved closed
CPP1117-11 Change struct VariableExt constructor CPP11 1.6b1 CPP11 1.7 Resolved closed
CPP1117-10 Improve bitmask mapping CPP11 1.6b1 CPP11 1.7 Deferred closed
CPP1117-14 bit_bound CPP11 1.6b1 CPP11 1.7 Resolved closed
CPP1117-12 Add bit_bound/underlying_type for enum traits CPP11 1.6b1 CPP11 1.7 Duplicate or Merged closed
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
ZIOP-79 1. Should a session component have a way to save and restore its private st CPP 1.1 ZIOP 1.0 Resolved closed
ZIOP-76 Implementation of extended CCM features CPP 1.1 ZIOP 1.0 Resolved closed
ZIOP-75 CCM specification terms CPP 1.1 ZIOP 1.0 Resolved closed
ZIOP-74 Document OMG ptc/99-10-04 p.615-87 CPP 1.1 ZIOP 1.0 Resolved closed
ZIOP-73 Federation of HomeFinders? CPP 1.1 ZIOP 1.0 Resolved closed
ZIOP-72 Registering homes outside of the container CPP 1.1 ZIOP 1.0 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
CORBA26-82 Use of undefined "id" attribute CPP 1.1 CORBA 2.6.1 Resolved closed
CORBA26-32 operation get_implementation() referenced but not declared CPP 1.1 CORBA 2.6.1 Resolved closed
CORBA26-31 Pbl: Improper mapping rule from IDL3 to IDL2 when dealing with events. CPP 1.1 CORBA 2.6.1 Resolved closed
CORBA26-30 Issue on Assemblies and descriptors CPP 1.1 CORBA 2.6.1 Resolved closed
CORBA26-33 What about valuetype factories? CPP 1.1 CORBA 2.6.1 Resolved closed
CORBA26-23 Bridge Interoperability of the Java mapping with the EJB-to-CCM mapping CPP 1.1 CORBA 2.6.1 Resolved closed
CORBA26-22 CCM issue chapter 69 ptc/99-10-04 CPP 1.1 CORBA 2.6.1 Resolved closed
CORBA26-21 Document orbos/99-08-13, lines 1-6, contradicts with orbos/99-07-01 CPP 1.1 CORBA 2.6.1 Resolved closed
CORBA26-20 EJB/CCM mappings for the IR CPP 1.1 CORBA 2.6.1 Resolved closed
CORBA26-19 IFR backward compatibility broken CPP 1.1 CORBA 2.6.1 Resolved closed
CORBA26-18 Missing Rights Combinator in Security deployment descriptor CPP 1.1 CORBA 2.6.1 Resolved closed
CORBA26-13 Purpose of "name" element CPP 1.1 CORBA 2.6.1 Resolved closed
CORBA26-29 Issue On the use of typed home (or CCMHome subtypes) CPP 1.1 CORBA 2.6.1 Resolved closed
CORBA26-28 Where is HomeExecutorBase interface defined? CPP 1.1 CORBA 2.6.1 Resolved closed
CORBA26-27 In example p.615-86 CPP 1.1 CORBA 2.6.1 Resolved closed
CORBA26-26 p.615-85 ToonTownImpl CPP 1.1 CORBA 2.6.1 Resolved closed
CORBA26-25 Why does not CCMHome include the operation create_component() ? CPP 1.1 CORBA 2.6.1 Resolved closed
CORBA26-24 operation CPP 1.1 CORBA 2.6.1 Resolved closed
CORBA26-15 PACKAGING AND DEPLOYMENT METAMODEL CPP 1.1 CORBA 2.6.1 Resolved closed
CORBA26-14 atribute not part of definition CPP 1.1 CORBA 2.6.1 Resolved closed
CORBA26-17 Components: readonly_attr_declarator slightly ambiguous CPP 1.1 CORBA 2.6.1 Resolved closed
CORBA26-16 Components: Relationship of CIDL and PSDL unclear CPP 1.1 CORBA 2.6.1 Resolved closed
CORBA3-99 Sending codeset context more than once? CPP 1.1 CORBA 3.0.2 Resolved closed
CORBA3-98 Getting reply svc ctxts from PersistentRequests CPP 1.0 CORBA 3.0.2 Resolved closed
CORBA21-79 OMG C++ Mapping: Implicit Conversion Operators CPP 1.0b1 CORBA 2.1 Resolved closed
CORBA21-78 Persistent Any values CPP 1.0b1 CORBA 2.1 Resolved closed
CORBA21-77 DII and DSI are useless with current Any CPP 1.0b1 CORBA 2.1 Resolved closed
CORBA21-76 iterating over Any primitives CPP 1.0b1 CORBA 2.1 Resolved closed
CORBA21-75 decompose Any into constituent primitives CPP 1.0b1 CORBA 2.1 Resolved closed
CORBA21-69 Rethrowing exceptions CPP 1.0b1 CORBA 2.1 Resolved closed
CORBA21-72 Return value of operator[] for array var CPP 1.0b1 CORBA 2.1 Resolved closed
CORBA21-71 Taking T out of T_var CPP 1.0b1 CORBA 2.1 Resolved closed
CORBA21-70 Freeing inaccessible storage for T_var as out parameter CPP 1.0b1 CORBA 2.1 Resolved closed
CORBA21-74 RTTI vs. _narrow for exceptions CPP 1.0b1 CORBA 2.1 Resolved closed
CORBA21-73 Implementation of parameter passing for T_var types CPP 1.0b1 CORBA 2.1 Resolved closed
CORBA3-11 Detail lacking in when request interceptors are called CPP 1.1 CORBA 3.0.2 Resolved closed
CORBA3-10 How correlate requests and replies when using pollable sets? CPP 1.1 CORBA 3.0.2 Resolved closed
CORBA3-18 no way to register value factory from ORB initializer CPP 1.1 CORBA 3.0.2 Resolved closed
CORBA3-17 ORB accessor on POA? CPP 1.1 CORBA 3.0.2 Resolved closed
CORBA3-16 RoutingPolicy issue CPP 1.1 CORBA 3.0.2 Resolved closed
CORBA3-19 Missing minor codes in Messaging Chapter CPP 1.1 CORBA 3.0.2 Resolved closed
CORBA3-15 Portable Interceptors / register_initial_reference() CPP 1.1 CORBA 3.0.2 Resolved closed
CORBA3-14 Policy Management in Portable Interceptors CPP 1.1 CORBA 3.0.2 Resolved closed
CORBA3-9 ORBInitInfo needs the ORB CPP 1.1 CORBA 3.0.2 Resolved closed
CORBA3-8 PI needs the ORB to be available in IDL CPP 1.1 CORBA 3.0.2 Resolved closed
CORBA3-7 Question about routing policies CPP 1.1 CORBA 3.0.2 Resolved closed
CORBA3-6 Portable Interceptors: object_to_string, string_to_object CPP 1.1 CORBA 3.0.2 Resolved closed
CORBA3-13 Overriding POA policies CPP 1.1 CORBA 3.0.3 Resolved closed
CORBA3-12 Portable Interceptors: 9.2.3 text describing `Arguments' CPP 1.1 CORBA 3.0.2 Resolved closed
CORBA24-150 Validity of object references CPP 1.1 CORBA 2.4 Resolved closed
CORBA24-149 An ORB should not accept an IOR with no usable profiles CPP 1.1 CORBA 2.4 Resolved closed
CORBA24-148 Should an ORB be allowed to drop non-standard profiles CPP 1.1 CORBA 2.4 Resolved closed
CORBA24-163 selected_profile_index origin CPP 1.1 CORBA 2.4.2 Resolved closed
CORBA24-162 Absence of Wide Character Code Set CPP 1.1 CORBA 2.4.2 Resolved closed
CORBA24-161 ORB throwing exception if it finds unknown service context CPP 1.1 CORBA 2.4 Resolved closed
CORBA24-160 Wrong minor code specified in Chapter 13 CPP 1.1 CORBA 2.4 Resolved closed
CORBA24-152 Preserving unencapsulated information CPP 1.1 CORBA 2.4 Resolved closed
CORBA24-151 Indirection for value types CPP 1.1 CORBA 2.4 Resolved closed
CORBA24-147 chunked value encoding: CPP 1.1 CORBA 2.4 Resolved closed
CORBA24-146 CORBA 2.3.1 missing text describing the response_expected field CPP 1.1 CORBA 2.4 Resolved closed
CORBA24-145 Supporting TAG_MULTIPLE_COMPONENTS CPP 1.1 CORBA 2.4 Resolved closed
CORBA24-157 GIOP version and CloseConnection CPP 1.1 CORBA 2.4 Resolved closed
CORBA24-156 Valuetype in anys. Unmarshaling problem? CPP 1.1 CORBA 2.4.2 Resolved closed
CORBA24-153 Transferring Java exception reason string across the wire CPP 1.1 CORBA 2.4 Resolved closed
CORBA24-159 Nesting depth in valuetype end tags CPP 1.1 CORBA 2.4 Resolved closed
CORBA24-158 Valuetype encoding grammar in 15.3.4.7 is wrong CPP 1.1 CORBA 2.4 Resolved closed
CORBA24-155 Marshaling fixed-point decimal types CPP 1.1 CORBA 2.4 Resolved closed
CORBA24-154 IIOP 1.2 Early Reply message in presence of fragmented Request CPP 1.1 CORBA 2.4 Resolved closed
CORBA24-132 Use of the type ComponentHome CPP 1.1 CORBA 2.4.2 Resolved closed
CORBA24-131 USING Components::Enumeration CPP 1.1 CORBA 2.4.2 Resolved closed
CORBA24-130 destroy() for local objects CPP 1.1 CORBA 2.4 Resolved closed
CORBA24-129 New IDL keywords CPP 1.1 CORBA 2.4.2 Resolved closed
CORBA24-128 Implementation of get_component CPP 1.1 CORBA 2.4.2 Resolved closed
CORBA24-127 CORBA IR METAMODEL CPP 1.1 CORBA 2.4.2 Resolved closed
CORBA24-126 Is the ccm_home method shown in Table 8-1 a typo? CPP 1.1 CORBA 2.4.2 Resolved closed
CORBA24-125 How is CCMHome::get_home_def mapped to EJB operations? CPP 1.1 CORBA 2.4.2 Resolved closed
CORBA24-124 What's the return type of CCM mappings of EJB finder and creator methods? CPP 1.1 CORBA 2.4.2 Resolved closed
CORBA24-123 Do EJB-mapped attributes go to the ComponentDefault interface? CPP 1.1 CORBA 2.4.2 Resolved closed
CORBA24-122 CCM Issue: Is CCMObject::remove intended to be available to the CCM client? CPP 1.1 CORBA 2.4.2 Resolved closed
CORBA24-168 Small optimization for the GIOP header CPP 1.1 CORBA 2.4.2 Resolved closed
CORBA24-167 interop issue: CodeSets service context in GIOP 1.0 request CPP 1.1 CORBA 2.4.2 Resolved closed
CORBA24-166 Version and byte order changes when fragmenting messages (interop) CPP 1.1 CORBA 2.4.2 Resolved closed
CORBA24-165 Issue 2 -- resulting from UK comment UK-5: CPP 1.1 CORBA 2.4.2 Resolved closed
CORBA24-164 Issue 1 -- resulting from Japanese comment JPN-009E: CPP 1.1 CORBA 2.4.2 Resolved closed
CORBA24-170 Is padding necessary for empty Reply body? CPP 1.1 CORBA 2.4.2 Resolved closed
CORBA24-169 GIOP _get_domain_managers ambiguous CPP 1.1 CORBA 2.4.2 Resolved closed
CORBA24-121 CCM Issue: How are standard EJB exceptions mapped into the CCM View CPP 1.1 CORBA 2.4.2 Resolved closed
CORBA24-115 Policies not locality-constrained? CPP 1.0 CORBA 2.4 Resolved closed
CORBA22-107 Type ids in OBJECT_FORWARD return message CPP 1.0b1 CORBA 2.2 Resolved closed
CORBA22-111 Use of dynamic ports CPP 1.0b1 CORBA 2.2 Resolved closed
CORBA22-110 CORBA::Object::non_existent CPP 1.0b1 CORBA 2.2 Resolved closed
CORBA22-109 Correct IIOP marshalling of union TypeCodes CPP 1.0b1 CORBA 2.2 Resolved closed
CORBA22-108 LOCATION_FORWARD byte alignment CPP 1.0b1 CORBA 2.2 Resolved closed
CORBA22-137 Defintion of Any CPP 1.0b1 CORBA 2.2 Resolved closed
CORBA22-136 Any extractor signature problem CPP 1.0b1 CORBA 2.2 Resolved closed
CORBA22-135 Missing Any inserter CPP 1.0b1 CORBA 2.2 Resolved closed
CORBA22-134 IIOP object pointer resetting CPP 1.0b1 CORBA 2.2 Resolved closed
CORBA22-115 Problem with GIOP CancelRequest when fragments are used CPP 1.0b1 CORBA 2.2 Resolved closed
CORBA22-114 Transport Level Bridge CPP 1.0b1 CORBA 2.2 Resolved closed
CORBA22-113 IORs and identifying Object Keys CPP 1.0b1 CORBA 2.2 Resolved closed
CORBA22-112 Callbacks in IIOP CPP 1.0b1 CORBA 2.2 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-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-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

Incorrect constructor referenced in Fixed description

  • Key: CPP1117-8
  • Status: closed  
  • Source: Remedy IT Expertise BV ( Johnny Willemsen)
  • Summary:

    This chapter says:

    The Fixed(std::string&) constructor converts a string representation of a fixed-point literal, with an optional leading sign (+ or -) and an optional trailing ‘d’ or ‘D’, into a real fixed-point value.

    But there is no constructor that accepts a non-const std::string&, the text should say

    The Fixed(const std::string&) constructor converts a string representation of a
    fixed-point literal, with an optional leading sign (+ or -) and an optional trailing ‘d’ or ‘D’, into a real fixed-point value.

  • Reported: CPP11 1.6b1 — Tue, 10 Jan 2023 15:56 GMT
  • Disposition: Resolved — CPP11 1.7
  • Disposition Summary:

    Correct the spec text to match the source code

    Add the missing "const" as described in the issue.

  • Updated: Tue, 9 Jan 2024 19:49 GMT

Typo

  • Key: CPP1117-9
  • Status: closed  
  • Source: Remedy IT Expertise BV ( Johnny Willemsen)
  • Summary:

    Double "to to" in the first sentence:

    IDL bitset types are mapped to to C++ structs that meet the C++11 requirements for aggregate initialization.

    Should be

    IDL bitset types are mapped to C++ structs that meet the C++11 requirements for aggregate initialization.

  • Reported: CPP11 1.6b1 — Mon, 17 Jul 2023 08:54 GMT
  • Disposition: Resolved — CPP11 1.7
  • Disposition Summary:

    Fix typo

    As per issue description

  • Updated: Tue, 9 Jan 2024 19:49 GMT

Missing annotation mapping

  • Key: CPP1117-13
  • Status: closed   Implementation work Blocked
  • Source: Remedy IT Expertise BV ( Johnny Willemsen)
  • Summary:

    The spec should mention how the IDL4-mentioned annotations impact the mapping, I think the spec should list at least @value, @default_literal, @default, @range @min @max @bit_bound @external

    See IDL4 to CPP and the IDL4 spec itself

  • Reported: CPP11 1.6b1 — Fri, 4 Aug 2023 07:01 GMT
  • Disposition: Resolved — CPP11 1.7
  • Disposition Summary:

    Add mappings for some more IDL 4 Standardized Annotations

    New mappings for @value, @default_literal, @default, and @bit_bound – in each case drawing from uses in the beta IDL4-to-C++ mapping and/or XTypes.

  • Updated: Tue, 9 Jan 2024 19:49 GMT

Missing description related to union member modifier

  • Key: CPP1117-7
  • Status: closed  
  • Source: Remedy IT Expertise BV ( Johnny Willemsen)
  • Summary:

    In the specification an addition was made about the default argument when the union member has multiple legal discriminator values:

    Union members associated with the "default" label and those associated with multiple labels may have multiple legal discriminator values. For these members, the modifiers (those that return void) have a second parameter which has the discriminator's type. This parameter has a default argument. For members associated with multiple labels, the value of the default argument is the value of the case label that appears first in IDL. For members associated with the default label, the value of the default argument is an implementation-defined value that selects the member.

    There is nothing in the text that describes what happens when a discriminator value is passed which doesn't belong to the member, this is implicitly in the example code further down "u.obj(a, 2)", but this should be explicit in the text also, passing a not allowed discriminator should result in a BAD_PARAM exception

  • Reported: CPP11 1.6b1 — Tue, 10 Jan 2023 09:20 GMT
  • Disposition: Resolved — CPP11 1.7
  • Disposition Summary:

    Add description of error handling for 2-parameter union modifier functions

    To be consistent with the existing parts of the spec, make it clear that invalid parameters result in a BAD_PARAM exception.

  • Updated: Tue, 9 Jan 2024 19:49 GMT

Change struct VariableExt constructor

  • Key: CPP1117-11
  • Status: closed   Implementation work Blocked
  • Source: Remedy IT Expertise BV ( Johnny Willemsen)
  • Summary:

    Instead of `VariableExt(const Variable&, bool);` it should be `VariableExt(Variable, bool);` so that in the implementation we can use std::move, this is as all complex types are passed into the constructor of a struct

  • Reported: CPP11 1.6b1 — Wed, 2 Aug 2023 08:42 GMT
  • Disposition: Resolved — CPP11 1.7
  • Disposition Summary:

    In example code, function signature of constructors is non-normative

    In section 6.31.3 make it clear that the specific types of the constructor parameters (if they use pass by value or pass by const-reference) is up to the implementation.

  • Updated: Tue, 9 Jan 2024 19:49 GMT

Improve bitmask mapping

  • Key: CPP1117-10
  • Status: closed   Implementation work Blocked
  • Source: Remedy IT Expertise BV ( Johnny Willemsen)
  • Summary:

    The bitmask mapping is very basic, it doesn't give any type safety or more modern API. The spec should be improved, the <X>Bits type should be removed, only one type should be used. Also when there are multiple bitmasks with the same bitfield name they could result in a name clash. Maybe map to a enum class and add the operators ~,|,^,& for the enum class as inline operations to modify the enum class as a bitmask. At that moment the Bit type can be removed.

    When time permits I will make a proof of concept for TAOX11

  • Reported: CPP11 1.6b1 — Mon, 31 Jul 2023 06:55 GMT
  • Disposition: Deferred — CPP11 1.7
  • Disposition Summary:

    Defer breaking change to the bitmask mapping

    The existing mapping in IDL-to-C++11 is based on DDS XTypes where it has been in a formal standard for a number of years.
    There are certainly reasons to have a mapping that makes better use of the C++ type system, but this would come at a cost in terms of divergence from OMG precedent.

  • Updated: Tue, 9 Jan 2024 19:49 GMT

bit_bound

  • Key: CPP1117-14
  • Status: closed  
  • Source: Remedy IT Expertise BV ( Johnny Willemsen)
  • Summary:

    The spec defines the type trait bit_bound as `std::integral_constant<uint32_t, b>`, but as bit_bound is maximal of 64, this could be `std::integral_constant<uint8_t, b>`

  • Reported: CPP11 1.6b1 — Mon, 7 Aug 2023 07:29 GMT
  • Disposition: Resolved — CPP11 1.7
  • Disposition Summary:

    Update type used for bit_bound in bit mask traits

    The integral_constant template from the C++ standard library should be instantiated with uint8_t instead of uint32_t

  • Updated: Tue, 9 Jan 2024 19:49 GMT

Add bit_bound/underlying_type for enum traits

  • Key: CPP1117-12
  • Status: closed  
  • Source: Remedy IT Expertise BV ( Johnny Willemsen)
  • Summary:

    The bit_bound annotation can be applied to the enum, so the bit_bound and underlying_type traits should also be added to the enum

  • Reported: CPP11 1.6b1 — Sat, 5 Aug 2023 14:47 GMT
  • Disposition: Duplicate or Merged — CPP11 1.7
  • Disposition Summary:

    Add type traits for enums

    Including this in the resolution to CPP1117-13.

  • Updated: Tue, 9 Jan 2024 19:49 GMT

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: Leonardo S.p.A ( 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 ( Mr. Oliver M. 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 ( Mr. 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 ( Mr. 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 ( Mr. Oliver M. 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 ( Mr. 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 ( Mr. 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 ( Mr. Bill Beckwith)
  • Summary:

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

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

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

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

    1.3.1:

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

    1.3.6:

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

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

    Benefits of Proposed Resolution:

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

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

    Existing user code will still compile.

    Resolution:
    Revised Text:

    Replace the text in section 1.36.1 beginning with the sentence:

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

    and section 1.36.2 in its entirety with:

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

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

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

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

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

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

    ;

    }

    1.36.2 Servant No Reference Counting Mix-In

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

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

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

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

    see below

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

CORBA::Fixed needs a to_string() conversion function

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

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

    namespace CORBA {
    class Fixed

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

    ;
    }

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

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

    No Data Available

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

Another issue with String_var

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

    Why is it that String_var contains the following?

    operator char *();

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

    It seems that this operator is redundant?

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

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

    Remove operator char*() from class String_var.

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

Missing conversion operator on String_var

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

    Page 1-153, section 1.41.2:

    String_var has:

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

    What is missing here is:

    operator char*&();

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

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

    Add operator char*&() to class String_var.

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

Any extraction widening to ValueBase

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

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

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

    duplicate of issue 3092...closed

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

Null assignment to String_var?

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

    page 1-23 says:

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

    So, I can't explicitly initialize with null:

    T_var tv = 0;

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

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

    T_var tv = ...;
    tv = 0;

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

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

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

    see below

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

_name and _rep_id

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

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

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

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

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

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

    see below

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

Do valuetype POA servants get tie templates?

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

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

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

    see below

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

Problem with OBV_ valuetype class constructor

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

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

    // IDL
    valuetype A

    { octet o1; }

    ;

    valuetype B : A

    { octet o2; }

    ;

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

    // C++
    class OBV_B

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

    ;

    Proposal:

    Change the second paragraph of 1.17.2 to read:

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

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

    see below

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

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

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

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

    Proposal:

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

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

    No Data Available

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

C++ Value Type issue (02)

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

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

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

    see below

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

Obsolete text in 1.40.3

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

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

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

    see below

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

Valuebox for object reference underspecified

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

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

    Proposal:

    Add the following paragraph just before the example in 1.17.7.2:

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

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

    see below

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

C++ valuetype issue (01)

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

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

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

    see below

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

Valuetype code typo in CORBA 2.3 C++ mapping

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

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

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

    fixed editorially...issue closed

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

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

1. Should a session component have a way to save and restore its private st

  • Key: ZIOP-79
  • Legacy Issue Number: 3212
  • Status: closed  
  • Source: Oracle ( Ed Cobb)
  • Summary:

    1. Should a session component have a way to save and restore its private state?
    Problem: The current component specification provides no way for the component programmer to explicitly save and restore its private state for session components.

  • Reported: CPP 1.1 — Wed, 12 Jan 2000 05:00 GMT
  • Disposition: Resolved — ZIOP 1.0
  • Disposition Summary:

    closed issue, no change

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

Implementation of extended CCM features

  • Key: ZIOP-76
  • Legacy Issue Number: 3873
  • Status: closed  
  • Source: Anonymous
  • Summary:

    This section indicates that the Language Mappings are to be provided as errata. I have searched high and low in the OMG web site to find these mappings and have not found a single bit of info on them. I need these mappings to accurately design and implement the extended CCM features.

  • Reported: CPP 1.1 — Tue, 19 Sep 2000 04:00 GMT
  • Disposition: Resolved — ZIOP 1.0
  • Disposition Summary:

    close no change

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

CCM specification terms

  • Key: ZIOP-75
  • Legacy Issue Number: 3652
  • Status: closed  
  • Source: Laboratoire d`Informatique Fondamentale de Lille ( Raphael Marvie)
  • Summary:

    In the first versions of the CCM specification terms such as
    ComponentBAse, ComponentHome, ... have been used. More recently these
    terms have been changed to CCMObject, CCMHome... Shouldn't all the
    interfaces of the ccm module be changed this way in order to be
    homogeneous in their naming?

    Why is there CCMContext (with CCM prefix) and SessionContext without
    CCM prefix ?

    Thus SessionComponent, EnterpriseComponent, SessionContext, ... would
    become CCMSessionObject, CCMEnterpriseObject, CCMSessionContext ...

  • Reported: CPP 1.1 — Tue, 23 May 2000 04:00 GMT
  • Disposition: Resolved — ZIOP 1.0
  • Disposition Summary:

    close, no change

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

Document OMG ptc/99-10-04 p.615-87

  • Key: ZIOP-74
  • Legacy Issue Number: 3646
  • Status: closed  
  • Source: Laboratoire d`Informatique Fondamentale de Lille ( Raphael Marvie)
  • Summary:

    2. Document OMG ptc/99-10-04 p.615-87. In the last paragraph of the
    illustrative example, it is said that: "The implementations of
    operations for navigation, executor activation, object reference
    creation and management, and other mechanical functions are either
    generated or supplied by the container."
    Don't you think this is dangerous in a multi vendor context? Let say
    a component implementation rely on the container to provide these
    operations. What will happend if this component is deployed in a
    container which considers that component implementations include
    the generated code providing these operations? (Same feeling as in
    remark 2.)

  • Reported: CPP 1.1 — Tue, 23 May 2000 04:00 GMT
  • Disposition: Resolved — ZIOP 1.0
  • Disposition Summary:

    close issue, no change

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

Federation of HomeFinders?

  • Key: ZIOP-73
  • Legacy Issue Number: 3215
  • Status: closed  
  • Source: Oracle ( Ed Cobb)
  • Summary:

    Problem: Can home finders be federated?

  • Reported: CPP 1.1 — Wed, 12 Jan 2000 05:00 GMT
  • Disposition: Resolved — ZIOP 1.0
  • Disposition Summary:

    No, HomeFinder cannot be federated. Clients can use the Naming Service instead, which is federated.

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

Registering homes outside of the container

  • Key: ZIOP-72
  • Legacy Issue Number: 3214
  • Status: closed  
  • Source: Oracle ( Ed Cobb)
  • Summary:

    Problem: The current specification does not provide an interface for registering homes that can be used outside of the container. Should it?

  • Reported: CPP 1.1 — Wed, 12 Jan 2000 05:00 GMT
  • Disposition: Resolved — ZIOP 1.0
  • Disposition Summary:

    close, no change

  • 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, PhD.)
  • 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 ( Mr. Oliver M. 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

Use of undefined "id" attribute

  • Key: CORBA26-82
  • Legacy Issue Number: 3197
  • Status: closed  
  • Source: Ericsson ( John-Luc Bakker)
  • Summary:

    I have a number of issues with the Software Package Descriptor section of
    the CCM specification (Component Spec - Volume I, orbos/99-07-01.) I have
    not found answers to issues raised below in either the components-ftf
    archive, or the issues list.

    ISSUE - The softpkg descriptor example uses an "id" attribute, which isn't
    defined in the softpkg.dtd.

    >From page 10-305, 10.2.1 A softpkg Descriptor Example, CORBA Components -
    orbos/99-07-01:

    <idl id="IDL:M1/Bank:1.0" ><link href="ftp://x/y/Bank.idl"/></idl>

    According to the softpkg.dtd, (page B-435, B.1 softpkg.dtd, CORBA Components

    • orbos/99-08-05, ) the idl element is defined as follows:

    <!ELEMENT idl
    ( link

    fileinarchive
    repository
    ) >

    The same definition can also found in section 10.2.2.14, The idl Element (,
    page 10-311, CORBA Components - orbos/99-07-01.) There are no attributes
    defined for the idl element.

  • Reported: CPP 1.1 — Mon, 10 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

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

operation get_implementation() referenced but not declared

  • Key: CORBA26-32
  • Legacy Issue Number: 3785
  • Status: closed  
  • Source: Anonymous
  • Summary:

    In chapter 69.9.1.2 Deployment Scenario on page 329 of ptc/99-10-04.pdf the
    operation get_implementation() is refered as if it belongs to the
    ComponentInstallation interface (called only "Installation"), but the
    specification of that interface lacks it.

  • Reported: CPP 1.1 — Thu, 17 Aug 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    Duplicate, close

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

Pbl: Improper mapping rule from IDL3 to IDL2 when dealing with events.

  • Key: CORBA26-31
  • Legacy Issue Number: 3746
  • Status: closed  
  • Source: Laboratoire d`Informatique Fondamentale de Lille ( Raphael Marvie)
  • Summary:

    Dealing with the following IDL3 definition, a problem arises when
    generating the IDL2 definitions (complete IDL2 mapping is enclosed at
    the end of this mail).

    module example {
    valuetype AnEvent : Components::EventBase

    { public string value; }

    ;

    component Producer

    { publishes AnEvent output; }

    ;

    component Consumer

    { consumes AnEvent input; }

    ;
    };

    According to the chapter 5 of the CCM specification, the publishes
    definition of the Producer component is mapped to the following
    definition (excerpt).

    interface Producer : Components::CCMObject

    { Components::Cookie subscribe_output(in ::example::ProducerEventConsumers::AnEventConsumer consumer) raises (Components::ExceededConnectionLimit); }

    ;

    In the mean time, the consumes definition of the Consumer component is
    mapped to the following definition.

    interface Consumer : Components::CCMObject {

    ::example::ConsumerEventConsumers::AnEventConsumer
    get_consumer_input();

    };

    We can see that two versions of the "AnEventConsumer" interface have
    been defined in two distincts modules. Thus the following Java
    lines are not correct:

    example.Producer p = ...;
    example.Consumer c = ...;

    p.subscribe_output(c.get_consumer_input());

    The Java compiler will refuse to compile the last one, producing an
    error like "BadTypeCoerce". However, in the IDL3 definitions, both
    components have been defined in order to be used together. (sic!)

    Thus, we think that the mapping for a Consumer should not be based on
    the component definitions, but on the event definition itself. It
    would then avoid multiple (incompatible) definitions of the consumers.
    This mapping could be defined in two distinct ways.

  • Reported: CPP 1.1 — Tue, 18 Jul 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

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

Issue on Assemblies and descriptors

  • Key: CORBA26-30
  • Legacy Issue Number: 3726
  • Status: closed  
  • Source: Laboratoire d`Informatique Fondamentale de Lille ( Raphael Marvie)
  • Summary:

    Looking a the <Assembly> interface, a question arises. When providing
    the assembly descriptor location, a logic description of the
    application to deploy is provided. But, how are set the pysical hosts
    to be used for the deployemnt of the logic configuration? No hooks is
    provided to the deployment tool (as there are no interfaces for the
    tool) in order to provide these information, and no operation is
    available on the assembly interface to do so. Is there an extension of
    the <Assembly> interface in order to contain this information?
    Otherwise, how could the application be deployed?

    Thinking about what should be provided, it is necessary to assign a
    logical name contained in the assembly descriptor to a physical host
    name. Maybe an extension to the assembly descriptor filled at
    deployment time is the solution? The second possible choice crossing
    my mind is an IDL structure (in fact sequence of structure) that could
    be provided to the assembly object.

  • Reported: CPP 1.1 — Mon, 26 Jun 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    rejected

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

What about valuetype factories?

  • Key: CORBA26-33
  • Legacy Issue Number: 3786
  • Status: closed  
  • Source: Laboratoire d`Informatique Fondamentale de Lille ( Raphael Marvie)
  • Summary:

    What about <i>valuetype factories</i>?

    <p>In the context of a component dealing with events, the aspect of
    <i>valuetype</i> factories has not been really mentionned in the spec,
    especially in the deploiement process.
    If I am right, dealing with <i>valuetypes</i> in a program means to
    instantiate and to register a factory for this <i>valuetype</i> to the
    ORB. In the context of the CCM, a component and its home is installed
    into a generic container which may not know the <i>valuetype</i>.
    Thus, the <i>valuetype factory</i> may have to be installed at
    deployment time. </p>
    <p> According
    to the similarity in the <i>home</i> and <i>valuetype factory</i>
    concepts, it may be a good solution to add an entry in the CORBA
    Component Descriptor OSD file to define the <i>valuetype factory</i>
    (which would have to be included in the component package) required by
    the component as well as to define a standard name scheme for their
    entry points. Here is an draft example of what it could look
    like. Relationships / dependencies between components and <i>valuetype
    factories</i> also have to be introduced.</p>

    <!--
    <softpkg>
    ...
    <implementation id="...">
    ... all the environment stuff ...
    <descriptor type="Event Factory">
    <fileinarchive>...</fileinarchive>
    </descriptor>
    <code type="DLL">
    <fileinarchive name="bank.dll" />
    <entrypoint>createEventFactory</entrypoint>
    </code>
    </implementation>
    ...
    </softpkg>
    -->

    <p><tt><softpkg>
    <br>  ...
    <br>  <implementation id="...">
    <br>    ... all the environment stuff ...
    <br>    <descriptor type="Event Factory">
    <br>      <fileinarchive>...</fileinarchive>
    <br>    </descriptor>
    <br>    <code type="DLL">
    <br>      <fileinarchive name="bank.dll" />
    <br>      <entrypoint>createEventFactory</entrypoint>
    <br>    </code>
    <br>  </implementation>
    <br>  ...
    <br></softpkg></tt></p>

    <p>The second solution could be to include the code for <i>valuetype
    factory</i> creation in the <i>home</i> implementation, which mean
    less specification: "The home has to install any valuetype factory
    required by the component." would be enough. However, this second
    approach may not be as much portable as the first one (as long as a
    <i>home</i> may be portable between containers, which IMHO should be
    possible).</p>

  • Reported: CPP 1.1 — Thu, 24 Aug 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

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

Bridge Interoperability of the Java mapping with the EJB-to-CCM mapping

  • Key: CORBA26-23
  • Legacy Issue Number: 3419
  • Status: closed  
  • Source: International Business Machines ( Mr. Ignacio Silva-Lepe)
  • Summary:

    he following sub-issues need to be addressed to make sure that CCM/EJB
    bridge implementations are interoperable. In particular, these sub-issues
    have in common that the current definition of the bridge relies on the
    Java-to-IDL mapping, which in certain cases does not match the requirements
    of the EJB-to-CCM mapping.

    Sub-issue: METHOD NAMES IN STANDARD INTERFACES

    The names for some methods defined on standard interfaces, for example
    <home-name>Implicit.find_by_primary_key or <home-name>Implicit.create,
    differ from the names that their EJB counterparts get mapped to under
    Java-to-IDL (in the example these would be
    <home-name>.findByPrimaryKey and create__keytype, respectively). When
    this happens, the translation from one form of the name to the other
    can happen at either the client or the server side of the bridge. FOR
    INTEROPERABILITY, it is necessary to eliminate this ambiguity. Choices
    for doing this include requiring the client stub to always do the
    translation or requiring the server skeleton to take into account both
    name forms.

    The actual problem we are getting hit by here is overloaded names. Methods
    like remove and create in EJBHome and user-defined EJB homes can only be
    mapped to remove_XXX and create_XXX under Java-to-IDL, yet the
    definitions of the corresponding methods in <home-name>Implicit are remove
    and create, respectively. I can understand that these implicit home names
    were defined as such because <home-name>Implicit is a standard interface
    (although the fact that its name is prefixed by <home-name> is a bit
    troubling) and, if for no other reason, because the XXX in create_XXX
    cannot be known in general. So, if we stick to the standard names, there is
    a mismatch. Notice however that I said that the mapping is done under
    Java-to-IDL. Perhaps I should not say that but the CCM spec is not clear
    about this and in fact it states that the create methods in an EJB home are
    mapped to factory names under Java-to-IDL. So we may actually be talking
    about two different issues: (1) use different mapping rules for create with
    no primary key, in which case we need to ammend the spec to this effect;
    (2) perform a translation, in which case we have an interoperability issue.

    Sub-issue: HANDLING STANDARD EXCEPTIONS

    Standard exceptions thrown by EJB methods, such as
    DuplicateKeyException, have a mapping specification to IDL (under the
    current Java-to-IDL specification) that does not match the exceptions
    that they map to under the CCM spec (in the example this would be
    DuplicateKeyValue). This requires that the bridge perform a run-time
    translation of exceptions from the Java-to-IDL mapping to the CCM
    mapping at either the client stub or the server skeleton. FOR
    INTEROPERABILITY, it is further necessary that the location of the
    translation be fixed. Early prototype implementation suggests that it
    is more advantageous for the client stub to perform the translation
    since otherwise the server skeleton would need to know what kind of
    client it is talking to: a CCM client or an EJB client. A larger issue
    that this falls under is the reconciliation of the Java-to-IDL mapping
    with the EJB-to-CCM mapping. If and when the larger issue is resolved,
    this issue would largely disappear.

    This also falls under the Java-to-IDL mismatch. Our choices seem to be: (1)
    define the standard exceptions, e.g. Components::DuplicateKeyValue, as if
    they had been mapped from Java under Java-to-IDL, (2) map the exceptions
    from Java under rules different from those on Java-to-IDL; (3) perform a
    translation. Choice (1) may be too intrusive but it could be rationalized
    with a "integration with EJB" argument. Choices (2) and (3) are similar to
    the above.

    Sub-issue: PASSING A PRIMARY KEY PARAMETER

    A number of methods defined by standard interfaces, such as remove
    defined by EJBHome, include in their signature a primary key value and
    define its type to be java.lang.Object, which under RMI-IIOP is mapped
    to CORBA::Any. Since the primary key is actually an object passed by
    value and thus mapped to an IDL value type, a run-time translation
    must be performed from the value type to Any and viceversa whenever a
    method that includes a primary key is called. FOR INTEROPERABILITY, it
    is necessary that the location of this translation be fixed. Choices
    for doing this include requiring the client stub to always do the
    translation or requiring the server skeleton to take into account both
    a value or an Any that could possibly be coming from any given
    client. In additon, if a primary key is returned it may be more
    advantageous for the client to perform this translation, since the
    server skeleton may not know what form the client is expecting.

    Here again the problem is that, under Java-to-IDL, java.lang.Object gets
    mapped to ::java::lang::Object (not CORBA::Any actually, as per the actual
    Java-to-IDL I am looking at) for methods like EJBHome.remove, whereas the
    key is expected to be passed as a value type. So the choices seem to be:
    (1) use rules other than those in Java-to-IDL for the mapping or (2)
    perform a translation.

  • Reported: CPP 1.1 — Tue, 14 Mar 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

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

CCM issue chapter 69 ptc/99-10-04

  • Key: CORBA26-22
  • Legacy Issue Number: 3412
  • Status: closed  
  • Source: Anonymous
  • Summary:

    What exactly is meant in chapter 69.7.2.3 by component archive file? It is
    not defined anywhere. Is it a software package descriptor or a software
    package? At least it is not a CORBA component descriptor as shown in the
    example in chapter 69.7.1. The text there is like:

    <componentfile id="A">
    <fileinarchive name="ca.ccd"/>
    ...

    Is the sufix ccd right?

  • Reported: CPP 1.1 — Mon, 13 Mar 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

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

Document orbos/99-08-13, lines 1-6, contradicts with orbos/99-07-01

  • Key: CORBA26-21
  • Legacy Issue Number: 3299
  • Status: closed  
  • Source: Ericsson ( John-Luc Bakker)
  • Summary:

    Document orbos/99-08-13, line 9 and further, contradicts with
    orbos/99-07-01,
    Chapter 4.4. The production rules for typePrefix and typeId contain a
    ";",
    where file orbos/99-08-13 omits them.

    Document orbos/99-08-13, lines 1-6, contradicts with orbos/99-07-01,
    Chapter 4.2. The production rules for import contain a ";",
    where file orbos/99-08-13 omits them.

  • Reported: CPP 1.1 — Mon, 7 Feb 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

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

EJB/CCM mappings for the IR

  • Key: CORBA26-20
  • Legacy Issue Number: 3260
  • Status: closed  
  • Source: Oracle ( Ed Cobb)
  • Summary:

    The mapping between EEJB metadata and the IR is missing in the
    current specification .Resolution: Define the mapping

  • Reported: CPP 1.1 — Thu, 27 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see above, rejected

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

IFR backward compatibility broken

  • Key: CORBA26-19
  • Legacy Issue Number: 3233
  • Status: closed  
  • Source: Thematix Partners LLC ( Jishnu Mukerji [X] (Inactive))
  • Summary:

    Moving existing interfaces from the CORBA module to a new IR module breaks
    backward compatibility. Hence they should be moved back to the CORBA module. The
    elements that are newly added can go into a new module, and interfaces
    corresponding to the existing ones with the same names can be placed in the new
    module, with these interfaces deriving from the existing corresponding
    interfaces in the CORBA module, thus allowing all CORBA3 IR interfaces to be
    accessed from a single module.

    This also fixes a related problem regarding separation of the TypeCode stuff,
    specifically TypeCode factory. It is broken in the current spec because certain
    types used by the typecode factory were inadvertently moved to the IR module.

  • Reported: CPP 1.1 — Tue, 18 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

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

Missing Rights Combinator in Security deployment descriptor

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

    In section 69.4.5.45, the "rights" element is mentioned, but the "rights
    combinator" elemnt is not. Given a set of "rights" it is not possible to
    determine how to cobine them without the "rights combinator" as specified in
    CORBAsec. Suggest we add a "rights cobminator" element, consistent with the
    definition of rights combinator in CORBAsec.

  • Reported: CPP 1.1 — Tue, 18 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

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

Purpose of "name" element

  • Key: CORBA26-13
  • Legacy Issue Number: 3198
  • Status: closed  
  • Source: Ericsson ( John-Luc Bakker)
  • Summary:

    ISSUE - What is the purpose of the "name" element as used in the
    "dependency" element?

    See section 10.2.2.7, The dependency Element (, page 10-308, 10.2.1 A
    softpkg Descriptor Example, CORBA Components - orbos/99-07-01.) Section
    10.2.2.20, The name Element, describes the name element as an optional
    element of the "author" element, and is meant to identify the author. So
    does the name element identify the author of the dependency, or is it used
    to identify the dependency itself?

  • Reported: CPP 1.1 — Mon, 10 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

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

Issue On the use of typed home (or CCMHome subtypes)

  • Key: CORBA26-29
  • Legacy Issue Number: 3725
  • Status: closed  
  • Source: Laboratoire d`Informatique Fondamentale de Lille ( Raphael Marvie)
  • Summary:

    When a component type is implemented, it inherits a specialized
    interface for callback functions, for example SessionComponent. In
    this context, why should home implementations be unspecialized? Using
    a specific home type, deployment could be improved when performed in a
    multi-actor context. As the cooperation between containers and homes
    is unspecified, using multi-actors components seems unreachable. One
    particular aspect is how the container <Context> interface si provided
    to the component instance. Using a well defined specialized home
    interface would solve this problem easily. Thus, avoiding the use of
    wrappers for example which are another solution, but far more complex.
    Such an interface should be defined for each component type category.

    As an example the following interface could be a basis for session
    component homes. (there must be other operations to add here, but I
    have not foudn them yet.)

    interface SessionCCMHome : CCMHome

    { // or CCMHomeKeyless void set_session_context ( in SessionContext sc ) ; }

    ;

  • Reported: CPP 1.1 — Mon, 26 Jun 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    rejected

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

Where is HomeExecutorBase interface defined?

  • Key: CORBA26-28
  • Legacy Issue Number: 3651
  • Status: closed  
  • Source: Laboratoire d`Informatique Fondamentale de Lille ( Raphael Marvie)
  • Summary:

    7. Where is HomeExecutorBase interface defined? I only saw it used in
    the packaging and deployment model. If it is a standard interface
    which is returned (how could it be non standard), shouldn't it be
    defined somewhere? (Same remark for ExecutorSegmentBase
    interfaces. It may be defined in the last Components.idl, but I did
    not find one more recent than orbos/99-08-13.)

  • Reported: CPP 1.1 — Tue, 23 May 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    See the resolution for issue 4574.

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

In example p.615-86

  • Key: CORBA26-27
  • Legacy Issue Number: 3650
  • Status: closed  
  • Source: Laboratoire d`Informatique Fondamentale de Lille ( Raphael Marvie)
  • Summary:

    6. In example p.615-86, shouldn't myToonImpl extends ToonSessionImpl
    (presented in the previous pages) instead of ToonImpl (which is not
    defined)? The same classname is used in pages 96-98, but it seems
    correct in this case.

  • Reported: CPP 1.1 — Tue, 23 May 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

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

p.615-85 ToonTownImpl

  • Key: CORBA26-26
  • Legacy Issue Number: 3649
  • Status: closed  
  • Source: Laboratoire d`Informatique Fondamentale de Lille ( Raphael Marvie)
  • Summary:

    5. Even if it is only an example, p.615-85 ToonTownImpl implements
    ExecutorSegmentBase, shouldn't it be HomeExecutorBase?

  • Reported: CPP 1.1 — Tue, 23 May 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

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

Why does not CCMHome include the operation create_component() ?

  • Key: CORBA26-25
  • Legacy Issue Number: 3648
  • Status: closed  
  • Source: Laboratoire d`Informatique Fondamentale de Lille ( Raphael Marvie)
  • Summary:

    4. Why does not CCMHome include the operation create_component() ? I
    understand that a component created by a home with keys should not
    offer this interface, however according to the exemple in the spec
    Container operation install_home() returns a CCMHome, thus how
    could a component be created in this context? Does it imply that
    you know if the home is keyless or not, thus narrowing it before
    use? Don't you find strange to have the remove operation but not a
    default create in the CCMHome interface?

  • Reported: CPP 1.1 — Tue, 23 May 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    rejected

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

operation

  • Key: CORBA26-24
  • Legacy Issue Number: 3647
  • Status: closed  
  • Source: Laboratoire d`Informatique Fondamentale de Lille ( Raphael Marvie)
  • Summary:

    3. Why isn't the operation <string get_implementation(in string iuuid)>
    defined in the interface ComponentInstallation while being used in
    ptc/99-10-04 p.69-329 item 9? (Where Installation should be
    replaced by ComponentInstallation don't you think?) Moreover, this
    operation is required for an Assembly to find the location of a
    component implementation in order to load it in a container.

  • Reported: CPP 1.1 — Tue, 23 May 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

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

PACKAGING AND DEPLOYMENT METAMODEL

  • Key: CORBA26-15
  • Legacy Issue Number: 3208
  • Status: closed  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    1) Some concepts from the CORBA metamodel (component, facet, receptacle,
    event publishing/emission/consumption) are also in P/D metamodel but the
    definitions from the CORBA metamodel are not directly reused.

    Recommendation: Analyze where reuse is appropriate and adjust the P/D
    metamodel accordingly.

    2) The P/D metamodel has the notion of files (e.g. configuration property
    files and some other files) where some metadata are stored. The hand-coded
    DTDs treat these files as types in their own right, i.e. they conceptualize
    them as files, and some of the other types point to the file types. This
    is approach is mimicked in the metamodel. However, it might not make sense
    in the metamodel because, in a repository context, you are referencing
    other information in the repository and not necessarily a file. The way
    the metamodel is now, when something references one of these files you lose
    the metadata trail. The file metaclass itself does not have structural
    features pointing to metaclasses that define the contents of the file. You
    have to go elsewhere (i.e. to the property file Package) to get that
    metadata and there is no reference to the property file Package.

    Recommendation: It might make more sense for references to the file
    metaclass to instead reference the top level element of the property file
    Package so that you can "follow the metadata trail." If someone wants to
    break out the properties metadata in a file, then the generated DTD should
    allow that, i.e. the part that needs to go into a properties file should be
    able to be self-contained without external references.

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

    rejected, See issue 4575.

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

atribute not part of definition

  • Key: CORBA26-14
  • Legacy Issue Number: 3199
  • Status: closed  
  • Source: Ericsson ( John-Luc Bakker)
  • Summary:

    ISSUE - The description of the "implementation" element explains the
    "variation" attribute, but the attribute is not part of the definition.

    >From page 10-32, CORBA Components - orbos/99-07-01: "The variation attribute
    is used to indicate a variation from a normal implementation." But the
    definition of the implementation attribute list only lists the "id"
    attribute. The variation attribute is not part of the definition as given in
    softpkg.dtd either (, page B-419, B.1 softpkg.dtd, CORBA Components -
    orbos/99-08-05.)

  • Reported: CPP 1.1 — Mon, 10 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

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

Components: readonly_attr_declarator slightly ambiguous

  • Key: CORBA26-17
  • Legacy Issue Number: 3230
  • Status: closed  
  • Source: Humboldt-Universitaet ( Martin von Loewis)
  • Summary:

    In ptc/99-10-04, the production 104

    <readonly_attr_declarator >::=
    <simple_declarator> [ <raises_expr> ]

    <simple_declarator> { "," <simple_declarator> }*

    is ambiguous, since a sole <simple_declarator> could either denote the
    first alternative (with no <raises_expr>), or the second alternative
    (with the simple-declarator-list omitted). Even though this does not
    constitute a serious problem, it is also easy to fix:

    <readonly_attr_declarator >::=
    <simple_declarator> <raises_expr>
    | <simple_declarator> { "," <simple_declarator> }

    *

  • Reported: CPP 1.1 — Mon, 17 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

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

Components: Relationship of CIDL and PSDL unclear

  • Key: CORBA26-16
  • Legacy Issue Number: 3229
  • Status: closed  
  • Source: Humboldt-Universitaet ( Martin von Loewis)
  • Summary:

    The draft component specification (ptc/99-10-04) explains that CIDL is
    a superset of IDL. This is a derivation from the specification
    voted-on in the PTC (orbos/99-07-01), which specified that CIDL is a
    superset of PSDL.

    Also, declaring CIDL not to be a superset of PSDL means that the
    <catalog_use_dcl>, <abstract_storage_home_binding> etc become
    meaningless, as they refer to entities from PSDL.

    Proposed Resolution: Declare CIDL to be a superset of PSDL.

  • Reported: CPP 1.1 — Mon, 17 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    See issue 3065.

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

Sending codeset context more than once?

  • Key: CORBA3-99
  • Legacy Issue Number: 3318
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    Question: Is it legal to send the same codeset context more than once
    on the same connection?

    The spec says:

    Codeset negotiation is not performed on a per-request basis,
    but only when a client initially connects to a server.

    These words suggest that the codeset must be sent on the first request,
    but don't say whether it's OK to send it more than once.

    I would like to have clarification, and also a loose interpretation. Here
    is why:

    A multithreaded client starts talking to a new object from
    multiple threads more or less simultaneously. If the codeset
    info must be sent only on the first request and is illegal on
    subsequent requests, we end up with rather complex locking
    logic in the connection management layer of the ORB. In effect,
    each request is no longer a stand-alone and context-free thing;
    instead, how to send a specific request now depends on what
    other threads may have done in the past.

    That's not very nice (even though it can be implemented) because
    it needlessly complicates things.

    So, I would like to change things such that it is legal to send the
    codeset context even if it was sent previously on the same connection.
    When that happens, the server should simply and silently ignore all
    but the first context (even if the subsequent contexts have different
    codeset information from earlier ones). That way, requests remain
    context-free. [ Yet again, we see a sterling demonstration that attaching
    semantics to the duration of a connection was a very bad idea, especially
    in a model that is connectionless ]

    Further, it seems pointless to send codeset info at all unless the client
    actually uses an operation that involves a wchar or wstring parameter.
    So, I think it would make sense to relax things such that the codeset
    need not be sent until the first request is made that requires sending it.

  • Reported: CPP 1.1 — Tue, 14 Mar 2000 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

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

Getting reply svc ctxts from PersistentRequests

  • Key: CORBA3-98
  • Legacy Issue Number: 2629
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: It does not appear that reply service contexts are maintained when retrieving
    polled requests from a Router. Although the Router interfaces properly
    propogate the service contexts to the the untyped reply handler representing the
    PersistentRequest, there is no way for the client to retrieve these contexts
    from the PersistentRequest::get_reply. This may make it impossible for the
    client to interpret the reply data (e.g. if the reply contained CodeSet
    contexts).

  • Reported: CPP 1.0 — Tue, 4 May 1999 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

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

OMG C++ Mapping: Implicit Conversion Operators

  • Key: CORBA21-79
  • Legacy Issue Number: 484
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: I propose that public interface of _var types, the similar "smart pointer" types used in struct fields, and "smart pointer" types returned from sequence index operators be extended. (see file)

  • Reported: CPP 1.0b1 — Thu, 30 Jan 1997 05:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    Fixed by Portability submission

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

Persistent Any values

  • Key: CORBA21-78
  • Legacy Issue Number: 480
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: It"s currently not possible for a C++ client or server to receive a parameter value of type Any, store that value in filesystem or a database and later reconstruct Any value from persistent represe

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

    Fixed by portability submission

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

DII and DSI are useless with current Any

  • Key: CORBA21-77
  • Legacy Issue Number: 479
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Cannot use DII to invoke an operation that expects or returns a complex user-defined type. Any needs to provide member functions for composing Any"s containing arbitrary user-defined values

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

    Fixed by Portability submission

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

iterating over Any primitives

  • Key: CORBA21-76
  • Legacy Issue Number: 254
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: There hsould be a way to access an unknown type inside an Any by "iterating" over the Any to examine the type in terms of the primitive types that make it up.

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

    Fixed by Portability submission

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

decompose Any into constituent primitives

  • Key: CORBA21-75
  • Legacy Issue Number: 251
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Here is an extremely simple extension to the any type to allow decomposition of values to their constituent parts: <EXAMPLE issue251>

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

    Fixed by Portability submission

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

Rethrowing exceptions

  • Key: CORBA21-69
  • Legacy Issue Number: 144
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: If all I want to do is rethrow an exception in my C++ client code, there is no convenient and compliant way. It would be useful to add extra members to allow this.

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

    Fixed by Portability submission

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

Return value of operator[] for array var

  • Key: CORBA21-72
  • Legacy Issue Number: 220
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Sec 16.12 Pg 16-27 CORBA2.o Why are we returning a Long * from operator[] rather than an LongArray_slice&?

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

    Fixed by Portability submission

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

Taking T out of T_var

  • Key: CORBA21-71
  • Legacy Issue Number: 205
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: [Sec 16.8.1 Pg 16-14 CORBA2.0 p31, Section 3.10.1 para 14: If I have T_var referring to T. How can I take ownership?How to stop it from being deallocated when T_var goes out of scope?

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

    Fixed by Portability submission

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

Freeing inaccessible storage for T_var as out parameter

  • Key: CORBA21-70
  • Legacy Issue Number: 187
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Standard requires that a conforming implementation must free the inaccessable storage associated with a parameter passed as a managed type(T_var). How to achieve it for out parameters??

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

    Fixed by Portability submission

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

RTTI vs. _narrow for exceptions

  • Key: CORBA21-74
  • Legacy Issue Number: 244
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Since RTTI is not ubiquitous, the _narrow operations for Exceptions should be defined, even when RTTI available. They are trivial to implement using RTTI.

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

    Fixed by Portability submission

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

Implementation of parameter passing for T_var types

  • Key: CORBA21-73
  • Legacy Issue Number: 239
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Implementation dependent: Implementation of parameter passing using T_var types

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

    Fixed by Portability submission

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

Detail lacking in when request interceptors are called

  • Key: CORBA3-11
  • Legacy Issue Number: 3599
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    I set out reading ptc/2000-04-05 to answer a question: how could a
    client interceptor for the OTS implement the proper behavior for the DII
    get_response or get_next_response operations that require the
    WrongTransaction to be raised if the current thread is not properly
    associated with the same transaction as the request.

    I wasn't able to answer this question authoritatively, because there is
    nothing in the Portable Interceptors Chapter that indicates the proper
    time sequencing of when the client side request interceptor operations
    are invoked in relation to the use of the DII (or the AMI_ messaging
    interfaces either.)

    By inference, it appears to me that the only way to allow an OTS client
    request interceptor to exhibit the proper semantics is for the ORB to
    not make calls to receive_

    {reply,exception,other}

    when the response is
    received from the protocol stack, but instead to make them when
    get_response or get_next_response is called by the application.

    This paragraph in 21.3.7.2:

    "Asynchronous requests are simply two separate requests. The first
    request receives no reply. The second receives a normal reply. So the
    normal (no exceptions) flow is: first request - send_request followed by
    receive_other; second request - send_request followed by receive_reply."

    is also not particularly useful, since it doesn't give any indication
    how the interceptor can distinguish the "first request" from the "second
    request".

    So, to sum up, the PI chapter needs explicit information showing the
    time sequencing of when the request interceptor operations are invoked
    in relationship to a static call, a DII call, and AMI_ calls.

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

    see above

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

How correlate requests and replies when using pollable sets?

  • Key: CORBA3-10
  • Legacy Issue Number: 3541
  • Status: closed  
  • Source: UBS ( Hans Kneubuehl)
  • Summary:

    When using the pollable sets, pollers are registered with
    PollableSet::add_pollable() and retrieved using
    PollableSet::get_ready_pollable(). As pollers are valuetypes they are passed by
    copy, thus portable applications must assume that get_ready_pollable() returns
    a different poller instance than the one passed to add_pollable(). Thus, with
    non-TII, currently there is no portable way to find out how requests
    (represented by the pollers returned from sendp) and replies (represented by
    the pollers returned from get_ready_pollable ) correlate.

    Consider the following IDL:

    module Stock
    {
    interface Quoter

    { long get_quote(in string stock_name); }

    };

    and a client that does a 1000 invocations in the style

    poller = quoter->sendp_get_quote(portfolio[i].stock_name);
    poll_set->add_pollable(poller);

    Now, the client could retrieve the 1000 replies in the order:

    while(poll_set->number_left() > 0)

    { pollable = poll_set->get_ready_pollable(timeout); ... }

    ;

    But how can the client find out which returned quote belongs to which
    stock_name?

    Possible resolutions:
    ---------------------
    (a) Reconsider the introduction of a correlation id on pollers which can be
    used to compare if two pollers are referring to the same request/reply.

    (b) Based on the fact that pollable set is locality-constrained and that
    valuetypes support sharing semantics (see CORBA 2.3, 5.2.4.2 Sharing
    Semantics), it could be required that PollableSet::get_ready_pollable() returns
    a pointer to the same valuetype instance as the one passed as argument of
    PollableSet::add_pollable().

    (c) Close without action, i.e. has to be solved at the application level, e.g.
    in our example the application would have to solve this by changing get_quote to

    long get_quote(in string stock_name, out string stock_name);

    Discussion:
    -----------
    (c) contradicts with the CORBA Messaging Philosophy that AMI is a mere
    client-side issue and that in principle any existing target can be called
    asynchronously.

    (b) means that we would have two different polling-related correlation
    mechanisms:

    • one for correlating requests and replies in different processes based on the
      PersistentRequest objref
    • one for correlating requests and replies in the same process based on poller
      pointers

    (a) means that a generic correlation mechanism is defined that covers both:
    intra- and inter-process correlation. This was variant (a) of issue 2803 in the
    latest vote. It failed with 5 NO : 4 YES : 3 ABSTAIN.

    I could work out two straw men for (a) and (b) for the next vote, or much
    better, we could try to discuss this before the next vote and just work out a
    straw man for the variant that has better acceptance.

  • Reported: CPP 1.1 — Mon, 10 Apr 2000 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    close no change

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

no way to register value factory from ORB initializer

  • Key: CORBA3-18
  • Legacy Issue Number: 3793
  • Status: closed  
  • Source: IONA ( Matthew Newhook)
  • Summary:

    There is currently no way to register a value factory from an ORB
    initializer.

  • Reported: CPP 1.1 — Mon, 28 Aug 2000 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above.

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

ORB accessor on POA?

  • Key: CORBA3-17
  • Legacy Issue Number: 3772
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    looking at the POA IDL, I get the impression that it was written at a time
    where the use of multiple ORBs in a process wasn't anticipated. With
    the advent of messaging, OTS, QoS policies, etc, it is more and more common
    for one application to use several ORBs simultaneously.

    When writing code, it becomes an endless pain dealing with multiple ORBs.
    That's because I have to endlessly pass the ORB around in my program, just
    so I can do things like call object_to_string() or string_to_object(), etc.

    I think it would be really useful to have an ORB() accessor on the POA
    interface:

    interface POA

    { CORBA::ORB ORB(); // ... }

    ;

    The accessor would return the ORB for this POA. Doing this would eliminate
    most of the cases in my code where I have to pass the ORB around. For
    example, in a servant, I can call _default_POA(), and then call ORB() to
    get at the ORB.

    Adding the operation would cause any compatibility problems, I believe.

    Opinions?

  • Reported: CPP 1.1 — Tue, 15 Aug 2000 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

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

RoutingPolicy issue

  • Key: CORBA3-16
  • Legacy Issue Number: 3770
  • Status: closed  
  • Source: Perot Systems ( Bill Binko)
  • Summary:

    This problem comes from the fact that RoutingPolicy is actually a range: min and max. Basically, Messaging defines this range of Routing QoS:

    ROUTE_NONE(0) ---> ROUTE_FORWARD(1) ---> ROUTE_STORE_AND_FORWARD(2)

    You can set your min and max to any of the values, with the caveat that min must be <= max. The issue that concerns us is when the min is ROUTE_NONE(0) and the max is either ROUTE_FORWARD(1) or ROUTE_STORE_AND_FORWARD(2).

    If you look at the Messaging spec (orbos/98-05-06) in section 5.3.5.3, it says:

    "If, for example, the min is ROUTE_NONE and the max is ROUTE_FORWARD, the Routing protocol will normally be used but a direct connection may be used if available."

    Of course, we've left in "usually" just to make sure we could screw up OTS for you

    Reading the text in section 3.3 makes me believe that an issue should really be raised in the Messaging-RTF to clarify this. Here's what I BELIEVE the results would be for all of the combinations.

    min maxresultconfidence ----------- ---------- -------------------- ROUTE_NONEROUTE_NONEDirect Call100% ROUTE_NONEROUTE_FORWARDTII if possible50% direct if not ROUTE_NONEROUTE_STORE_AND_FORWARDTII if possible50% direct if not ROUTE_FORWARDROUTE_FORWARDTII Only100% ROUTE_FORWARDROUTE_STORE_AND_FORWARDTII Only100% ROUTE_STORE_AND_FORWARDROUTE_STORE_AND_FORWARDTII Only100%

    Obviously, the problem is with cases #2 and #3.

    How should an ORB determine which to use: what priority is given to each of the RoutingType values?

  • Reported: CPP 1.1 — Mon, 31 Jul 2000 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    close no change

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

Missing minor codes in Messaging Chapter

  • Key: CORBA3-19
  • Legacy Issue Number: 3914
  • Status: closed  
  • Source: Thematix Partners LLC ( Jishnu Mukerji [X] (Inactive))
  • Summary:

    Minor codes specifications are missing in all the places where the
    specifications states that a system exception is to be raised. The minor
    codes need to be specifiedto complete the specification of exceptional
    beahivior.

  • Reported: CPP 1.1 — Thu, 14 Sep 2000 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

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

Portable Interceptors / register_initial_reference()

  • Key: CORBA3-15
  • Legacy Issue Number: 3672
  • Status: closed  
  • Source: International Business Machines ( Mr. Phil Adams)
  • Summary:

    I am in the process of implementing Portable Interceptors within a C++
    ORB,
    and I would like to raise an issue for resolution regarding the semantics
    of the
    "register_initial_reference()" function, particularly with respect to the
    memory
    management of the object being registered.

    The interface for this function is as follows:

    void register_initial_reference (
    ObjectId id,
    Object_ptr obj
    );

    Within the Portable Interceptors specification, there is really no
    information about
    how the memory for the object should be managed. For example, does the
    caller of
    "register_initial_reference()" pass ownership of the object to the ORB, or
    not?
    Also, does the caller of "resolve_initial_references()" gain ownership of
    the object
    which is returned, or not?

    Here is my proposed resolution:

    The fact that the "obj" parameter is a CORBA::Object implies that it is a
    reference-counted
    object. Therefore, it would make sense that when
    "register_initial_reference()" is called, the
    ORB performs a "_duplicate()" on the object to increment its reference
    count (the ORB would
    then hold its own reference count). The caller of
    "register_initial_reference()" can decide
    whether to call "release()" or retain its own reference count.

    Later, when "resolve_initial_references()" is called, the ORB would call
    "_duplicate()" on the
    object prior to returning it to the caller, thereby giving the caller its
    own reference count.
    The caller would then need to call "release()" when it is finished with
    the object.

    When the ORB is deleted, it must clean up the lookup table of registered
    objects. To do this,
    it simply calls "release()" on each one, and if no one else holds a
    reference count, then
    the object is simply deleted.

    I would like the hear other people's thoughts on this, particularly those
    who have done or are
    working on a C++ implementation of PI.

  • Reported: CPP 1.1 — Tue, 6 Jun 2000 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

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

Policy Management in Portable Interceptors

  • Key: CORBA3-14
  • Legacy Issue Number: 3615
  • Status: closed  
  • Source: foxfield-sw.demon.co.uk ( Nick Sharman)
  • Summary:

    (All document refs to ptc/00-04-05)

    Sec. 4.3.7.1 (Object::get_policy) talks about "the Policy as specified in
    the IOR". Policies get translated to IOR components, but AFAIK there's no
    general way that a component can be unscrambled to give a Policy. This
    suggests that we need another interception point, effectively the inverse of
    the existing IORInterceptor (sec. 21.5), that allows an IOR component to be
    converted into a Policy on the client side.

    I suggest something like:

    local interface ReceiveIORInterceptor : Interceptor

    { void establish_policies (in ReceiveIORInfo info); }

    ;

    local interface ReceiveIORInfo

    { CORBA::Policy set_policy (in CORBA::Policy policy); IOP::TaggedComponent get_ior_component (); IOP::TaggedComponent get_ior_component_from_profile ( in IOP::ProfileId profile_id); }

    ;

    and an extra operation add_receive_ior_interceptor in ORBInitInfo.

    ReceiveIORInterceptor::establish_policies provides the opportunity for an
    interceptor to turn IOR components back into Policies, using the
    interceptor's Policy Factories directly or indirectly via
    ORB::create_policy.

    The ORB will call this method on all registered ReceiveIORInterceptor
    objects during or before the first call of Object::get_policy (we needn't be
    more specific - this would allow eager calls on unmarshalling or lazy calls
    within Object::get_policy).

  • Reported: CPP 1.1 — Mon, 15 May 2000 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

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

ORBInitInfo needs the ORB

  • Key: CORBA3-9
  • Legacy Issue Number: 3429
  • Status: closed  
  • Source: International Business Machines ( Russell Butek)
  • Summary:

    Portable interceptor implementations need access to the ORB. The presumed
    place to put the ORB would be on ORBInitInfo since at least one
    implementation needs the ORB at initialization time. Is that sufficient?
    Or is it also needed in RequestInfo and IORInfo? My guess is that having
    ORB only on ORBInitInfo is sufficient. All interceptors begin here. If
    the ORB is needed at other points, the implementations can assure that it
    is available where it's needed.

    Since ORB is PIDL and we don't want to pollute the interceptor interfaces
    with PIDL, we have to create IDL access to the ORB, but that's another
    issue.

  • Reported: CPP 1.1 — Thu, 16 Mar 2000 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    This issue is a restatement of issue 3403. Merge with issue 3403 and close this issue

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

PI needs the ORB to be available in IDL

  • Key: CORBA3-8
  • Legacy Issue Number: 3403
  • Status: closed  
  • Source: International Business Machines ( Russell Butek)
  • Summary:

    Portable interceptor implementations need access to the ORB. In order to
    accomplish this, the ORB must be defined in IDL There are four
    possibilities that have been opined:

    1. Define the ORB as "native ORB;"

    This puts the ORB into the IDL namespace. However, the ORB is still
    described in PIDL. This doesn't really help us to remove PIDL, some folks
    feel this is a misuse of native, but it would be sufficient for the
    requirements of PI.

    2. Define an IDL wrapper for the ORB, call it proxyORB for now.

    proxyORB would contain exactly the same items that the PIDL ORB does, only
    defined in pure IDL. Advantages: this is a migration step toward getting
    rid of ORB PIDL if we encourage folks to use proxyORB rather than ORB.
    Disadvantages: dual maintenance; lots of work - too much for this FTF?; I
    don't think we know all the ramifications; where do you get a proxyORB?
    from the ORB?

    3. Make the leap and redefine ORB in IDL now.

    This option is similar to option 2, but the IDL is not a wrapper, it's the
    real ORB. Advantages: no dual maintenance; we get rid of ORB PIDL right
    now. Disadvantages: BIG step - too big for this FTF?; lots of work; I
    don't think we know all the ramifications.

    4. Make the ORB a primitive type like TypeCode.

    This seems to be generally undesired. It requires all compilers to change.
    Unless someone really likes this approach, I don't think we should even
    consider it.

  • Reported: CPP 1.1 — Thu, 16 Mar 2000 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    Resolve this issue simultaneously with 3772 and close it as soon as 3772 is resolved and closed

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

Question about routing policies

  • Key: CORBA3-7
  • Legacy Issue Number: 3355
  • Status: closed  
  • Source: Thematix Partners LLC ( Jishnu Mukerji [X] (Inactive))
  • Summary:

    How are the routing policies e.g.ImmediateSuspend, LimitedPing, UnlimitedPing,
    etc. created. It is not clear that these can be created using the standard
    create_policy operation since these policies are valuetypes that support the
    CORBA::Policy interface.

    Also what are the Policy Type tag values for these policies?

  • Reported: CPP 1.1 — Tue, 22 Feb 2000 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    close no change

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

Portable Interceptors: object_to_string, string_to_object

  • Key: CORBA3-6
  • Legacy Issue Number: 3322
  • Status: closed  
  • Source: IONA ( Matthew Newhook)
  • Summary:

    object_to_string and string_to_object are missing on ORBInitInfo.

  • Reported: CPP 1.1 — Mon, 17 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    Resolve in conjunction with 3772 and close this issue when 3772 is resolved

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

Overriding POA policies

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

    it appears to be impossible to portably attach OTS policies
    to POAs with the machinery that is currently in place. We need a fix for
    that, otherwise OTS ends up getting hamstrung...

  • Reported: CPP 1.1 — Mon, 15 May 2000 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.3
  • Disposition Summary:

    close no change

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

Portable Interceptors: 9.2.3 text describing `Arguments'

  • Key: CORBA3-12
  • Legacy Issue Number: 3601
  • Status: closed  
  • Source: DSTC ( Ted McFadden)
  • Summary:

    The text in section 9.2.3 / page 9-71 describing the
    arguments attribute to ORBInitInfo could use some
    more precise wording. It reads:

    "This attribute contains the arguments passed to ORB_init.
    They may or may not contain the ORB's arguments."

    I take this to mean that any ORB_init arguments that
    applied to the ORB instance being created may not be
    present. All other strings passed to ORB_init will be
    present so initialisation strings can be passed to
    the interceptors through ORB_init.

    With the current text it is possible to think that
    you may not get any of the arguments to ORB_init.

  • Reported: CPP 1.1 — Wed, 3 May 2000 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

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

Validity of object references

  • Legacy Issue Number: 3307
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    Section 15.4.5, page 15-39:

    LocateRequest messages may be sent from a client to a server to
    determine the following regarding a specified object reference:

    • whether the object reference is valid

    In the absence of a definition for how to judge a reference "valid", this
    is a meaningless statement.

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

    close with revision

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

An ORB should not accept an IOR with no usable profiles

  • Legacy Issue Number: 3303
  • Status: closed  
  • Source: Xerox ( Bill Janssen)
  • Summary:

    ORBs should be required to reject IORs that do not contain any profile that the ORB can use

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

    accomodated by proposed change from Issue 3234.

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

Should an ORB be allowed to drop non-standard profiles

  • Legacy Issue Number: 3235
  • Status: closed  
  • Source: Thematix Partners LLC ( Jishnu Mukerji [X] (Inactive))
  • Summary:

    Part 2: Should an ORB be allowed to drop non-standard profiles (as it is allowed
    to, indeed almost encouraged to do in GIOP/IIOP 1.2) even though it is not faced
    with any resource contraints. Moreover, when it is faced with resource
    contraints should it be required to follow a specific sequence in determining
    what profiles to drop.

  • Reported: CPP 1.1 — Tue, 18 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    The proposed resolution defines two possible IOR conformance classes for every ORB interoperability

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

selected_profile_index origin

  • Legacy Issue Number: 3622
  • Status: closed  
  • Source: Objective Interface Systems ( Mr. Victor Giddings)
  • Summary:

    Since the index numbering of sequences is a language mapping specific issue, the origin of the selected_profile_index within the IORAddressingInfo must be specified. I assume a zero origin is meant.

    Proposed Resolution:
    Add the following sentence to the description of IORAddressingInfo (in section 15.4.2.1 of the 25 March CORBA 2.4 preliminary draft): "The first profile has an index of zero."

  • Reported: CPP 1.1 — Thu, 18 May 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    Accept proposed solution.

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

Absence of Wide Character Code Set

  • Legacy Issue Number: 3576
  • Status: closed  
  • Source: Anonymous
  • Summary:

    CORBA is inconsistent on how to deal with the lack wide character code set
    information in an IOR and the codes set service context.

    When a server receives a service context without a wide character code set
    specified, then it is supposed to raise BAD_PARAM when it receives wide
    characters data from the client.

    However a client is supposed to raise INV_OBJREF if the IOR is missing
    from the server's native wchar code set . In CORBA 2.3, section13.7.2.6,
    "Code Set Negotiation", it says, "... a server that supports interfaces
    that
    use wide character data is required to specify its native wchar code set;
    if
    one is not specified, then the client-side ORB raises exception
    INV_OBJREF."

    This requires a client to know whether a server supports interfaces that
    use
    wide character data at the time the client receives an IOR. To determine
    this when the first IOR is received is a burdensome task. The client orb
    would be forced to apply an exhaustive examination, such scanning all of
    the
    server's IDL bindings or the contents of the IFR looking for wchar types.
    Additionally the client may need to determine if some Any might flow
    containing wchar data.

    I propose that the client's behavior be changed to match the server's. If
    any wide character data is encountered and the server's IOR was missing
    the native wchar code set, (which would cause the wide character
    transmission
    code set to not be negotiated), the client should raise BAD_PARAM.

    This will allow common marshal and demarshal code to be independent of
    whether it is running as a client or server. It also allows users to not
    configure
    wide character code sets if they know they aren't using them.

  • Reported: CPP 1.1 — Fri, 21 Apr 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    The check should be able to be done at invoke time by the client orb

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

ORB throwing exception if it finds unknown service context

  • Legacy Issue Number: 3565
  • Status: closed  
  • Source: UBS ( Urs Kuenzler)
  • Summary:

    Why does it make sense at all to allow an ORB to throw an exception if it finds
    a service context it does not "understand"? This is not very helpful for
    interoperability. Would a sending ORB have to handle this exception and resend
    the same request without context to allow to interoperate with an ORB throwing
    BAD_PARAM in this case? If an unknown service context is sent with a reply, the
    receiving ORB would throw BAD_PARAM at the caller (even if it got a valid
    reply). The originator of the service context wouldn't even know.

  • Reported: CPP 1.1 — Fri, 14 Apr 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    To close with Issue 3561 resolution to eliminate option of throwing exception

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

Wrong minor code specified in Chapter 13

  • Legacy Issue Number: 3561
  • Status: closed  
  • Source: Thematix Partners LLC ( Jishnu Mukerji [X] (Inactive))
  • Summary:

    In document ptc/00-03-02 on page 13-30 in the last bullet on that page it says: "If a system
    exception is raised , it shall be BAD_PARAM with an OMG standard minor code of 1".

    This cannot be right because the OMG standard minor code of 1 for BAD_PARAM is assigned to "failure
    to register, unregister or lookup value factory."

    I recommend that we change this minor code to a new one that is properly allocated with the
    associated text that reads something like: "Service context not understood". I am still wondering
    though why BAD_PARAM is the correct exception to raise. Wouldn't BAD_CONTEXT be more appropriate?

    In any case we have to change the minor code, even if we cannot make up our minds about which
    exception.

  • Reported: CPP 1.1 — Fri, 14 Apr 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    resolved and closed

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

Preserving unencapsulated information

  • Legacy Issue Number: 3327
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    Page 15-50 of 2.3.1:

    ORBs that suport only version 1.1. or 1.2 IIOP profiles must
    ignore, but preserve, any data in the profile that occurs
    after the components member.

    A 1.2 ORB is obliged to ignore, but preserve, any information that follows
    the components member in 1_1 profile body. I think the cost of implementing
    this is quite high. What follows after the components member is not in
    a separate encapsulation. So, an ORB that receives an IOR that indeed has
    data after the components member doesn't understand anything about that data
    and therefore must treat it as a blob of bits.

    However, the IOR might be little-endian and the receiving ORB might be
    big-endian. When the receiving ORB wants to send the IOR back out, it
    can't send it as a big-endian IOR because it can't know how to byte-swap
    the data that follows the components member. That means that a big-endian
    ORB is obliged to remarshal the IOR back as a little-endian IOR.
    That's inconvenient, to say the least.

    I don't think it makes sense to require an ORB to preserve something that
    is not encapsulated, simply because the cost of doing this is high.
    (The ORB has to keep a copy of the marshaled profile around because of
    the trailing bit it doesn't understand.)

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

    Close with revision

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

Indirection for value types

  • Legacy Issue Number: 3315
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    Section 15.3.4, page 15-18:

    The encoding used for indirection is the same as that used for
    recursive TypeCodes (i.e., a 0xffffffff indirection marker
    followed by a long offset (in units of octets) from the beginning
    of the long offset).

    [...]

    Indirections may refer to any preceding location in the GIOP
    message, including previous fragments if fragmentation is used.
    This includes any previously marshaled parameters.

    The beginning of the section ("is the same as that used for recursive
    TypeCodes") is in conflict with what appears at the end ("refer to any
    preceding location in the GIOP message [...]. This includes any previously
    marshaled parameters.")

    This is incorrect because the indirection for type codes does not permit
    indirections that span type code boundaries (page 15-27):

    The indirection applies only to TypeCodes nested within
    some "top-level" TypeCode. Indirected TypeCodes are not
    "freestanding," but only exist inside some other encoded TypeCode.

    I would suggest to rephrase the first part of what is on page 15-18
    to avoid saying that the indirection is the same as for type codes
    because that's simply not the case.

  • Reported: CPP 1.1 — Fri, 11 Feb 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    close with revision

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

chunked value encoding:

  • Legacy Issue Number: 3231
  • Status: closed  
  • Source: Anonymous
  • Summary:

    a chunk can be followed by:

    1. a new chunk (starting with its size tag)
    (1 <= chunk_size_tag < 0x7fffff00
    2. a new value (value_tag | 0 | value_ref)
    (0x7fffff00 <= value_tag <= 0x7fffffff)
    (valueref = 0xffffffff)
    3. an end tag
    (0x80000000 <= end_tag <= 0xffffffff)

    A value indirection and a "top-level" end tag, both have the same tag (0xffffffff).
    Consequently, the 0xffffffff tag marks the end of the current value but it is not clear whether or not a new value (indirection) has started.

    An example where this situation occurs is a ring buffer that is chunked encoded.

  • Reported: CPP 1.1 — Tue, 18 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    to close with revision

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

CORBA 2.3.1 missing text describing the response_expected field

  • Legacy Issue Number: 3195
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    When the response_flags text was added for GIOP 1.2 Request processing,
    the old text for the GIOP 1.0 and 1.1 response_expected field was
    removed. Thus, the current documentation no longer completely describes
    the GIOP 1.0 and 1.1 protocols.

  • Reported: CPP 1.1 — Fri, 7 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    to close with revision

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

Supporting TAG_MULTIPLE_COMPONENTS

  • Legacy Issue Number: 3176
  • Status: closed  
  • Source: Borland Software Corporation ( Vishy Kasar)
  • Summary:

    I have a question on how can ORB vendor support profile with ID
    TAG_MULTIPLE_COMPONENTS? The spec 2.3/13.6.2 says single profile holds
    enough information to drive a complete invocation. Let us say we have an
    IOR with one profile and the ID is TAG_MULTIPLE_COMPONENTS. As per
    13.6.2.2, the profile body in this case contains a
    MultipleComponentProfile. Let us again assume that there is only one
    TaggedComponent with component id of TAG_CODE_SETS and its component
    data.

    What we have here is a legal profile with no end point information. What
    can a ORB do with such a profile? Is there any thing broken here or did
    I just misinterpret the spec completely?

  • Reported: CPP 1.1 — Tue, 4 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Close with no revision

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

GIOP version and CloseConnection

  • Legacy Issue Number: 3438
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    I believe that, at some point, we decided that it is legal to send
    request for different GIOP versions over the same connection. Could someone
    please confirm or deny? (My memory is a bit hazy on the details.)

    At any rate, careful scrutiny of the spec does not reveal any words that would
    either state that separate connections must be used for different GIOP versions
    or that they can share a single connection. A definite statement is required
    either way.

    Assuming that different GIOP versions can indeed coexist on the same
    connection, we get an interesting problem: for GIOP 1.0 and 1.1, the spec
    disallows a client to send a CloseConnection message; for GIOP 1.2, it
    requires the client to send a CloseConnection message. This begs the question:
    if different GIOP versions can coexist on the same connection, it becomes
    impossible to achieve orderly connection shutdown. Sending a CloseConnection
    message is illegal for GIOP 1.0 and 1.1, whereas it is required for
    GIOP 1.2... So, what's the client to do if multiple GIOP versions are used
    over the same connection?

  • Reported: CPP 1.1 — Wed, 22 Mar 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    To close with revision

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

Valuetype in anys. Unmarshaling problem?

  • Legacy Issue Number: 3434
  • Status: closed  
  • Source: Borland Software Corporation ( Vijaykumar Natarajan)
  • Summary:

    There seems to be a problem with valuetypes contained in anys.

    Consider the following:
    valuetype A

    { A a; }

    ;

    valuetype B : A

    { private long long x; }

    ;

    If an instance w/ the following structure:

    A { a = {B { x = {<value>}}}}

    is inserted into an any and the any is received by an event service. Given that
    the event service has no type information of the B encoded inside of A, the
    event service has no way of knowing how big A.a (an instance of B) is and how
    many bytes it needs to read (unless it contacts an IR)

    Am I missing something here?

  • Reported: CPP 1.1 — Mon, 20 Mar 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    Close this issue and place it into the GIOP wish list for future enhancements to GIOP.

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

Transferring Java exception reason string across the wire

  • Legacy Issue Number: 3405
  • Status: closed  
  • Source: International Business Machines ( Russell Butek)
  • Summary:

    Although this is a Java-specific issue, I suspect it will have to be
    decided in interop, therefore I'd like this to be an interop issue. I've
    cc'ed java-rtf since I'm sure they'll be interested.

    System exceptions only have: minor code, completion status. Java
    exceptions all have a reason string as well. This is a potentially
    significant bit of info that is not getting transferred across the wire in
    Java ORB implementations. Our rmi over iiop customers expect this
    information.

    Our suggested solution is to create another service context for a system
    exception reason string. When a system exception occurs, on a Java server,
    the ORB places the reason string into this service context on the reply
    message. On a Java client, the ORB checks for and extracts this string and
    uses it when creating the system exception instance which is propagated to
    the application code. If the service context doesn't exist, the Java ORB
    just does what it does today. Any other client bindings may ignore this
    service context.

    Java bindings do not need to change for this proposal.

    To be more precise (sorta), we need three things:
    1. A new service context ID

    const ServiceId SystemExceptionReason = TBD;

    2. The context data associated with this ID is a CDR encapsulation of a
    string.
    3. Some verbage somewhere describing this.

  • Reported: CPP 1.1 — Tue, 21 Mar 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    closed/resolved

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

Nesting depth in valuetype end tags

  • Legacy Issue Number: 3526
  • Status: closed  
  • Source: hursley.ibm.com ( Simon Nash)
  • Summary:

    Section 15.3.4.5 contains an inconsistency in the description of how end tags
    for valuetypes are written. Consider the case where an unchunked value (V)
    contains a chunked value (CV1). Should the end tag for CV1 contain a nesting
    depth of -2 or -1?

    The following sentence in the spec seems to imply that the correct value is -2:

    > The end tag is a negative long whose value is the negation of the absolute
    > nesting depth of the value type ending at this point in the CDR stream.

    However the spec also says:

    > The outermost value type will always be terminated by an end tag with a
    > value of -1.

    which is not true if the end tag for CV1 is written as -2, since no end tag
    with a -1 value will be written.

    Proposed resolution:

    Delete the second above sentence from the spec.

  • Reported: CPP 1.1 — Fri, 31 Mar 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Close with revision using alternative A above.

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

Valuetype encoding grammar in 15.3.4.7 is wrong

  • Legacy Issue Number: 3512
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    The valuetype encoding "grammar" in 15.3.4.7 is wrong. The rule for
    <state> should be:

    <state> ::= <octets> |<value_data>* [ <end_tag> ]

    to allow for valuetypes with no state and therefore no value chunks.

    -

  • Reported: CPP 1.1 — Wed, 29 Mar 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    to close with revised text

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

Marshaling fixed-point decimal types

  • Legacy Issue Number: 3431
  • Status: closed  
  • Source: Oracle ( Stefan Bauer)
  • Summary:

    Looking at formal/99-10-07, 15.3.2.8 which describes marshaling of fixed
    types I ran into a question. The section doesn't mention how to indicate
    the scale of the written decimal.

    My understanding is that the TypeCode of kind fixed, which gets written
    before the value, indicates the maximum number of digits and the maximum
    scale, not what is currently contained in the number. To describe the
    current scale I would expect that a decimal point gets written to the
    stream, just like the decimals into the half-octets as described in
    15.3.2.8.

  • Reported: CPP 1.1 — Thu, 16 Mar 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Close with no Interop Revision

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

IIOP 1.2 Early Reply message in presence of fragmented Request

  • Legacy Issue Number: 3409
  • Status: closed  
  • Source: ICL ( Chris Wood)
  • Summary:

    It is unclear in the spec when reply messages are allowed when a fragmented
    send message is sent.

    It is possible to know that a system exception will occour before the last
    fragment in a message is recieved, for example the request can be
    demultiplexed to discover the object does not exist, or the appropriate
    service contexts are not present.

    It should be legal to send a reply containing anything but a NO_EXCEPTION or
    USER_EXCEPTION before the last fragment is recieved.

  • Reported: CPP 1.1 — Wed, 8 Mar 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    close without revision

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

Use of the type ComponentHome

  • Legacy Issue Number: 3645
  • Status: closed  
  • Source: Laboratoire d`Informatique Fondamentale de Lille ( Raphael Marvie)
  • Summary:

    1. In the document OMG ptc/99-10-04 p.69-329 there is in item 5 a use
    of the type ComponentHome, shouldn't it be CCMHome? If I do recall
    correctly, ComponentHome was used in the first versions of the
    specification proposal.

  • Reported: CPP 1.1 — Tue, 23 May 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    You are correct. ComponentHome should be CCMHome

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

USING Components::Enumeration

  • Legacy Issue Number: 3418
  • Status: closed  
  • Source: International Business Machines ( Mr. Ignacio Silva-Lepe)
  • Summary:

    It is probably not a good idea to mandate an implementation for
    Enumeration, since there may be different options for implementing.
    For example, it may be desirable for
    performance reasons to implement a form of lazy Enumeration that does
    not carry with it every element that it can contain, but requiring
    this kind of implementation can be overkill for some
    applications. Given this, Enumeration is defined as an abstract
    valuetype and at least one concrete specialization of it is
    required. In addition, FOR INTEROPERABILITY, at least one STANDARD
    implementation must also be provided so that client stubs and server
    skeletons know how to marshal and unmarshal Enumeration values.

  • Reported: CPP 1.1 — Tue, 14 Mar 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    resolution see above

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

destroy() for local objects

  • Legacy Issue Number: 3236
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    every ORB I know of implements the various destroy() operations on
    local objects (such as policies or DynAny) as a no-op and destroys the local
    object on the final call to release() instead. Yet, the spec still requires
    programmers to call destroy(). The problem with this is that programmers
    can easily end up writing non-portable code without any visible problem.
    Then, when code is moved to another ORB, it is conceivable that it will
    leak objects.

    This isn't very pretty. I think we should get rid of the destroy() calls
    on local objects (possibly with the exception of the ORB object, although
    the entire shutdown issue for that is quite a mess anyway). It doesn't
    make sense to require the programmer to make a destroy() call for something
    that naturally can be reference counted.

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

    When the interfaces identified in section 11.1.5 are updated to be local interfaces, any destroy() o

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

New IDL keywords

  • Legacy Issue Number: 3216
  • Status: closed  
  • Source: Oracle ( Ed Cobb)
  • Summary:

    Problem: The new IDL keywords use mixed case, rather than the lower case style used by current keywords. Should the new keywords be changed to comply with the existing style?

  • Reported: CPP 1.1 — Wed, 12 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    Yes, new IDL keywords should be changed to conform to existing style guide.

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

Implementation of get_component

  • Legacy Issue Number: 3213
  • Status: closed  
  • Source: Oracle ( Ed Cobb)
  • Summary:

    2. Implementation of get_component with separate ORB and component vendors
    Problem: A design goal of the components specification was to permit the component container to be provided by a different vendor than the ORB vendor. When this is true, how does the implementation of get_component work?

  • Reported: CPP 1.1 — Wed, 12 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    closed issue, resolved

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

CORBA IR METAMODEL

  • Legacy Issue Number: 3207
  • Status: closed  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    1) The isBasic Attribute needs to be removed from HomeDef to synchronize
    with the regular CORBA IR.

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

    resolved

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

Is the ccm_home method shown in Table 8-1 a typo?

  • Legacy Issue Number: 3191
  • Status: closed  
  • Source: International Business Machines ( Mr. Ignacio Silva-Lepe)
  • Summary:

    Table 8-1 shows a mapping for CCMObject::get_home. It looks like it should
    say CCMObject::get_ccm_home

    Proposal:

    Change "CCMObject::get_home" to "CCMObject::get_ccm_home" in Table 8-1.

  • Reported: CPP 1.1 — Fri, 7 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    No Data Available

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

How is CCMHome::get_home_def mapped to EJB operations?

  • Legacy Issue Number: 3190
  • Status: closed  
  • Source: International Business Machines ( Mr. Ignacio Silva-Lepe)
  • Summary:

    Chapter 8 omits to mention how the CCMHome::get_home_def call is mapped by
    the bridge at runtime to an EJB operation.

    Issue:
    The very similar call CCMHome::get_component_def is shown as mapped to the
    EJBHome.getEJBMetaData operation, but there is no mapping shown for
    CCMHome::get_home_def. It appears that get_home_def could be also be
    implemented using the EJBHome.getEJBMetaData operation, and if necessary,
    with the help of Java introspection.

    Proposal:
    Add a line in Table 8-1 to show CCMHome::get_home_def mapped at runtime to
    EJBHome.getEJBMetaData.

  • Reported: CPP 1.1 — Fri, 7 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    Add a line in Table 8-1 to show CCMHome::get_home_def mapped at runtime to EJBHome.getEJBMetaData

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

What's the return type of CCM mappings of EJB finder and creator methods?

  • Legacy Issue Number: 3189
  • Status: closed  
  • Source: International Business Machines ( Mr. Ignacio Silva-Lepe)
  • Summary:

    Summary:

    8.2.1.2 of the CCM specification says that EJB finder and creator methods
    which return an RMI object reference are mapped to methods which return a
    Components::CCMObject reference. It is unclear whether the actual base
    class CCMObject is intended or whether the specific component subclass
    (e.g., Widget) is intended. The specific subclass seems more sensible,
    and is consistent with the equivalent IDL mappings shown in section 5.8.4.

    Proposal:

    Change 8.2.1.2 to make it clear that the specific subclass (e.g., Widget)
    is the return type.

  • Reported: CPP 1.1 — Fri, 7 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    Change 8.2.1.2 to make it clear that the specific subclass (e.g., Widget) is the return type

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

Do EJB-mapped attributes go to the ComponentDefault interface?

  • Legacy Issue Number: 3187
  • Status: closed  
  • Source: International Business Machines ( Mr. Ignacio Silva-Lepe)
  • Summary:

    When mapping EJB set/get methods to a CCM view, it is not clear whether the
    resulting IDL attributes belong on the ComponentDefault interface or on the
    component definition itself

    Issue:
    Set/get method pairs on the EJB remote interface map to IDL attributes, but
    do these attributes end up in the XXXDefault interface or in the XXX
    component definition? Section 8.2.1.2 of the specification seems to imply
    they belong in the XXXDefault interface, but section 5.3.2 says the
    component definition for a basic CCM "shall only contain zero or more
    attribute declarations", which suggests that attributes of a CORBA
    Component belong in the component definition. Also, the mapping in the
    other direction (EJB view of a CCM), described in 8.3.1, suggests that CCM
    attributes are always found in the component definition itself. It appears
    that both versions will work, but this point is worth clarifying.

    Proposal:
    Change 8.2.1.2 to say that all EJB set/get method pairs are mapped to IDL
    attributes on the component definition itself.

  • Reported: CPP 1.1 — Fri, 7 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    resolved

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

CCM Issue: Is CCMObject::remove intended to be available to the CCM client?

  • Legacy Issue Number: 3183
  • Status: closed  
  • Source: International Business Machines ( Mr. Ignacio Silva-Lepe)
  • Summary:

    Section 5.12.1 of the spec can be interpreted to mean that the
    CCMObject::remove call is not intended for use by CCM clients; but this is
    inconsistent with the EJB/CCM mapping given in chapter 8.

    Issue:
    The explanation given for the CCMObject::remove call in section 5.12.1 is:
    "This operation is called when a component is about to be destroyed.
    The component
    can perform any cleanup processing required (e.g. releasing resources)
    prior to its
    destruction."
    This explanation can be interpreted to mean that the call is a private call
    from a CCM container to one of its components; if it has this internal
    purpose then it might not be
    intended for use by CCM clients wanting delete the component. However,
    table 8-1 shows that the CCM view of an EJB maps this call to the
    EJBObject.remove()
    method. This implies that the method is intended for client use as the
    EJBObject.remove() is. If so, then it also makes more sense to implement
    the
    CCMHome::remove() method in terms of the EJBObject.remove() method, rather
    than the current mapping which requires an EJB Handle.

    Proposal: (a) Change the text for remove() in 5.12.1 to say: "This
    operation is used to delete a component".
    (b) Change the mapping in table 8-1 for CCMHome::remove to use
    EJBObject.remove

  • Reported: CPP 1.1 — Fri, 7 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    Change the text for remove() in 5.12.1 to say: "This operation is used to delete a component".

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

Small optimization for the GIOP header

  • Legacy Issue Number: 3708
  • Status: closed  
  • Source: University of California, Irvine ( Carlos O'Ryan)
  • Summary:

    I think I found a possible (very minor) optimization for the
    GIOP 1.3 spec, but maybe I'm missing something in GIOP 1.2

    The new <target> field on the RequestHeader_1_2 structure is
    always aligned to a 4 byte boundary, the reserved[3] field ensures
    that. Consequently the discriminant for the TargetAddress union
    does not end on a 4 byte boundary, but will require 2 bytes of padding
    following it, since all the union values in this case start on 4 byte
    boundaries.

    IMHO, using just 1 byte for the reserved[] field, would have
    resulted in more natural alignments. Did I get something wrong here?
    Is this something likely to be fixed in GIOP 1.3?

  • Reported: CPP 1.1 — Fri, 16 Jun 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    Close this issue as too much of a change for this RTF, and add it to the GIOP wish list for future p

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

interop issue: CodeSets service context in GIOP 1.0 request

  • Legacy Issue Number: 3681
  • Status: closed  
  • Source: Xerox ( Bill Janssen)
  • Summary:

    Well, a new Java release is upon us, and with it comes a new CORBA
    implementation. I'm trying Java 2 SE 1.3 CORBA clients against an ILU
    2.0beta1 CosNaming server, and we find that the Java ORB cannot
    reliably connect to the server. Why not? First, we must analyze the
    IOR provided by the ILU service:

    IOR:000000000000002849444C3A6F6D672E6F72672F436F734E616D696E672F4E616D696E67436F6E746578743A312E300000000002000000000000002F0001000000000016776174736F6E2E706172632E7865726F782E636F6D00270F0000000B4E616D6553657276696365000000000100000024000100000000000100000001000000140001001800010001000000000001010000000000

    If we look at this (those who've received it un-truncated) we find that it advertises the following:

    _IIOP_ParseCDR: byte order BigEndian, repository id <IDL:omg.org/CosNaming/NamingContext:1.0>, 2 profiles
    _IIOP_ParseCDR: profile 1 is 47 bytes, tag 0 (INTERNET), BigEndian byte order
    _IIOP_ParseCDR: profile 2 is 36 bytes, tag 1 (MULTIPLE COMPONENT), BigEndian byte order
    (iiop.c:parse_IIOP_Profile): bo=BigEndian, version=1.0, hostname=watson.parc.xerox.com, port=9999, object_key=<NameService>
    (iiop.c:parse_IIOP_Profile): encoded object key is <NameService>
    (iiop.c:parse_IIOP_Profile): non-native cinfo is <iiop_1_0_1_NameService@tcp_watson.parc.xerox.com_9999>
    (iiop.c:parse_MultiComponent_Profile): profile contains 1 component
    (iiop.c:parse_MultiComponent_Profile): component 1 of type 1, 20 bytes
    (iiop.c:parse_MultiComponent_Profile): native codeset for SHORT CHARACTER is 00010001, with 0 converters
    (iiop.c:parse_MultiComponent_Profile): native codeset for CHARACTER is 00010100, with 0 converters

    That is, there's a vanilla Internet profile (bo=BigEndian,
    version=1.0, hostname=watson.parc.xerox.com, port=9999,
    object_key=<NameService>), plus a Multicomponent profile, noting that
    the ILU ORB's native codesets are Latin-1 and UCS-2.

    OK, great. Now we get the first message from the Java ORB:

    0000 47 49 4f 50 01 00 00 00 00 00 01 00 GIOP........
    0000 00 00 00 02 00 00 00 01 00 00 00 0c 00 00 00 00 ................
    0010 00 01 00 20 00 01 01 00 00 00 00 06 00 00 00 90 ... ............
    0020 00 00 00 00 00 00 00 28 49 44 4c 3a 6f 6d 67 2e .......(IDL:omg.
    0030 6f 72 67 2f 53 65 6e 64 69 6e 67 43 6f 6e 74 65 org/SendingConte
    0040 78 74 2f 43 6f 64 65 42 61 73 65 3a 31 2e 30 00 xt/CodeBase:1.0.
    0050 00 00 00 01 00 00 00 00 00 00 00 54 00 01 01 00 ...........T....
    0060 00 00 00 0c 31 33 2e 31 2e 31 30 33 2e 36 38 00 ....13.1.103.68.
    0070 0e e9 00 00 00 00 00 18 af ab ca fe 00 00 00 02 ................
    0080 67 d5 93 95 00 00 00 08 00 00 00 00 00 00 00 00 g...............
    0090 00 00 00 01 00 00 00 01 00 00 00 14 00 00 00 00 ................
    00a0 00 01 00 20 00 00 00 00 00 01 01 00 00 00 00 00 ... ............
    00b0 00 00 00 05 01 00 00 00 00 00 00 07 53 79 6e 65 ............Syne
    00c0 72 67 79 00 00 00 00 06 5f 69 73 5f 61 00 00 00 rgy....._is_a...
    00d0 00 00 00 00 00 00 00 28 49 44 4c 3a 6f 6d 67 2e .......(IDL:omg.
    00e0 6f 72 67 2f 43 6f 73 4e 61 6d 69 6e 67 2f 4e 61 org/CosNaming/Na
    00f0 6d 69 6e 67 43 6f 6e 74 65 78 74 3a 31 2e 30 00 mingContext:1.0.

    Note that we are seeing a CodeSets service context, even though the
    request is GIOP 1.0. The service context specifies a TCS-C of ASCII,
    and a TCS-W of UCS-2.

    The question is, what should the server do with it?

    First of all, there seems to be no way in which the algorithm in
    section 13.2.7.6 can result in the TCS-C specified in the service
    context. So perhaps this bug should be detected and signalled back to
    the sending ORB. How? Using CODESET_INCOMPATIBLE might make sense,
    but that really doesn't flag the bug in the client-side implementation
    of the codesets determination algorithm. Perhaps a straight
    COMM_FAILURE would be better. Opinions?

    Secondly, since this is GIOP 1.0, the client could reasonably ignore
    the service context, and go ahead with using its default codeset
    (Latin-1). However, to do so risks comm failure down the line, as
    ASCII (the TCS-C assumed by the client) does not permit many Latin-1
    characters. It seems better to flag this situation up front.

  • Reported: CPP 1.1 — Wed, 5 Jul 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    close with revision. See below

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

Version and byte order changes when fragmenting messages (interop)

  • Legacy Issue Number: 3680
  • Status: closed  
  • Source: ICL ( Chris Wood)
  • Summary:

    It's occoured to me that according to the spec it's allowable for
    a message to be fragmented and have second and subsequent
    fragments change the version fields.

    Having the version change while in the middle of reading a
    wstring could cause problems, the CDR encoding of version 1.1
    strings is always two bytes longer than the corresponding 1.2
    encoding, if the version changed while in the middle of reading
    the wstring the length field would be out by two.

    Secondly if request IDs are per-protocol rather than
    per-connection (as aired in issue 3438) then the request ids of
    the fragments could interfere.

    I think an extra phrase should be added to the spec with regards
    to fragmentation, similar to the one regarding byte order:

    The version of fragments must match the version of the initial message that
    the fragment extends.

  • Reported: CPP 1.1 — Fri, 16 Jun 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    Close without revision since the spec was already clarified to state this.

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

Issue 2 -- resulting from UK comment UK-5:

  • Legacy Issue Number: 3624
  • Status: closed  
  • Source: Object Management Group ( Henry Lowe)
  • Summary:

    The UK believes the footnote to section 13.6.2, page 13-16, of CORBA
    2.3.1 (this is clause 5.6.2 with the footnote appearing on page 13 of
    DIS 19500-2) does not make sense, especially the phrase "... except
    ones that make such profiles...". The meaning of this footnote needs
    to be clarified with revised text.

  • Reported: CPP 1.1 — Fri, 19 May 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    Close without revision.

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

Issue 1 -- resulting from Japanese comment JPN-009E:

  • Legacy Issue Number: 3623
  • Status: closed  
  • Source: Object Management Group ( Henry Lowe)
  • Summary:

    The Japanese would like to clarify the first sentence of the first
    paragraph of section 15.5.2, page 15-46, of CORBA 2.3.1 (this
    is clause 6.4.2 of DIS 19500-2, page 70) by adding the phrase
    "if Bi-Directional GIOP is not used" to the end of the sentence.
    The resulting sentence would read "Only the client (connection
    originator) may send Request, LocateRequest, and CancelRequest
    messages if Bi-Directional GIOP is not used."

    Is there any reason not to add this phrase now that Bi-Directional
    is in the OMG specification?

  • Reported: CPP 1.1 — Fri, 19 May 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    Agree that this was an editorial oversight in corba 2.3.

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

Is padding necessary for empty Reply body?

  • Legacy Issue Number: 3792
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    The Interop RTF added text that explicitly states that padding for a
    Request body in GIOP 1.2 is not necessary if the body is empty. No
    equivalent text was added for empty GIOP 1.2 Reply bodies.

  • Reported: CPP 1.1 — Fri, 25 Aug 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    Agree to add equivalent text for reply bodies.

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

GIOP _get_domain_managers ambiguous

  • Legacy Issue Number: 3787
  • Status: closed  
  • Source: Anonymous
  • Summary:

    In GIOP, the _get_domain_managers operation name is used to indicate
    an invocation of the get_domain_managers pseudo operation. OTOH, it is
    also used if an attribute domain_managers is accessed, as it would
    appear in

    interface I

    { readonly attribute long domain_managers; }

    ;

  • Reported: CPP 1.1 — Fri, 18 Aug 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    Changing the object reference operation on the wire to _domain_managers fixes the problem stated.

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

CCM Issue: How are standard EJB exceptions mapped into the CCM View

  • Legacy Issue Number: 3182
  • Status: closed  
  • Source: International Business Machines ( Mr. Ignacio Silva-Lepe)
  • Summary:

    Chapter 8 of the spec specifies mappings between EJB operations and their
    equivalents in the CCM view, but it leaves the mappings of standard EJB
    exceptions unclear.

    Issue:
    Create methods on an EJB home interface all throw the standard
    javax.ejb.CreateException; finder methods on the EJB home interface all
    throw the javax.ejb.FinderException; and remove methods on both home and
    remote interfaces all throw the javax.ejb.RemoveException. In a few cases
    chapter 8 gives an implied mapping: for example, the FinderException on the
    findByPrimaryKey method seems to map to either the
    Components.UnknownKeyValue exception or to the Components.InvalidKey
    exception on the equivalent find_by_primary_key CCM method. Even in these
    cases the names are sometimes inappropriate. In the majority of cases,
    however, there is simply no CCM equivalent to the EJB exception, and bridge
    implementors are left to wonder whether they should attempt a non-standard
    mapping.

    Proposal:
    (a) Add the new CCM standard exceptions Components.CreationFailure,
    Components.NotFound, and Components.RemovalFailure
    (b) Add Components.CreationFailure to the raises clause of all create
    methods on implicit and explicit home interfaces
    (c) Add Components.NotFound to the raises clause of
    find_by_primary_key on implicit home interfaces, and to the raises clause
    of all finder methods on explicit home interfaces
    (d) Add Components.RemovalFailure to the raises clause on the remove
    operation on implicit home interfaces, to the CCMObject.remove operation,
    and to the CCMHome.remove_component operation
    (e) Specify in chapter 8 that the EJB Finder exception is always
    mapped to Components.CreationFailure; that the EJB CreateException is
    always mapped to Components.CreationFailure; and that the EJB
    RemoveException is always mapped to Components.RemovalFailure.
    (f) Make explicit in chapter 8 the already implied mapping bewteen the
    EJB DuplicateKeyException and the Components.DuplicateKeyValue exception

  • Reported: CPP 1.1 — Fri, 7 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    No Data Available

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

Policies not locality-constrained?

  • Legacy Issue Number: 2611
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: the current spec doesn"t list policy objects as locality constrained.
    This seems rather strange. In particular, at the time I create policy objects,
    there is no POA that could be responsible for them, and I have no way
    to associate a policy object with a particular POA.
    Of course, this raises the question of whether references to policy objects
    are persistent or transient, whether I can pass them to another address
    space, whether requests on them are single-threaded or not, etc, etc.

  • Reported: CPP 1.0 — Fri, 16 Apr 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Close, no change (for 2.4).

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

Type ids in OBJECT_FORWARD return message

  • Legacy Issue Number: 74
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: When a GIOP "LocateRequest" message is sent to a location service and it replies with OBJECT_FORWARD, can the IOR have a type_id equal to simply CORBA::Object rather than the true type id?

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

    Closed with revised text

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

Use of dynamic ports

  • Legacy Issue Number: 382
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Static port # should not be mandated-unworkable.It would be nice if a "standard" IIOP port # was registered with IANA

  • Reported: CPP 1.0b1 — Mon, 2 Dec 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    closed with no revision required

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

CORBA::Object::non_existent

  • Legacy Issue Number: 126
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: section 7.2.5 names it "non_existent", while section 12.4.1 says that the GIOP protocol version is "_nonexistent".

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

    resolved, close issue

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

Correct IIOP marshalling of union TypeCodes

  • Legacy Issue Number: 89
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: There is a problem with marshalling of union TypeCodes where multiple discriminant values select the same arm of the union.

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

    closed with revised text

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

LOCATION_FORWARD byte alignment

  • Legacy Issue Number: 77
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: It would be good if the request body of a LOCATION_FORWARD reply always started on an 8 byte boundary.

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

    closed with revision from issue 901, 902

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

Defintion of Any

  • Legacy Issue Number: 147
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The definition of Any in C.3 is missing the no_copy flag in the class Any::from_string.

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

    Fixed in CORBA 2.2 editing process

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

Any extractor signature problem

  • Legacy Issue Number: 146
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Should the Any extractor signature be (Any_ptr &) instead of (Any &)?

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

    Fixed in CORBA 2.2 editing process

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

Missing Any inserter

  • Legacy Issue Number: 145
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The following inserter is missing in the C++ spec: void operation <<=(Any &, Any *); // non-copying

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

    Fixed in CORBA 2.2 editing process

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

IIOP object pointer resetting

  • Legacy Issue Number: 55
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Some IIOP implementations set the object pointers to nil object pointers, while others set them to nil pointers.

  • Reported: CPP 1.0b1 — Tue, 16 Jul 1996 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    closed, no revision required

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

Problem with GIOP CancelRequest when fragments are used

  • Legacy Issue Number: 488
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Potential problem in determining whether CancelRequest message applies to the current message or a message that has already had a reply sent. Resolutions to this: (file)

  • Reported: CPP 1.0b1 — Thu, 30 Jan 1997 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    closed with revised text

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

Transport Level Bridge

  • Legacy Issue Number: 465
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Work for transport level bridge that doesn"t need to understand full GIOP/IIOP protocol. Requirements: interoperability across network that doesn"t share commom transport protocol

  • Reported: CPP 1.0b1 — Wed, 4 Dec 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    accomodated by "NeedAddressingInfo" change

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

IORs and identifying Object Keys

  • Legacy Issue Number: 460
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Is there a standard by which you can identify whether incoming IOR is for an object reference in our ORB or not? Opaque object key could have same encoding in another ORB...Confusion

  • Reported: CPP 1.0b1 — Thu, 5 Dec 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    closed with no revision required

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

Callbacks in IIOP

  • Legacy Issue Number: 383
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Callbacks in IIOP are to be implemented by getting the server to connect back to client and act as a client itself. If this could be changed it would really help from firewall perspective.

  • Reported: CPP 1.0b1 — Mon, 2 Dec 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    closed with no revision required

  • 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

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

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

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

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

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

    clarified

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

Wide string allocation (1)

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

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

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

    closed issue, fixed

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

Bounded strings

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

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

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

    resolved, close issue

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

Interpretation of _narrow semantics

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

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

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

    fixed, close issue

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

Distinction between _var and _ptr types

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

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

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

    fixed

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

Return value of maximum() for unbounded sequences

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

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

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

    resolved, close issue

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

Sequence buffer types

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

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

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

    Addressed by resolution to issue 75

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

Sequence lacks common features

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

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

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

    Beyond scope of RTF - closed

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

get_principal () needs an environment parameter

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

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

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

    resolved, close issue

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

Names of anonymous types

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

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

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

    Duplicate of issue 52

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

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

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

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

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

    resolved, close issue

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

Problem with Any::to_object memory management

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

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

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

    resolved, close issue

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

C++ mapping complexity

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

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

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

    Beyond scope of RTF - closed

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

string and objrev members of constructed types

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

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

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

    Withdrawn by submitter

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

State of release flag for sequence

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

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

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

    Addressed by resolution to issue 75

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

Sequence implementation

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

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

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

    Addressed by resolution to issue 75

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

References returned from sequence operator[] after realloc

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

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

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

    clarified

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

Sequence maximum() call

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

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

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

    Duplicate of issue 185 - closed

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

fixed- vs. variable-length types

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

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

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

    Duplicate of issue123

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

Implementation dependency for _var and _ptr

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

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

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

    Duplicate of issue189

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

Any string extractor

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

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

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

    Clarifying text added

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

Adding T_copy function

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

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

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

    Fixed as suggested by submitter

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

Mapping for wide strings

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

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

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

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

    Fix the mapping to specify what WChar maps to.

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

Old References in C++ mapping

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

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

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

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

    These should now refer to Section 20.

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

    Close without change. Already fixed.

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

Semantics of >>= operator in C++ mapping

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

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

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

    closed with no change

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

Errors in example code for boxed struct

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

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

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

    Modify the sample code as indicated.

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

Object reference members, _var, and widening

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

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

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

    Clarify the text

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

98-09-03, exception inconsistency

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

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

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

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

    Close as duplicate of 1923.

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

Is SystemException supposed to be concrete?

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

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

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

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

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

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

DSI C++ issue

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

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

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

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

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

    Change the text as suggested.

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

resolve_initial_references missing from Orb interface

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

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

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

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

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

    Add the missing text.

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

Section 7.3.5 ValueBase editorial changes

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

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

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

    Fix the code.

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

C++ mapping for strings

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

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

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

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

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

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

Any and WChar issue

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

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

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

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

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

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

    closed, fixed

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

New C++ issue about T_out classes

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

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

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

    fixed, issue closed

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

from_string issue

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

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

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

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

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

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

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

    Close as duplicate of 2453.

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

void * functions for Any

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

    Summary: The mapping for Any currently requires:

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

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

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

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

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

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

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

Alias type codes in any values

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

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

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

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

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

Missing Mappings for Object

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

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

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

    closed with no change

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

Signature of _narrow in exceptions

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

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

    static SystemException * _narrow(Exception *);

    I think we should change this to

    static SystemException * _narrow(const Exception *);

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

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

    No Data Available

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

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

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

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

    class ServantBase

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

    ;

    and change the last paragraph of section 20.34.1 to:

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

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

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

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

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

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

    :ServantBase

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

Missing text describing fixed point constant mapping

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

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

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

    No Data Available

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

Missing constructor for Fixed

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

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

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

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

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

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

fixed_digits and fixed_scale member functions

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

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

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

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

    Fixed<5,2> x;

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

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

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

    No Data Available

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

C++ Any mapping proposed change

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

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

    class Any

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

    ;

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

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

    No Data Available

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

How to put a generic CORBA exception into an Any

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

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

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

    No Data Available

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

macros for fixed arithmetic results

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

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

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

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

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

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

    No Data Available

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

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

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

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

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

    should be

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

    2)
    operator LongDouble() const;

    should be

    operator CORBA::LongDouble() const;

    3)

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

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

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

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

    No Data Available

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

Fixed types in orbos/98-01-11

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

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

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

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

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

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

    No Data Available

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

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

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

    Summary: In section 5.6:

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

    In section A.24:

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

    {...}

    ;
    };

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

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

    No Data Available

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

C++ Fixed Type (03)

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

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

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

    No Data Available

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

Fixed type (02)

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

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

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

    No Data Available

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

_out parameter typo

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

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

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

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

    No Data Available

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

Typo in orbos/98-01-11

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

    Summary: Page 20-74, para 1:

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

    Should be

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

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

    No Data Available

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

C++ Fixed type issue (01)

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

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

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

    No Data Available

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

C++ mapping for fixed is broken (01)

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

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

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

    No Data Available

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

String member initialization

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

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

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

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

    No Data Available

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

Access to sequence elements

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

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

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

    Duplicate of issue 75 - closed

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

Any and IN_COPY_VALUE

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

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

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

    clarifying text added

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

operator>>= on strings and object references

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

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

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

    Clarifying text added

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

A_ptr and A_var should be distinct types

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

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

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

    Duplicate of issue 189 - closed

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

Default constructor for String_var

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

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

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

    Fixed as suggested by submitter

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

explicit copy/adopt for String_var

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

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

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

    handled by Portability submission - closed

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

TypeCode interpreter

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

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

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

    Fixed with issue 251

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

Any release flag and operator<<=

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

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

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

    requested functionality added

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

to/from string for Any type safety

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

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

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

    Requested functionality added

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

nested ptr and var types

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

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

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

    resolved, close issue

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

Typo in table 3?

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

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

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

    clarified

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

Sequence creation

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

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

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

    clarified

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

Accessors for release flag of sequence

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

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

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

    Duplicate of issue 75 - closed

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

T_copy for string and array

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

    Summary:

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

    Duplicate of issue 148 - closed

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

_var types for fixed-length types

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

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

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

    clarified

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

TypeCode mapping update for CORBA 2.)

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

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

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

    TypeCode interface updated

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

Interface issue

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

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

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

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

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

Transfer of C++ codes

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

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

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

    Closed without change

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

ORB mapping re Policy

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

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

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

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

    Add the missing operation.

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

Access to sequence buffers

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

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

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

    Fixed

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

Omission in union C++ mapping

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

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

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

    fixed by adding clarifying text

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

Any inserters for strings need to use const pointers

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

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

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

    Make the suggested fixes.

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

C++ keyword mapping ambiguous

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

    Summary: The last para of section 20.1.2 says:

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

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

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

    Clarify the text.

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

Extraction from Any by pointer

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

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

    class Any

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

    ;

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

    class Any

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

    ;

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

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

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

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

    fixed, issue closed

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

C++ spec uses reserved names in global namespace

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

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

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

    Close with no change

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

string allocation functions -- description ambiguous

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

    Summary: the text for string_alloc et al. says:

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

    [ ... ]

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

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

    I suggest to change the second sentence to read:

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

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

    Clarify the text.

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

String sequence and allocbuff

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

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

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

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

    closed

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

_raise() should be const

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

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

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

    Make _raise a const member function.

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

boxed types for floating point values

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

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

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

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

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

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

    Clarify the text.

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

Any inserters and extractors

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

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

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

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

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

    closed issue

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

CustomMarshal mapping type

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

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

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

    Fix the typo.

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

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

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

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

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

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

    This issue has already been resolved.

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

C++ classes for modules

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

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

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

    clarified

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

Defining an operator for struct/union/sequence _var types

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

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

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

    withdrawn by submitter

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

T__alloc in C mapping

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

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

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

    clarified

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

Memory Management Clarification

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

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

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

    No Data Available

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

Union discriminators in C++

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

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

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

    clarified

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

In String Argument Passing Question

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

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

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

    clarified

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

inserter and extractor functions for exceptions

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

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

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

    added clarifying texed, fixed

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

Union problem

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

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

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

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

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

    fixed

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

Fixed(const char *) constructor problem

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

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

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

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

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

    This means that the following call is illegal:

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

    Even though this can be rewritten (legally) as:

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

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

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

    closed/resolved

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

Editorial typo in Section 1.36.3 of C++ mapping

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

    The code example has a "ServantBaseBase_var".

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

    closed, editorial fix

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

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

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

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

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

    Close as duplicate of 2354.

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

Object _out class copy constructor & assignment op wrong

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

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

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

    closed/resolved

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

CORBA 2.3 Editorial problem in TypeCode

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

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

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

    editorial fix...isssue closed

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

Contents of string members (02)

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

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

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

    closed/resolved

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

Contents of string members (01)

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

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

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

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

    closed/resolved

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

String extractor semantics undefined?

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

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

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

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

    The same applies to wide strings.

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

    closed/resolved

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

Exception constructors should be protected

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

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

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

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

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

Exception::_raise() should be const?

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

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

    class Exception

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

    ;

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

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

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

Union string member mapping defect?

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

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

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

    closed/resolved

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

Unary operators for Fixed class have wrong return types

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

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

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

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

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

1 of 4 issues with Abstract interfaces

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

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

    // IDL

    interface A {
    };

    interface B : A {
    };

    // C++

    class MyA : public virtual POA_A {
    };

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

    However, this paradigm breaks when using abstract interfaces:

    // IDL
    abstract interface A {
    };

    interface B : A {
    };

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

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

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

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

    resolved/closed

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

NamedValue not only an NVList element

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

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

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

    editorial fix, issue closed

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

4 of 4 issues with Abstract interfaces

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

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

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

    closed/resolved

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

don't understand the last paragraph of 1.18.2:

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

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

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

    // IDL
    abstract interface A {
    };

    interface I : A {
    };

    valuetype V1 : supports A {
    };

    valuetype V2 : supports I {
    };

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

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

    see below

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

Extraction operator for system exceptions?

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

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

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

    // assume a contains a system exception...

    a >>= sep;

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

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

    I would like to suggest adding the following extraction operator:

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

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

    closed/resolved

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

Need Any::to_value operation?

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

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

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

    closed/resolved

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

2 of4 issues with Abstract interfaces

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

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

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

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

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

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

    closed/resolved

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

Supporting typedefs for _var types?

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

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

    What's missing at the moment is a similar feature for _var types.
    When I'm writing a template that does it's job in terms of _var types,
    I also quite often want to do something to the underlying target type
    of the _var. However, I can't do that unless I pass in an extra template
    parameter (which, in turn, doesn't always work if I also want to use
    STL standard binders and such...)

    So, why not add a typedef for the target type to every _var type?

  • Reported: CPP 1.0b1 — Mon, 1 Mar 1999 05:00 GMT
  • Disposition: Duplicate or Merged — CPP 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Any::to_abstract_base needs statement about memory management

  • Key: CPP11-121
  • Legacy Issue Number: 3113
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    The description of Any::to_abstract_base does not have any information
    about its memory managment implications. It should have the equivalent
    semantics to Any::to_object, and require the resulting reference to be
    released by the caller.

  • Reported: CPP 1.0 — Sun, 12 Dec 1999 05:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    closed/resolved

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Standard object operations & DynamicImplementation

  • Key: CPP11-112
  • Legacy Issue Number: 2966
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    The CORBA 2.3 spec needs to make it clear that for dynamic
    implementations, invocations of the standard object operations
    (get_interface, is_a, non_existent) call the virtual functions defined
    in PortableServer::ServantBase, and do not call
    PortableServer::DynamicImplementation::invoke().

  • Reported: CPP 1.0 — Thu, 14 Oct 1999 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    closed/resolved

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Inconsistency in 1.7 and 1.9 of mapping

  • Key: CPP11-111
  • Legacy Issue Number: 2951
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    Minor editorial issue:

    In Section 1.9.2, "T_out Types":

    class T_out {
    public:
    //...
    T_out(const T_out& p) : ptr_(p.ptr_) {}
    T_out& operator=(const T_out& p)

    { ... }
    };

    In Section 1.7, "Mapping for String Types":

    class String_out {
    public:
    // ...
    String_out(String_out& s) : ptr_(s.ptr_) {}
    String_out& operator=(String_out& s) { ... }

    };

    Note the missing "const" in 1.7. I suspect String_out should do the
    same as T_out and pass const references.

  • Reported: CPP 1.0 — Mon, 11 Oct 1999 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    closed/resolved

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Typographical problems

  • Key: CPP11-123
  • Legacy Issue Number: 5450
  • Status: closed  
  • Source: Boeing Australia ( Bruce McIntosh)
  • Summary:

    Name: Bruce McIntosh
    Company: Boeing Australia
    mailFrom: bruce.mcintosh@boeing.com
    Notification: Yes
    Specification: C++ Language Mapping
    Section: 1.36.2
    FormalNumber: ptc/01-06-07
    Version: Proposed Available Revision
    RevisionDate: 01/26/2002
    Page: 1-136
    The example given has a couple of small typographical problems: (1) the function signature specifies a void return type, but returns a Foo* (2) the function returns "foo_servant->this;" which I think should be "return foo_servant->_this();"

    Perhaps the example should read:

    Foo* some_function (/.../)

    { Servant_var<Foo_impl> foo_servant = new Foo_impl; foo_servant->do_something(); // might throw... some_poa->activate_object_with_id(...); return foo_servant->_this(); }
  • Reported: CPP 1.0 — Sun, 30 Jun 2002 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Updated the example code as suggested

  • Updated: Fri, 6 Mar 2015 20:58 GMT

allocbuf() for bounded sequences?

  • Key: CPP11-120
  • Legacy Issue Number: 3110
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    What should allocbuf() for a bounded sequence return if I ask for more
    elements than the sequence bound? The spec doesn't say. I think it should
    return null in this case.

    Also, what should allocbuf() return if I ask for zero elements?

  • Reported: CPP 1.0 — Sat, 11 Dec 1999 05:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    closed/resolved

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Fixed::round and truncate issue

  • Key: CPP11-110
  • Legacy Issue Number: 2950
  • Status: closed  
  • Source: Progress Software ( Steve Vinoski)
  • Summary:

    The Fixed::round() and Fixed::truncate() functions do not mention what to
    do if their scale argument is larger than the current scale. I figure they
    shouldn't do anything – for example, "truncating" by making something have
    more digits doesn't seem to make sense. I propose adding the sentence below
    after the sentence reading "The round and truncate functions convert a
    fixed value to a new value with the specified scale." (page 23-32 of
    ptc/99-03-04):

    If the new scale is equal to or larger than the new scale, no rounding or
    truncation is performed and the result is equal to the target object.

  • Reported: CPP 1.0 — Wed, 29 Sep 1999 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    closed/resolved

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ORB interface destroy() operation issue

  • Key: CPP13-72
  • Legacy Issue Number: 4567
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The ORB interface destroy() operation defined in the core CORBA 2.3 spec seems to be missing from the associated C++ language mapping.

  • Reported: CPP 1.1 — Fri, 14 Sep 2001 04:00 GMT
  • Disposition: Resolved — CPP 1.3
  • Disposition Summary:

    Add the destroy operation to the ORB definition in 4.35.1 and 4.45.21

  • Updated: Fri, 6 Mar 2015 20:58 GMT

_ptr_type and _var_type typedefs

  • Key: CPP13-71
  • Legacy Issue Number: 1794
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: We recently added _ptr_type and _var_type typedefs into interface classes
    to make writing templates for interface types easier. We should add the
    same typedefs for valuetype classes.

  • Reported: CPP 1.0b1 — Tue, 11 Aug 1998 04:00 GMT
  • Disposition: Resolved — CPP 1.3
  • Disposition Summary:

    Add the missing typedefs

  • Updated: Fri, 6 Mar 2015 20:58 GMT

make it possible to write more generic C++ code

  • Key: CPP13-76
  • Legacy Issue Number: 14169
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The spec defines: // C++ class Seq_var; class Seq

    { public: typedef Seq_var _var_type; // ... }

    ; We propose to extend this to the following to make it possible to write more generic C++ code. // C++ class Seq_var; class Seq_out; class Seq

    { public: typedef Seq_var _var_type; typedef Seq_out _out_type: typedef ::CORBA::ULong _size_type; // ... }

    ;

  • Reported: CPP 1.2 — Fri, 31 Jul 2009 04:00 GMT
  • Disposition: Resolved — CPP 1.3
  • Disposition Summary:

    In section 4.11 add to the example at the end Seq_out and a _out_type typedef
    as in the revised text below.
    The _size_type typedef will make it possible in the user code to differentiate
    between the index of a sequence type and a user defined ULong value. To
    section 4.15 add the sentence
    To facilitate template-based programming, a nested public typedef _size_type is delivered as the type
    representing the length of the sequence.
    And to the sequence class examples in section 4.15 the following
    typedef ULong _size_type;

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Servant_var + spec typo?

  • Key: CPP13-75
  • Legacy Issue Number: 12913
  • Status: closed  
  • Source: lmco.com ( Abdullah Sowayan)
  • Summary:

    I was looking at the OMG IDL to C++ mapping specification, specifically
    page 123 and came across the below. It looks to me that their
    implementation in the spec is NOT correct. Shouldn't the swap function
    take the "tmp" Servant_var?

    Servant_var& operator=(Servant* p)
    {
    if (_ptr != p)

    { Servant_var<Servant> tmp = p; swap(_ptr, p); }

    return *this;
    }

    Servant_var&
    operator=(const Servant_var& b)
    {
    if (_ptr != b._ptr)

    { Servant_var<Servant> tmp = b; swap(_ptr, b._ptr); }

    return *this;
    }

  • Reported: CPP 1.2 — Mon, 6 Oct 2008 04:00 GMT
  • Disposition: Resolved — CPP 1.3
  • Disposition Summary:

    Update assignment operator as proposed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

valuetype classes should add _out_type typedef

  • Key: CPP13-79
  • Legacy Issue Number: 16356
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    To really support template meta programming the valuetype classes should deliver a typedef _out_type besides the _ptr_type and _var_type which are proposed to be added as part of issue 1794

  • Reported: CPP 1.2 — Thu, 7 Jul 2011 04:00 GMT
  • Disposition: Resolved — CPP 1.3
  • Disposition Summary:

    Add a _out_type typedef to the valuetype class

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Interface should add _out_type typedef

  • Key: CPP13-78
  • Legacy Issue Number: 16355
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    To really support template meta programming the inteface should deliver a typedef _out_type besides the already defined _ptr_type and _var_type

  • Reported: CPP 1.2 — Thu, 7 Jul 2011 04:00 GMT
  • Disposition: Resolved — CPP 1.3
  • Disposition Summary:

    Add a _out_type typedef to the interface class

  • Updated: Fri, 6 Mar 2015 20:58 GMT

C++ keywords should be updated

  • Key: CPP13-77
  • Legacy Issue Number: 16283
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The C++ keywords in section 4.47 should be updated and extended with the addition of C++0x

  • Reported: CPP 1.2 — Fri, 27 May 2011 04:00 GMT
  • Disposition: Resolved — CPP 1.3
  • Disposition Summary:

    Add the following keywords to the table on page 154 as part of section 4.47

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 4.5.4: parameter to _narrow

  • Key: CPP13-74
  • Legacy Issue Number: 12856
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    In section 4.5.4 it says: Unlike _duplicate, the parameter to _narrow is a reference of an object of any interface type (Object_ptr). If the actual (runtime) type of the parameter object can be widened to the requested interface’s type, then _narrow will return a valid object reference; it should say (widened to narrowed) Unlike _duplicate, the parameter to _narrow is a reference of an object of any interface type (Object_ptr). If the actual (runtime) type of the parameter object can be narrowed to the requested interface’s type, then _narrow will return a valid object reference;

  • Reported: CPP 1.2 — Thu, 18 Sep 2008 04:00 GMT
  • Disposition: Resolved — CPP 1.3
  • Disposition Summary:

    In section 4.5.4 change widened to narrowed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Context PIDL mapping bug

  • Key: CPP13-73
  • Legacy Issue Number: 4743
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    Section 1.31.3 says:

    • In the C mapping, set_one_value used strings, while
      others used NamedValues containg any. Even though implementations
      need only support strings as values, the signatures now uniformly
      allow alternatives.

    I would suggest to delete the entire bullet point. In particular, the notion
    of allowing alternative data types as propery values for contexts doesn't
    work because the receiver expects a sequence of strings with an even number
    of elements; if anything but a string sequence is sent, the receiver
    has no chance of unmarshaling it.

  • Reported: CPP 1.1 — Tue, 11 Dec 2001 05:00 GMT
  • Disposition: Resolved — CPP 1.3
  • Disposition Summary:

    Remove bullet as suggested

  • Updated: Fri, 6 Mar 2015 20:58 GMT

get_policy should return Policy, not Policy_ptr

  • Key: CPP13-80
  • Legacy Issue Number: 16358
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The Object::get_policy returns a Policy in IDL, not a Policy_ptr, that is the C++ return value

  • Reported: CPP 1.2 — Fri, 8 Jul 2011 04:00 GMT
  • Disposition: Resolved — CPP 1.3
  • Disposition Summary:

    Replace in 4.36.1 the text Policy_ptr to Policy

  • Updated: Fri, 6 Mar 2015 20:58 GMT

operator>> for String_var

  • Key: CPP11-97
  • Legacy Issue Number: 2619
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The C++ mapping says:

    A compliant mapping implementation shall provide overloaded operator<<
    (insertion) and operator>> (extraction) operators for using String_var
    and
    String_out directly with C++ iostreams.

    >From this definition it"s no clear whether operator>> allocates memory
    or not. That is, is the following code correct?

    CORBA::String_var str;
    cin >> str;

  • Reported: CPP 1.0 — Wed, 21 Apr 1999 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    closed/resolved

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Valuetypes and _out classes in C++ mapping

  • Key: CPP11-96
  • Legacy Issue Number: 2564
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: I"m trying to work out how valuetypes interact with My question is what should the two reference counts be, and why?
    >From my understanding, myVal"s reference count should be 1, and myPtr"s
    reference count should be 0.

    Is this correct? Perhaps an example _out type for valuetypes should be
    included in the spec to clear this up for future reference.

  • Reported: CPP 1.0 — Wed, 31 Mar 1999 05:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close no change. The submitter of the issue misunderstood _var semantics.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

generate concrete classes and factories for valuetypes without initializer

  • Key: CPP11-89
  • Legacy Issue Number: 2496
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Suggestion: generate concrete classes and factories
    for valuetypes that do not have any initializers. If a
    value type does not have any initializers, it should
    be safe to use the default constructor for all members.

    This would reduce the size of the code that needs
    to be written by the application programmer.

    Similarly, concrete factories could be generated for
    value boxes

  • Reported: CPP 1.0b1 — Mon, 1 Mar 1999 05:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    resolved/closed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

add a _var type for each servant type

  • Key: CPP11-88
  • Legacy Issue Number: 2445
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: full_desc: The C++ mapping for CORBA 2.3 introduces reference
    counting on servants and provides the
    PortableServer::ServantBase_var class for automated
    reference counting. However, this class can not be
    used if a more specific type of the servant is needed.
    Proposal: add a _var type for each servant type, for
    example POA_FooBar_var.

  • Reported: CPP 1.0b1 — Tue, 9 Feb 1999 05:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

tie doesn"t do ref counting

  • Key: CPP11-87
  • Legacy Issue Number: 2441
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: After all the recently past work getting servant reference counting, it
    just occurred to me that this doesn"t work with TIE. Or am I missing
    something?

    As things stand, to make it work it is necessary to derive a new class
    from both the instantiated tie template and RefCountServantBase. This
    then requires all the constructors to be redefined - ugh!

  • Reported: CPP 1.0b1 — Fri, 5 Feb 1999 05:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    See resolution for issue 4114, which addresses this issue as well.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Misleading text for DSI invoke() and _primary_interface()

  • Key: CPP11-86
  • Legacy Issue Number: 2357
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Section 20.38.3 of the CORBA 2.3 draft states:
    I believe that the intent of this paragraph is to forbid the user from
    calling invoke() and _primary_interface() directly, not to forbid the
    POA from calling _primary_interface() in circumstances other than
    processing a request.

    The paragraph should be reworded to say:

    "The invoke() and _primary_interface() methods will be called by the
    POA, and should never be explicitly called by the application."

  • Reported: CPP 1.0b1 — Fri, 29 Jan 1999 05:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close no change. This issue is already addressed in the CORBA 2.3 specification.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Valuetypes and arbitrary graphs

  • Key: CPP11-95
  • Legacy Issue Number: 2561
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Valuetypes can be used to form arbitrary, potentially circular graphs.
    This means that reference counts may never drop to zero and that more
    advanced garbage collection is required, which does not come natural to
    C++.

    An ORB may keep track of circularity by traversing a graph and can detect
    if the last outside reference is lost. However, the overhead is significant,
    and the solution would be incomplete, as users need not use "proper" refe-
    rence counting on graph nodes by ignoring both OBV_* classes and default
    reference counting.

    Possible solution: restrict CORBA::DefaultValueRefCountBase to
    non-circular graphs. Users can decide much better when a graph is safe
    to be cleaned up.

  • Reported: CPP 1.0 — Tue, 30 Mar 1999 05:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close as duplicate of 2309.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Factories for StringValue and WStringValue

  • Key: CPP11-94
  • Legacy Issue Number: 2560
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The C++ mapping for Objects by Value requires factories for marshalling
    valuetypes. Therefore, it needs to specify default factories for the
    standard StringValue and WStringValue types.

  • Reported: CPP 1.0 — Tue, 30 Mar 1999 05:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close no change. Valueboxes do not have factories.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

_primary_interface

  • Key: CPP11-84
  • Legacy Issue Number: 2029
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: From the C++ spec (CORBA2_3-c++.pdf) pg: 20-132

    For static skeletons, the default implementation of the _get_interface
    and _is_a functions provided by ServantBase use the interface associated
    with the skeleton class to determine their respective return values. For
    dynamic skeletons (see Section 20.37), these functions use the
    _primary_interface function to determine their return values.

    Does this mean that a dynamic implementation needs the IFR?
    If not, then how can _is_a be implemented for sub-types?

    I note that the java mapping includes the method _all_interfaces in Servant
    for precisely this reason...

  • Reported: CPP 1.0b1 — Fri, 2 Oct 1998 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Already resolved.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

The C++ mapping for valuetype _narrow should not _add_ref

  • Key: CPP11-83
  • Legacy Issue Number: 2002
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The C++ mapping for valuetype includes a typesafe _narrow generated
    for all values. The specification states that the caller
    of _narrow must invoke _remove_ref once on the returned value
    from _narrow (just like object reference _narrow).
    f

  • Reported: CPP 1.0b1 — Sun, 27 Sep 1998 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Already resolved.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Valuetype argument passing

  • Key: CPP11-92
  • Legacy Issue Number: 2523
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The passing of valuetypes as parameter to operations needs more
    consideration. Section 20.22 of ptc/98-09-03 (98/11/06) specifies
    that the callee should receive a deep-copy of each valuetype to
    preserve location transparently.

    Now, does this apply only to operations of interfaces, or also to
    valuetype operations? With the current phrasing, this applies just
    the same (meaning that valuetype operations also receive a deep-
    copy). And then there are abstract interfaces, which may incarnate
    a remote interface or a local valuetype.

  • Reported: CPP 1.0 — Tue, 9 Mar 1999 05:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close no change. The specification is already clear about valuetype argument passing semantics.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Add AbstractBase base type to IDL language?

  • Key: CPP11-91
  • Legacy Issue Number: 2499
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Does it make sense to add the AbstractBase base
    type to the IDL language, so that operations could
    receive an AbstractBase parameter?

  • Reported: CPP 1.0b1 — Mon, 1 Mar 1999 05:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    close with no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

narrow abstract interface class to concrete object?

  • Key: CPP11-90
  • Legacy Issue Number: 2498
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Should it be possible to narrow an abstract interface
    class to a concrete Object, or to downcast it to a
    Valuetype?

  • Reported: CPP 1.0b1 — Mon, 1 Mar 1999 05:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    closed/resolved

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Sequences and get_buffer()

  • Key: CPP11-93
  • Legacy Issue Number: 2530
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: This is a new issue for the C++ RTF.

    The mapping for sequences mandates a get_buffer() accessor for read/write
    access to the members of the sequence. It is mentioned that an implemen-
    tation is not required to store sequence elements in continuous memory
    for efficiency reasons, but may choose to do so only when get_buffer()
    is called.

    However, this introduces coherency problems if sequence elements are
    accessed and modified using both get_buffer() and operator[].

    get_buffer() is not possible for recursive sequences anyway.

  • Reported: CPP 1.0 — Fri, 12 Mar 1999 05:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close no change. The submitter of the issue misread the specification.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

sequence allocbuf parameter != 0

  • Key: CPP11-82
  • Legacy Issue Number: 1946
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Sequence allocbuf functions should be specified such that passing zero for
    their arguments is illegal. Allocating a sequence buffer of zero elements
    is rather pointless because nothing useful can be done with such a buffer.
    The result of passing zero to allocbuf should be implementation-defined,
    since throwing an exception is not a good way to handle programming logic
    errors (similar to how indexing past the end of a sequence is a logic error
    for which an exception is pretty useless).

  • Reported: CPP 1.0b1 — Sun, 13 Sep 1998 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close no change. Discussion of this issue determined that a zero parameter to allocbuf is legal and

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Any missing LongLong operators, etc?

  • Key: CPP11-85
  • Legacy Issue Number: 2118
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: In the latest spec (98-09-03) the Any class appears to be missing
    insertion extraction operators for LongLong, ULongLong, etc.

  • Reported: CPP 1.0b1 — Thu, 22 Oct 1998 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close no change. This issue is already addressed in the CORBA 2.3 specification.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Exception id for each exception type

  • Key: CPP11-43
  • Legacy Issue Number: 260
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: C++ mapping should make available the exception id for each exception type.. Sun would like to revise sec. 3.17 to add following function: static const char * _exception_id();

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    closed/resolved

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Accessor for exception id

  • Key: CPP11-42
  • Legacy Issue Number: 259
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The base exception class should include an accessor to get the exception id of an exception.It"s obtained from environment.Ability to get exception id is desirable in C++

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    closed/resolved

  • Updated: Fri, 6 Mar 2015 20:58 GMT

operator<< for ostreams and Exceptions

  • Key: CPP11-47
  • Legacy Issue Number: 266
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Exceptions could be formatted onto ostreams using operator<<..Examples available on /archives/issues/issue266

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    closed/resolved

  • Updated: Fri, 6 Mar 2015 20:58 GMT

C++ semantics vs. IDL semantics

  • Key: CPP11-49
  • Legacy Issue Number: 268
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Isn"t it the mappings responsibility to decide how to project the semantics to the underlying "wire rep". You don"t need to put NULL on the wire. Sec 16.18 Pg 16-46 para 11 CORBA2.0

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close no change. This change is too intrusive and would break too much existing code

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ANy release flag and operator

  • Key: CPP11-48
  • Legacy Issue Number: 267
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Sec 3.16.2 para 11 describes lifetime of inserted value. Since lifetime of the value is independent of value passed to operator<<=, Any must contain a copy of value.

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    close with no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Legal IDL cannot map to C++

  • Key: CPP11-53
  • Legacy Issue Number: 497
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Generated C++ (example) ends up with redefinition errors. This is not addressed in current C++ mapping. Options are to amend IDL or to simply state that such IDL cannot be translated.

  • Reported: CPP 1.0b1 — Wed, 5 Feb 1997 05:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    close with no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Double underscore identifier mapping

  • Key: CPP11-52
  • Legacy Issue Number: 496
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: identifiers containing a double underscore[..] are reserved for use by C++ implementations and standard libraries and shall be avoided by users. IDL could be amended to prohibit double undersc.

  • Reported: CPP 1.0b1 — Wed, 5 Feb 1997 05:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    closed with no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

make String_var reference but not adopt

  • Key: CPP11-46
  • Legacy Issue Number: 264
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: String_var could refer to memory without assuming memory management responsibilities for it, like void String_var::value(const char*, Boolean release = 0

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    close with no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

buffer classes for sequences

  • Key: CPP11-45
  • Legacy Issue Number: 263
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: p41,sec 3.13.3,para 24: These functions should return buffers, not T* If you wanted a T* provide a conversion on returned buffer. No need to lock down implementation in this manner

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    closed with no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

u++ binding for ServerRequest pseudo object

  • Key: CPP11-50
  • Legacy Issue Number: 290
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Class defined for ServerRequest shows op_def() operation. Seems not to be in IDL for ServerRequest and there is no description in the rest of the section (CORBA 2 spec, Sect. 18.4.1)

  • Reported: CPP 1.0b1 — Thu, 24 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close no change. This issue is already addressed in the CORBA 2.3 specification.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

[q] intf name == op name

  • Key: CPP11-51
  • Legacy Issue Number: 481
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Sentence in IDL spec "An identifier can only be defined once in a scope.However,identifiers can be redifined in nested scopes" seems to allow interface Foo

    { void Foo(in long 1); }

    ;

  • Reported: CPP 1.0b1 — Wed, 22 Jan 1997 05:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close no change. This issue is already addressed in the CORBA 2.3 specification

  • Updated: Fri, 6 Mar 2015 20:58 GMT

TypeCode for each basic and IDL defined types

  • Key: CPP11-44
  • Legacy Issue Number: 261
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Sec 4.10 para 2: pseudo object reference of form tc<type> made available for basic and IDL defined types. Sun wants replacements with global function of form TypeCode_ptr tc<type>

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close with no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Accessors for the Any release flag

  • Key: CPP11-41
  • Legacy Issue Number: 258
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Sun would like to add the following accessors to Any: Boolean release(); void release(Boolean);

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close with no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Constructor taking discriminant as argument

  • Key: CPP11-40
  • Legacy Issue Number: 255
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Sec 3.12 para1 describes union constructors.Sun would like to add new constructor that takes as its sole argument a discriminant value.It initializes union according to specified discr. value

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close with no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Name field for SystemExceptions

  • Key: CPP11-39
  • Legacy Issue Number: 253
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: SystemException class should contain a string name field for easy printing of error messages,or operator<< should be overloaded for each system exception

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    closed/resolved

  • Updated: Fri, 6 Mar 2015 20:58 GMT

union accessors

  • Key: CPP11-31
  • Legacy Issue Number: 231
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Accessors that return a reference to a non-const object can be used for read-write access. They are provided only for following types: struct, union, sequence, any.Provede for all types..

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close no change. This change is too intrusive and would break too much existing code.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

callee-allocated storage modification

  • Key: CPP11-30
  • Legacy Issue Number: 228
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: CORBA2.0 Sec 16.18 Pg 16-45 para 9 The caller has sufficient knowledge to release, but not sufficient knowledge to know if contiguous. ("to allow..we adopt the policy....")

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Already resolved.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

accessor members for structs

  • Key: CPP11-37
  • Legacy Issue Number: 245
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Struct Mapping: IONA that accessor functions be provided for struct members. Direct access to member variables still available. Enhancement affords the user a consistent interface.

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Closed with no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

allocbuf and initialization of elements

  • Key: CPP11-36
  • Legacy Issue Number: 241
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Sec 3.13.2 para 25describes allocbuf. Sun prefers that allocated sequence elements be initialized as if vector were allocated by sequence constructor

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close no change. This issue is already addressed in the CORBA 2.3 specification.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Allocated storage for out and return strings

  • Key: CPP11-34
  • Legacy Issue Number: 237
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Sec 16.6 Pg 16-11 CORBA2.0: Sec D.12 states that client stub allocates buffer of specified size for bounded strings.This may result in unnecessary memory consumption.

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    close with no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

accessor function on SystemException

  • Key: CPP11-33
  • Legacy Issue Number: 234
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: SystemException has accessor functions minor() and completed() rather than public data members like exceptions normally do. Normal mapping is to make exception data into public data members

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close with no change.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

void* from Any for constructed types

  • Key: CPP11-28
  • Legacy Issue Number: 226
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: tables not present in CORBA2.0 What about structs, unions, exceptions, and arrays?

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close no change. This issue is already addressed in the CORBA 2.3 specification

  • Updated: Fri, 6 Mar 2015 20:58 GMT

handling void* from Any

  • Key: CPP11-27
  • Legacy Issue Number: 225
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Sec 16.14.6 Pg 16-38 para 44 CORBA2.0 How are you supposed to delete/duplicate this void* value if you don"t know the type? Do we have to emulate a C++ compiler

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close no change. This issue is already addressed in the CORBA 2.3 specification.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Mapping for IDL context

  • Key: CPP11-32
  • Legacy Issue Number: 232
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: If operation in an IDL spec. has a context spec, then a Context_ptr input parameter follows all operation specific arguments (OMGD 3.19) It should map to const Context_ptr

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close with no change. Object references are always passed as a plain _ptr parameter and never as a c

  • Updated: Fri, 6 Mar 2015 20:58 GMT

union accessors require temporaries

  • Key: CPP11-38
  • Legacy Issue Number: 250
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: For structs and exceptions: Unions" access functions return primitives by value, not by refs.I need to use temporaries.Change them to refs

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close no change. This issue is already addressed in the CORBA 2.3 specification.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

anonymus types

  • Key: CPP11-29
  • Legacy Issue Number: 227
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Tables not present in CORBA2.0 Aren"t anonymus sequences still allowed in structs, union, and exception?

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close no change. This issue is already addressed in the CORBA 2.3 specification.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

C++ namespaces

  • Key: CPP11-35
  • Legacy Issue Number: 238
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Implementation dependent: Namespaces available/not available

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close no change. Issue withdrawn by submitter.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Multiple inheritance of C++ Servants is ill-defined

  • Key: CPP11-63
  • Legacy Issue Number: 674
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Please find example/discussion in corresponding archive file

  • Reported: CPP 1.0b1 — Mon, 11 Aug 1997 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    closed and resolved

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Blocking semantics of get_next_response not well specified

  • Key: CPP11-59
  • Legacy Issue Number: 646
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The semantics of get_next_response sec 4.3.4 are not well-defined with respect to blocking behavior. There is no explicit description of the behavior of the C++ routines

  • Reported: CPP 1.0b1 — Thu, 31 Jul 1997 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    resolved, issue closed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 16.2, Section 16.6: editorial

  • Key: CPP11-58
  • Legacy Issue Number: 622
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Section 16.2: "A shown" should be "As shown". Section 16.6: The title is incorrect "TMapping" remove the "T"

  • Reported: CPP 1.0b1 — Wed, 9 Jul 1997 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close as fixed. A search through the current draft does not locate either of the two typos mentioned

  • Updated: Fri, 6 Mar 2015 20:58 GMT

No conversion defined from a B_var to an A_ptr

  • Key: CPP11-67
  • Legacy Issue Number: 956
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: I was writing some C++ code and noticed that the following doesn"t work:

    // IDL

    interface A {
    };

    interface B : A {
    };

    // C++

    B_var bv = get_b_from_somewhere();
    A_var av = A::_duplicate(bv);

    because there is no conversion defined from a B_var to an A_ptr. Is
    there a way that this could be added to the language binding without
    ambiguity problems?

  • Reported: CPP 1.0b1 — Wed, 11 Feb 1998 05:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    close with no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ServantBase mappings

  • Key: CPP11-66
  • Legacy Issue Number: 920
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Should the C++ mapping for ServantBase also have _duplicate,
    _var mappings ? For example if get_servant is called on POA, what
    are the ownership rules for the returned Servant. It seems providing
    a _duplicate, _release operations on ServantBase might be useful. These
    operations could be used to ensure that the Servant is not released
    while the caller has a reference to it.

  • Reported: CPP 1.0b1 — Tue, 27 Jan 1998 05:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    resolved and closed in ptc/1998-09-03

  • Updated: Fri, 6 Mar 2015 20:58 GMT

C++ mapping of servants may result in ambigous run-time behavior

  • Key: CPP11-62
  • Legacy Issue Number: 673
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: If the same servant and ObjectId are registered with two POAs, _this() can"t know which object to return outside of a method invokation

  • Reported: CPP 1.0b1 — Mon, 11 Aug 1997 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close no change. This issue is already addressed in the CORBA 2.3 specification.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Implementation problem with policy objects using root POA

  • Key: CPP11-61
  • Legacy Issue Number: 663
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: It appears to be impossible to implement the policy objects using the root POA due to race conditions on the Polilicy::destroy() operation. There appears to be no safe time to delete servant

  • Reported: CPP 1.0b1 — Sat, 9 Aug 1997 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close no change. This issue is already addressed in the CORBA 2.3 specification.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Interface definition must be standardized

  • Key: CPP11-56
  • Legacy Issue Number: 608
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: IDL for Object Interface differs from that provided by core specification in section 7.2 page 7.2

  • Reported: CPP 1.0b1 — Wed, 9 Jul 1997 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close with no change. The relevant functions are shown in the latest C++ mapping.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

String_var and Any_var are missing the T_ptr definition

  • Key: CPP11-55
  • Legacy Issue Number: 600
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Appendix E page E-2 and E-3: String_var and Any_var classes are missing T_ptr definition that occurs in the template for var types. These should be added for completness.

  • Reported: CPP 1.0b1 — Wed, 9 Jul 1997 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close with no change. Only object reference types have _ptr type. They do not apply to strings or ty

  • Updated: Fri, 6 Mar 2015 20:58 GMT

C and C++ Mapping question

  • Key: CPP11-65
  • Legacy Issue Number: 705
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: IDL spec states that identifiers can have characters that are things like an A with accent aigu, or a german script B. Can IDL identifiers have these characters? How are they mapped ontoC/C++?

  • Reported: CPP 1.0b1 — Sat, 23 Aug 1997 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close as non-issue. IDL no longer permits non-ASCII letters in identifiers.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

inout strings modifiable?

  • Key: CPP11-64
  • Legacy Issue Number: 678
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: C++ mapping spec should be clearer about the rules for inout strings.There are currently two possible interpretations of what server can do with an inout string (details in archive)

  • Reported: CPP 1.0b1 — Mon, 18 Aug 1997 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    resolverd and closed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

sec. 18.1.2: explicit information on _this() is missing

  • Key: CPP11-60
  • Legacy Issue Number: 653
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The discussion of how _this() operates is missing explicit information about what to do if there is no request context. Should _this() return nil reference, or should exception be thrown

  • Reported: CPP 1.0b1 — Tue, 5 Aug 1997 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close no change. This issue is already addressed in the CORBA 2.3 specification.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

IDL from Ennvironment has invalid attribute

  • Key: CPP11-57
  • Legacy Issue Number: 618
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: IDL from Environment has an attribute called "exception" which is invalid. This member should be renammed to "ex"or some other name which is a legal identifier

  • Reported: CPP 1.0b1 — Mon, 14 Jul 1997 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close no change. Environment is defined as PIDL, so this is legal.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

const method qualification should be removed

  • Key: CPP11-54
  • Legacy Issue Number: 599
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: C++ mapping for pseudo request class contains const member functions mapped from readonly attributes. IDL does not define C++ mapping for readonly attribs to const member functions.

  • Reported: CPP 1.0b1 — Wed, 9 Jul 1997 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    close with no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Storage ownership issue

  • Key: CPP11-25
  • Legacy Issue Number: 223
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: CORBA2.0 Care must be taken to avoid using T_var types with these extraction operators. They will try to assume responsibility for deleting storage owned by Any. Problem in mapping.

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close with no change. That's how the mapping was designed to work.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Global functions vs. T_var namespace

  • Key: CPP11-24
  • Legacy Issue Number: 222
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Sec 16.12 Pg 16-28 CORBA2.0 p. 44, sec 3.14 para 8: Why are these global functions rather than static methods of T_var?

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    closed/resolved

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Array slice example

  • Key: CPP11-22
  • Legacy Issue Number: 219
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Sec 16.12 Pg 16-27 CORBA 2.0 Why is a Long Array_slice declared to be a typedef Long[]? Why are these locked down rather than allowing a slice to be a class?

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    resolved/closed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Semantics of sequence length() operation

  • Key: CPP11-21
  • Legacy Issue Number: 218
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Sec 16.11 Pg 16-23 CORBA2.0 What is the semantics of the length() member? When can I do reallocation? Can it truncate? Can it realloc if length== current size?

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close no change. This issue is already addressed in the CORBA 2.3 specification.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Implementation description

  • Key: CPP11-17
  • Legacy Issue Number: 206
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: [Sec 16.9 Pg 16-15 CORBA2.0 p.32, Section 3.11 para 4: Seems to describe an implementation. Why is it specified. Is this how Sec. 3.10.1 para 14 issue is supposed to be addressed?

  • Reported: CPP 1.0b1 — Fri, 11 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close no change. We do not have enough context to determine what the issue is.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Detection of initialization of T_var

  • Key: CPP11-16
  • Legacy Issue Number: 203
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: [Sec 16.8.1 Pg 16-14 CORBA2.0] p.31, Section 3.10.1 para 12: How do I know if the T_var I"ve been passed (in C++) has been initialized?

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close no change. This change is too intrusive and would break too much existing code.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

example incorrect?

  • Key: CPP11-14
  • Legacy Issue Number: 201
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Sec 16.8 Pg 16-13 CORBA2.0 p. 29, Section 3.10 example para 4. : This example looks incorrect. Example shown in 3.10.1 is inconsistent with the code in paragraph 4.

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close no change. We do not have enough context to determine what the issue is.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Levels of portability conformance requested

  • Key: CPP11-13
  • Legacy Issue Number: 199
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Sec 15.1.1 Pg 15-1 CORBA2.0 "Conforming client or server program is portable across all conforming implementations" We object the word "portable"being used in this context.

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close no change. We do not have enough context to determine what the issue is.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Copying of out parameters

  • Key: CPP11-20
  • Legacy Issue Number: 217
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Sec 16.11.2 Pg 16-25 CORBA2.0 p.41, section 3.13.2 para 21 Do I have to make an application level full copy? This doesn"t meet the performance goal outlined in the beginning

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Already resolved.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

C vs. C++ coding style

  • Key: CPP11-19
  • Legacy Issue Number: 215
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Sec 16.11.2 Pg 16-24 CORBA2.0 p. 40 Section 3.13.2, para 17 Looks like C, not C++

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close no change. We do not have enough context to determine what the issue is.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Autoextension of sequences

  • Key: CPP11-18
  • Legacy Issue Number: 208
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: [Sec 16.11 Pg 16-21 CORBA2.0 Since autoextension is not apparently supported, you should change "may" to "must"

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    resolved and closed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Pointers vs. values

  • Key: CPP11-26
  • Legacy Issue Number: 224
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Sec. 16.14.3 Pg 16-34 para 30 CORBA2.0 p.48, sec 3.16.3, para 26 Why is this specified. Why are pointers treated differently from Values. Primitives are not set to NULL

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close with no change. It is no longer possible to identify the document to which the question refers

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Assignment to T_var

  • Key: CPP11-15
  • Legacy Issue Number: 202
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: What happens if i assign a container of data I hold Does aliasing allow in more than simple temporary. Is there a restriction that there can be NO overlapping?

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close no change. We do not have enough context to determine what the issue is.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Array_forany

  • Key: CPP11-23
  • Legacy Issue Number: 221
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Do you anticipate end user"s instantiating the Array_forany class? Isn"t this a implementation detail? The name conflicts with IDL specifiable. Section should be removed.

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    closed/resolved

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Problems with deactivate_object()

  • Key: CPP11-76
  • Legacy Issue Number: 1627
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The POA does not properly define the behavior of POA operations
    for requests that are currently executing in an object that
    has been deactivated.

  • Reported: CPP 1.0b1 — Thu, 2 Jul 1998 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close no change. This issue is already addressed in the CORBA 2.3 specification.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Do POA servant classes need to use virtual inheritance?

  • Key: CPP11-75
  • Legacy Issue Number: 1535
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: 2. The spec is silent on whether POA servant classes need to use
    virtual inheritence when an IDL class inherits from the same base
    interface more than once:

    // IDL
    interface A

    { void op(); }

    ;
    interface B : A { };
    interface C : A { };
    value D : supports B, C { };

    Must POA_B & POA_C inherit virtually from POA_A or can defined
    independently with all of interface A"s operations? This makes a big
    difference for values that support interfaces, since, for example, value
    D is defined by the C++ language mapping to inherit from both POA_B and
    POA_C. So, does value D inherit one or two versions of A::op()?

  • Reported: CPP 1.0b1 — Thu, 18 Jun 1998 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    resolved

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Spec does not mention the existance of an Any_out class

  • Key: CPP11-73
  • Legacy Issue Number: 1520
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: 2. The spec does not explicitly mention the existence of an Any_out
    class. I believe that this class is necessary, following the same
    pattern as the normal T_out class for variable length structured types.

  • Reported: CPP 1.0b1 — Wed, 10 Jun 1998 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    resolved and closed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

_var & _out types problems (01)

  • Key: CPP11-72
  • Legacy Issue Number: 1519
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: 1. The spec insection 20.9.2 does not specifically address the form of
    T_out types for fixed length structured types. So, should the T_out
    type be:

    typedef T &T_out;

    or should it follow the form of the T_out type for variable length
    structured types and define as a "class T_out"? In this case, of course
    the copy contructor operator from T_var would not delete the pointer
    held by the T_var.

    Since the "class T_out" solution for fixed length types does not appear
    to have any advantages over the typedef, I recommend that the spec be
    modified to state that T_out types for fixed length structured types
    simply be a typedef of "T&".

  • Reported: CPP 1.0b1 — Wed, 10 Jun 1998 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Spec is too verse in defining the T_var types for fixed length

  • Key: CPP11-74
  • Legacy Issue Number: 1521
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: 3. The spec is too terse in defining the T_var types for fixed length
    structured types as having "the same semantics as T_var types for
    variable-length types." This is not quite true, since the signatures
    for out and return values of these types are different, thus changing
    the semantics of the implicit and explicit (out() and _retn())
    conversion operations. The spec should show the definition of the out()
    and _retn() operations for fixed length types as:

    T &T_var::out()

    { return ptr_; }

    T &T_var::_retn()
    { return ptr_; }
  • Reported: CPP 1.0b1 — Wed, 10 Jun 1998 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    closed/resolved

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Passing Fixed to operations

  • Key: CPP11-81
  • Legacy Issue Number: 1785
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: // IDL
    typedef fixed<4,2> F;

    interface foo

    { void op(in F param); }

    ;

    What should happen if at run time, I do the following?

    F myf = "12345.678D";

    foo_var fv = ...;
    fv->op(myf); // ???

    I think the operation should raise BAD_PARAM, because silent truncation
    is too dangerous. Note that the operation cannot send a fixed<8,3> because
    the operation expects a fixed<4,2> and will get a marshalling error if
    what arrives over the wire does not match the IDL definition.

  • Reported: CPP 1.0b1 — Fri, 7 Aug 1998 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close no change. This issue is already addressed in the CORBA 2.3 specification.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Comparison operators for Fixed

  • Key: CPP11-80
  • Legacy Issue Number: 1783
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The fixed mapping in 98-07-12 shows:

    Fixed operator > (const Fixed &val1, const Fixed& val2);
    Fixed operator < (const Fixed &val1, const Fixed& val2);
    Fixed operator >= (const Fixed &val1, const Fixed& val2);
    Fixed operator <= (const Fixed &val1, const Fixed& val2);
    Fixed operator != (const Fixed &val1, const Fixed& val2);
    Fixed operator == (const Fixed &val1, const Fixed& val2);

    I"m surprised at the return type – shouldn"t that be bool for ANSI
    compilers and int for non-ANSI compilers?

  • Reported: CPP 1.0b1 — Fri, 7 Aug 1998 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Already resolved.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

C++ Sequence mapping Question

  • Key: CPP11-70
  • Legacy Issue Number: 1134
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Section 20.13 states:

    "For each different named OMG IDL sequence type, a compliant
    implementation provides a separate C++ sequence type."

    This certainly means that each declared sequence with a different bound
    and component type maps to a unique C++ class. But how about this:

    // IDL
    typedef sequence<long> LongSeq1;
    typedef sequence<long> LongSeq2;

    Are LongSeq1 & LongSeq2 mapped to the same or different C++ classes?

  • Reported: CPP 1.0b1 — Tue, 7 Apr 1998 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close no change. This issue is already addressed in the CORBA 2.3 specification.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

TypeCode_ptr base_typecode(TypeCode_ptr tc)

  • Key: CPP11-69
  • Legacy Issue Number: 1115
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Look at this code and tell me what is wrong with it (CORBA:: left off
    for simplicity):
    So, now the question is: Inside the
    TypeCode_var::operator=(TypeCode_ptr tc)
    assignment operator, when tc == this, what should happen?

    Should this call release(this) to satisfy the requirements of code frag
    #3? Or should it be a noop to satisfy the requirements of code frag #4?

  • Reported: CPP 1.0b1 — Mon, 6 Apr 1998 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close no change. The submitter of the issue misunderstood _var reference counting semantics.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Parameter passing rules for ValueFactory

  • Key: CPP11-79
  • Legacy Issue Number: 1658
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Since it is a native, the parameter passing rules for ValueFactory
    must be specified so the register/unregister/lookup operations
    can be mapped.

  • Reported: CPP 1.0b1 — Thu, 9 Jul 1998 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Already resolved.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

C++ language mapping minor editorial revision

  • Key: CPP11-78
  • Legacy Issue Number: 1656
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: There are a few minor editorial mistakes in the C++ language
    mapping examples. These are included in this single issue for
    brevity.

  • Reported: CPP 1.0b1 — Thu, 9 Jul 1998 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Already resolved.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

C++ mapping for fixed is broken (02)

  • Key: CPP11-68
  • Legacy Issue Number: 1093
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: 2. The mapping for the "_out" type for Fixed is broken. It is
    specified as a typedef, for example "Fixed<3,1>" maps to:

    typedef Fixed<3,1> &Fixed_3_1_out;

    but the IDL grammar allows fixed types to be declared as attribute
    types, operation parameters and return values. This causes problems
    because it is no longer obvious where to declare the _out type for an
    out parameter.

  • Reported: CPP 1.0b1 — Sat, 21 Mar 1998 05:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close as fixed. The new Fixed mapping takes care of this.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Missing operators in orbos/98-01-11

  • Key: CPP11-71
  • Legacy Issue Number: 1383
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: the Any class shown on page 20-115 of 98-01-11 appears to be missing
    support for some of the new IDL types. In particular, no operators
    are shown for (unsigned and signed) long long and long double.

    Also, there is no operator to insert an unbounded wide string.

  • Reported: CPP 1.0b1 — Mon, 18 May 1998 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close no change. This issue is already addressed in the CORBA 2.3 specification.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 5.3.6.3 Value Factories

  • Key: CPP11-77
  • Legacy Issue Number: 1655
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The last paragraph of section 5.3.6.3 says the standard language mapping
    rules are followed when determining these operation signatures. Since
    one of the arguments/return values is a Native, this isn"t quite
    possible.

  • Reported: CPP 1.0b1 — Thu, 9 Jul 1998 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Already resolved.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Fixed structs

  • Key: CPP11-2
  • Legacy Issue Number: 123
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Should the ORB hide the difference between fixed and variable length structs from the application developer?

  • Reported: CPP 1.0b1 — Mon, 23 Sep 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close no change. This change is too intrusive and would break too much existing code.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Inconsistent interfaces for the operation pairs *duplicate* and

  • Key: CPP11-5
  • Legacy Issue Number: 186
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The operations duplicate and release work together to provide memory mgmt. functionallity. It"s desirable to use both via similar interface/syntax. nil/is_nil similar problem

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    close with no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Testing exceptions

  • Key: CPP11-4
  • Legacy Issue Number: 143
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: In the DII, testing what variety of exception is stored in the Request Pseudo-object requires a sequence of dynamic_cast<> or (_narrow) calls. It would be useful to have a single call.

  • Reported: CPP 1.0b1 — Tue, 1 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    closed/resolved

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Pseudo objects for DSI

  • Key: CPP11-8
  • Legacy Issue Number: 193
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: [Ch 17 CORBA2.0] Sun would like section 4 to include the interface for the dynamic server invocation

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close no change. This issue is already addressed in the CORBA 2.3 specification.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Identifier conflicts resulting from the language mapping

  • Key: CPP11-7
  • Legacy Issue Number: 192
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Section 3.1 para 4 specifies the rule for resolving identifier conflicts with C++ keywords. A similar rule is required to resolve name conflicts resulting from the mapping.

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close 192 with no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

TypeCode/Value mismatch in ANY

  • Key: CPP11-11
  • Legacy Issue Number: 197
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Implementation dependent: What happens if the typecode & value for the unsafe Any operations do not match?

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close no change. Issue withdrawn by submitter.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

illegal union access when discriminator is wrong

  • Key: CPP11-10
  • Legacy Issue Number: 196
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Implementation dependent: illegal access of union member accessor functions when the discriminator has the wrong value

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close no change. Issue withdrawn by submitter.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Passing of object reference in pointers

  • Key: CPP11-3
  • Legacy Issue Number: 125
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Suggest changing the mapping so that object references for an interface "T" are passed as "const T_ptr&" instead of just "T_ptr" for "in" parameters.

  • Reported: CPP 1.0b1 — Mon, 23 Sep 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close no change. This change is too intrusive and would break too much existing code.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Representation of void* returned from ANY

  • Key: CPP11-12
  • Legacy Issue Number: 198
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Implementation dependent: Implementation representation of the void * pointer returned by Any::value() for unknown types

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close with no change. The latest draft has already deprecated the void * member functions for type A

  • Updated: Fri, 6 Mar 2015 20:58 GMT

interface mapping

  • Key: CPP11-6
  • Legacy Issue Number: 188
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Mapping for Interface [16.3 CORBA2.0] Mapping example in 3.5.6 implements the ptr type as full pointer. A pointer could be implemented as a class

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close no change. This change is too intrusive and would break too much existing code.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

_ptr member accessors for string and objref

  • Key: CPP11-9
  • Legacy Issue Number: 195
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Implementation dependent: _ptr member accessors for strings & object references

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close no change. Issue withdrawn by submitter.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Escaped keyword mapping?

  • Key: CPP12-9
  • Legacy Issue Number: 4498
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    the mapping says in section 1.1.2:

    To avoid C++ compilation problems, every use in OMG IDL of a
    C++ keyword as an identifier is mapped into the same name preceded
    by the prefix "cxx." For example, an IDL interface named "try"
    would be named "_cxx_try" when its name is mapped into C++.
    For consistency, this rule also applies to identifiers that
    are derived from IDL identifiers. For example, an IDL interface
    "try" generates the names "_cxx_try_var" and "cxx_try_ptr,"
    ^^^^^^^^^^^
    that is, the IDL compiler behaves as if the interface were
    names "cxx_try" and then applies the normal mapping rules.
    ^ ^^^^^^^

    Four issues here:

    1) I think we have a typo at the first place I highlighed. I
    believe it should be "_cxx_try_ptr". (The leading underscore
    is missing in the text as it stands now.)

    2) Typo: It should be '...were named "cxx_try"', not
    '... were names "cxx_try"'

    3) To state that the compiler behaves is if the interface were
    named "cxx_try" doesn't explain where the additional leading
    underscore comes from because we get cxx, not cxx_
    for the mapped identifiers.

    Unfortunately, changing this sentence to state that the compiler
    behaves as if the interface were named "_cxx_try" won't fix
    it, because the leading underscore would be dropped by the
    IDL keyword escape mechanism.

    4) The explanations are insufficient:

    interface try {};

    This will result in "_cxx_try" as the interface name. But what
    about the generated tc type code constant? It could be:

    a) _cxx_tc_try

    This mapping would be consistent with the statement that
    the "cxx" is a prefix.

    b) cxx_tc_try

    Same as above but, given that, normally, the tc type code
    constants already start with an underscore, the escaped
    mapping results in a double underscore.

    c) _tc_cxx_try

    This mapping would be consistent with the directive to map
    as if the type were named "cxx_try".

    d) tc_cxx_try

    Same as above but preserves the underscore for both the
    "tc" and the "cxx", resulting in a double underscore.

    To me, interpretation (d) seems the most natural and intuitive because
    it preserves the leading "tc" for all type code constants (including ones
    for identifiers that are C++ keywords). Also, if the mapping of the type
    is to "_cxx_try", then it makes sense to have the double underscore because
    that is consistent and doesn't make an exception to the rule of "use
    "tc" for type code constants and "cxx" for IDL identifiers that are
    C++ keywords."

    Proposal:

    Rewrite the above para to read:

    To avoid C++ compilation problems, every use in OMG IDL of a
    C++ keyword as an identifier is mapped into the same name preceded
    by the prefix "cxx." For example, an IDL interface named "try"
    would be named "_cxx_try" when its name is mapped into C++.
    For consistency, this rule also applies to identifiers that
    are derived from IDL identifiers. For example, an IDL interface
    "try" generates the names "_cxx_try_var," "_cxx_try_ptr,"
    and "tc_cxx_try".

  • Reported: CPP 1.1 — Thu, 16 Aug 2001 04:00 GMT
  • Disposition: Resolved — CPP 1.2
  • Disposition Summary:

    accept the suggested proposal

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Local interfaces issue 1

  • Key: CPP12-8
  • Legacy Issue Number: 4496
  • Status: closed  
  • Source: Borland Software Corporation ( Vijaykumar Natarajan)
  • Summary:

    The current specification of the local mapping requires the
    implementation to enforce the "localness" of the object. This was very
    similar to the (old) java mapping. The inheritance heirarchy is as
    follows

    CORBA::LocalObject : CORBA::Object

    abstract MyLocalObject : CORBA::Object

    MyLocalObjectImpl : MyLocalObject, CORBA::LocalObject

    The problem here is that there is no way for the ORB or the code
    generators to enforce the last inheritance. And I am not even sure how
    an ORB can detect the following case

    MyLocalObjectImpl : MyLocalObject

    which I suspect would be a very common error.

    Proposal:

    Fix the mapping to have the following heirarchy.

    CORBA::LocalObject : CORBA::Object

    abstract MyLocalObject : CORBA::LocalObject <===== Difference is here

    MyLocalObjectImpl : MyLocalObject <== and here

    Now an _is_a("IDL:omg.org/CORBA/LocalObject:1.0") is guaranteed to give
    a correct answer and it is enforced by the IDL compilers.

    This is also backward source compatible.

  • Reported: CPP 1.1 — Tue, 14 Aug 2001 04:00 GMT
  • Disposition: Resolved — CPP 1.2
  • Disposition Summary:

    see issue #4160 (the proposed resolution rejects this suggestion)

  • Updated: Fri, 6 Mar 2015 20:57 GMT

implementing local interfaces in C++

  • Key: CPP12-16
  • Legacy Issue Number: 5579
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    There seems to be only two choices:

    1. Accept that changing interfaces to local breaks old code that implemented
    POA interfaces using servants. Not wonderful, but I can live with it, since
    the source code changes are evident and fixed in a straightforward fashion.

    2. Try to come up with a scheme where local objects can be implemented either
    by using LocalObject or by the traditional servant route. This is more
    specification work, but cleaner, and I an live with it too.

    While we are at it, we should make sure that any other CORBA 3.0 changes are
    properly reflected in the C++ mapping as well.

  • Reported: CPP 1.1 — Fri, 9 Aug 2002 04:00 GMT
  • Disposition: Resolved — CPP 1.2
  • Disposition Summary:

    see proposed resolution for issue #4160

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Initialized T_var?

  • Key: CPP12-15
  • Legacy Issue Number: 5578
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    a discussion in comp.object.corba pointed out the difficulty
    of testing whether a T_var has been initialized. There is
    no _is_null() member function or some such. As a result,
    calling operator->() appears to be the only way to test
    whether a T_var is initialized:

    if (T_var.operator->())
    // It's initialized...

    Not exactly elegant, but workable. However, the following
    words in the spec get in the way:

    "The overloaded operator-> returns the T* held by the T_var,
    but retains ownership of it. Compliant applications may not
    call this function unless the T_var has been initialized with a
    valid non-null T* or T_var."

    These words forbid me to call operator->() until after the
    T_var has been initialized, meaning that there is no portable
    and compliant way to test whether a T_var is nil. I think
    what was meant here is that

    "Compliant applications may not *dereference the return value
    of this function* unless the T_var has been initialized with a
    valid non-null T* or T_var."

    BTW – using operator->() to test for null is a bit obscure.
    We could add a _is_null() member to T_var for this. But,
    given the versioning confustion we'd cause and the fact
    that adding the member provides only marginal benefit,
    I think it may be better to leave things as they are. (But
    we should fix the description of operator->(), of course.)

  • Reported: CPP 1.1 — Tue, 20 Aug 2002 04:00 GMT
  • Disposition: Resolved — CPP 1.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Missin operations in Object interface, ptc/01-06-07

  • Key: CPP12-14
  • Legacy Issue Number: 4871
  • Status: closed  
  • Source: seimet.de ( Uwe Seimet)
  • Summary:

    in ptc/01-06-07, 1.34.1, several operations seem to be missing in the Object
    interface, e. g.

    get_client_policy()
    get_policy_overrides()
    validate_connection()

    These are also missing in the Object C++ class, 1.34.2. create_request2() is
    also missing here.

  • Reported: CPP 1.1 — Wed, 27 Feb 2002 05:00 GMT
  • Disposition: Resolved — CPP 1.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:57 GMT

String_var and C++ implicit conversions

  • Key: CPP12-19
  • Legacy Issue Number: 5807
  • Status: closed  
  • Source: Anonymous
  • Summary:

    This e-mail addresses three CORBA C++ Revision Task Force issues:
    3796
    3797
    4530
    It also addresses section 6.10.2 of your book, "Advanced CORBA
    Programming with C++" ((C) 1999).

    Starting with 6.10.2 of your book, p. 164, you show an example where a
    CORBA::String_var is implicitly converted to 'const char *' in a
    function call, with the conversion operators as defined on p. 157 (sect.
    6.10).

    However, the C++ language won't choose the 'const char *() const'
    operator as you (and I) would think. Instead, since the String_var
    isn't const in the call's scope, the 'char *()' (i.e., non-const)
    operator is chosen.

    Aparently, the conversion path
    String_var -> char * -> const char *
    Is considered "better" than the conversion path we'd expect, namely
    String_var -> const String_var -> const char *

    Further, updating String_var with the resolutions of Issues 3796 and
    3797 (as found in http://cgi.omg.org/issues/cxx_revision.html), namely
    removing 'operator char *()' and adding 'operator char *&()' now leads
    to the conversion path
    String_var -> char *& -> const char *
    The 'const char *' operator is still bypassed, and with 'operator char
    *&()' in the picture, it seems trouble is more likely.

    For reference, take a look at the USENET newsgroup comp.std.c++, the
    thread of "Subject: Implicit conversion of g++", starting 2000/03/02 (I
    know that long URL's don't e-mail well, but...
    http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&threadm=p6qr
    9dsxi04.fsf%40informatik.hu-berlin.de&rnum=1&prev=/groups%3Fhl%3Den%26lr
    %3D%26ie%3DUTF-8%26oe%3DUTF-8%26selm%3Dp6qr9dsxi04.fsf%2540informatik.hu
    -berlin.de)

    For reference, I've attached a little source-code. Imagine that the
    class is String_var. This program produces identical results under two
    compilers:

    • Microsoft's Visual C++ 6.0 (SP3)
    • CygWin's gcc v3.2

    Though the String_var implementations I've seen aren't adversely
    affected, I wanted to bring this compiler behavior to your attention. I
    think the CORBA & C++ folks should eventually know, too, since CORBA and
    C++ seem to miss each other here.

  • Reported: CPP 1.1 — Fri, 10 Jan 2003 05:00 GMT
  • Disposition: Resolved — CPP 1.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:57 GMT

need mapping for get_orb and get_component on CORBA::Object

  • Key: CPP12-18
  • Legacy Issue Number: 5784
  • Status: closed  
  • Source: Thematix Partners LLC ( Jishnu Mukerji [X] (Inactive))
  • Summary:

    The Core issue that adds get_orb to CORBA::Object has passed. It would
    be good if you were to initiate an issue in the C++ RTF to make the
    necessary changes in the C++ pseudo-object mapping section for Object to
    incorporate this new operation. While you are at it you might also wish
    to throw in the get_component operation, which was added by the
    Components specification, and is yet to get into the C++ mapping chapter
    (I think).

    These might be way easier tor esolve than some of the weightier issues
    that you have been struggling with, since these have very
    straightforward and non-controversial resolutions

  • Reported: CPP 1.1 — Tue, 10 Dec 2002 05:00 GMT
  • Disposition: Resolved — CPP 1.2
  • Disposition Summary:

    same as proposed resolution for issue #4871

  • Updated: Fri, 6 Mar 2015 20:57 GMT

No Mapping for Local interface in C++

  • Key: CPP12-17
  • Legacy Issue Number: 5580
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The bit that defines the mapping of local
    interfaces to C++ seems to be missing from the specification (ptc/99-10-09 has a change
    > based on the CCM specification, which does not appear in
    > ptc/01-06-07. )

  • Reported: CPP 1.1 — Fri, 9 Aug 2002 04:00 GMT
  • Disposition: Resolved — CPP 1.2
  • Disposition Summary:

    same as proposed resolution for issue #4160

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Bug on _var references

  • Key: CPP12-11
  • Legacy Issue Number: 4530
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    he spec shows on page 1-13:

    class A_var {
    public:
    // ...
    operator const A_ptr&() const

    { return ptr_; }
    operator A_ptr&() { return ptr_; }

    // ...
    };

    The conversion operator is overloaded for const and non-const.

    Now, two issues here:

    1) It seems that "const A_ptr &" as the return type for the
    first operator is wrong because it really means
    "A * const", not "const A *". So, if anything, I think it
    would have to be written as

    operator const A * &() const

    { return ptr_; }

    2) But why provide a const version of the conversion operator
    at all? Object references are never passed with a const
    qualifier, so why provide this conversion operator? I think
    it could simply be deleted without affecting anything.

    Proposal: Delete the const version of the conversion operator.

    Opinions?

  • Reported: CPP 1.1 — Wed, 22 Aug 2001 04:00 GMT
  • Disposition: Resolved — CPP 1.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Dangling reference

  • Key: CPP12-10
  • Legacy Issue Number: 4499
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    On page 1-3 of the mapping, it says:

    For more information about CORBA compliance, refer to the
    Preface, "Definition of CORBA Compliance" on page viii.

    That preface hasn't existed for a long time now.

    Proposal:

    Strike this sentence.

  • Reported: CPP 1.1 — Thu, 16 Aug 2001 04:00 GMT
  • Disposition: Resolved — CPP 1.2
  • Disposition Summary:

    Strike this sentence

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Structure member ordering

  • Key: CPP12-7
  • Legacy Issue Number: 4340
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    The C++ mapping says in section 1.10:

    An OMG IDL struct maps to C++ struct, with each OMG IDL struct
    member mapped to a corresponding member of the C++ struct.

    This doesn't say that the order of the struct members in C++ must be the
    same as in the IDL. Without that guarantee, code that compares pointers to
    members is non-portable. We need a requirement to preserve the order here.

  • Reported: CPP 1.1 — Wed, 6 Jun 2001 04:00 GMT
  • Disposition: Resolved — CPP 1.2
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:57 GMT

semantics of valuetype _downcast operation unclear

  • Key: CPP12-6
  • Legacy Issue Number: 4270
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    The definition of the _downcast operation generated for valuetypes is
    unclear about whether it increments the reference count of the valuetype
    before returning the downcasted pointer. I assume by the fact that it
    is called _downcast rather than _narrow that it should not increment the
    reference count.

    Proposal:

    Add the following text to the end of the last paragraph in 1.17.3:

    "The _downcast function does not increment the reference count of the
    valuetype."

  • Reported: CPP 1.1 — Fri, 13 Apr 2001 04:00 GMT
  • Disposition: Resolved — CPP 1.2
  • Disposition Summary:

    Add the proposed text

  • Updated: Fri, 6 Mar 2015 20:57 GMT

ValueRefCountBase::_add_ref

  • Key: CPP12-13
  • Legacy Issue Number: 4610
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    PortableServer::ValueRefCountBase derives from both CORBA::ValueBase and
    PortableServer::ServantBase. This create a problem because ValueBase
    contains

    virtual ValueBase * _add_ref() = 0;

    but ServantBase contains

    virtual void _add_ref();

    The easy fix would appear to be to change the ValueBase version to return void.

    Anyone see a problem with this? (I don't understand why the ValueBase version
    currently returns a ValueBase * anyway. Any subtle reason for this that I
    am not aware of?)

  • Reported: CPP 1.1 — Tue, 9 Oct 2001 04:00 GMT
  • Disposition: Resolved — CPP 1.2
  • Disposition Summary:

    Change _add_ref() on ValueBase to return void.

  • Updated: Fri, 6 Mar 2015 20:57 GMT

C++ mapping for CORBA::LocalObject

  • Key: CPP12-12
  • Legacy Issue Number: 4545
  • Status: closed  
  • Source: Dell Technologies ( Ted Burghart)
  • Summary:

    In the latest C++ mapping including RTF report changes (ptc/01-06-07) I see no mention of a mapping for CORBA::LocalObject. CORBA 2.4.x 3.7.6.2 states that this is to be specified in each language mapping.

    How does it get mapped and, in particular, what are it's memory management semantics and relevant methods?

  • Reported: CPP 1.1 — Wed, 29 Aug 2001 04:00 GMT
  • Disposition: Resolved — CPP 1.2
  • Disposition Summary:

    same as proposed resolution for issue #4160

  • Updated: Fri, 6 Mar 2015 20:57 GMT

LocalObject

  • Key: CPP12-3
  • Legacy Issue Number: 4172
  • Status: closed  
  • Source: IONA ( Matthew Newhook)
  • Summary:

    From orbos/99-07-01 (is there a more up-to-date version with the C++
    mapping?)

    namespace CORBA
    {
    class LocalObject
    : public virtual Object

    { protected: LocalObject(); ~LocalObject(); public: virtual void _add_ref(); virtual void _remove_ref(); // pseudo operations not shown... }

    ;
    };

    Member functions and any data members needed to implement the Object
    pseudo-operations and any other ORB support functions must also be
    supplied but are not shown.

    _add_ref

    The _add_ref member function is called when the reference is duplicated.
    A default implementation is provided that does nothing. A derived
    implementation may use this operation to maintain a reference count.

    _remove_ref

    The _remove_ref member function is called when the reference is
    released. A default implementation is provided that does nothing. A
    derived implementation may use this operation to maintain a reference
    count, and delete the object when the count becomes zero.

    This implies that by default a LocalObject will not be reference
    counted. That seems counter-intuitive. What was the intention here? It
    seems that every application I can think of will want reference counted
    local objects – however, to get this at present the application developer
    either has to implement the reference counting themselves or inherit
    off some proprietary interface.

  • Reported: CPP 1.1 — Tue, 23 Jan 2001 05:00 GMT
  • Disposition: Resolved — CPP 1.2
  • Disposition Summary:

    same as issue #4160

  • Updated: Fri, 6 Mar 2015 20:57 GMT

mapping of local interfaces

  • Key: CPP12-2
  • Legacy Issue Number: 4160
  • Status: closed  
  • Source: AdNovum Informatik ( Stefan Wengi)
  • Summary:

    I took a closer look at orbos/99-07-01 to see how I'd have to implement
    local objects.
    Several questions came to my mind:

    1)
    what happens if you invoke CORBA::Object::_duplicate on a LocalObject?

    • does it call _add_ref on the local object (as the spec seems to say in
      4.1.2)?
    • is it allowed to return a copy of the object?

    2)
    how is memory handling done on existing interfaces?

    4.1.5 defines a list of interfaces that are changed to local interfaces
    e.g. CORBA::Current. How are they supposed to support proper memory
    handling when the default implementations of _add_ref/_remove_ref do
    nothing?

    3)
    local interfaces can be implemented by the application programmer, e.g.
    PortableInterceptors.

    • what happens if my _duplicate operation on CORBA::Object creates a
      copy (which is legal) and my implemenation of the local interface
      contains some state?

    This mapping creates more problems than it solves.
    It breaks at least one of the basic rules of OO design: base classes
    must not know about subclasses.
    Also disabling some methods that are valid on CORBA::Object (e.g. is_a)
    is a hint for bad design.
    Why not take the same interface 'inheritance' approach as with value
    types?

  • Reported: CPP 1.1 — Thu, 18 Jan 2001 05:00 GMT
  • Disposition: Resolved — CPP 1.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:57 GMT

How to create a local object reference?

  • Key: CPP12-5
  • Legacy Issue Number: 4245
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    The text added by the CCM spec that describes LocalObject has no
    information on how to portably create a local object reference. Since
    we have ORB services, like the Security or Transaction service which
    must create local object references, and since we have a goal that these
    services should be portable as source code between ORBs, we need a
    portable way to create a local object reference.

    Proposal:

    Add a static _create_reference() member function to local object
    interface classes:

    // IDL
    local interface I

    { ... }

    ;

    // C++

    ... I_ptr;

    class I : ...

    { public: I_ptr _create_reference(I *); }

    ;

    A programmer can then create a new local object reference portably:

    class MyI : public I, public CORBA::LocalObject

    { ... }

    ;

    I_var new_i = I::_create_reference(new MyI());

  • Reported: CPP 1.1 — Fri, 30 Mar 2001 05:00 GMT
  • Disposition: Resolved — CPP 1.2
  • Disposition Summary:

    same as issue #4160

  • Updated: Fri, 6 Mar 2015 20:57 GMT

CORBA::Object & LocalObject

  • Key: CPP12-4
  • Legacy Issue Number: 4186
  • Status: closed  
  • Source: IONA ( Matthew Newhook)
  • Summary:

    Is the definition of CORBA::Object given the C++ specificaton intended
    to be normative? If so then the C++ mapping given in the components
    spec won't work since it's clear that LocalObject is supposed to
    override the various methods provided on CORBA::Object.

  • Reported: CPP 1.1 — Wed, 24 Jan 2001 05:00 GMT
  • Disposition: Resolved — CPP 1.2
  • Disposition Summary:

    same as issue #4160

  • Updated: Fri, 6 Mar 2015 20:57 GMT