Issues for C++ Revision Task Force mailing list

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Issue 52: Omission in union C++ mapping
Issue 75: Access to sequence buffers
Issue 91: Efficiency issue in C++ mapping
Issue 92: T__alloc in C mapping
Issue 94: Defining an operator for struct/union/sequence _var types
Issue 95: Re-opening modules
Issue 96: C++ classes for modules
Issue 98: In String Argument Passing Question
Issue 100: Union discriminators in C++
Issue 101: Memory Management Clarification
Issue 123: Fixed structs
Issue 125: Passing of object reference in pointers
Issue 134: Union problem
Issue 141: Practical problem with DII using Request Pseudo Object
Issue 142: inserter and extractor functions for exceptions
Issue 143: Testing exceptions
Issue 144: Rethrowing exceptions
Issue 145: Missing Any inserter
Issue 146: Any extractor signature problem
Issue 147: Defintion of Any
Issue 148: Adding T_copy function
Issue 150: Any string extractor
Issue 154: Problem with Any::to_object memory management
Issue 178: Bounded sequence problem (Section 16.11 p. 16-23)
Issue 185: Return value of maximum() for unbounded sequences
Issue 186: Inconsistent interfaces for the operation pairs *duplicate* and
Issue 187: Freeing inaccessible storage for T_var as out parameter
Issue 188: interface mapping
Issue 189: Distinction between _var and _ptr types
Issue 190: Names of anonymous types
Issue 191: get_principal () needs an environment parameter
Issue 192: Identifier conflicts resulting from the language mapping
Issue 193: Pseudo objects for DSI
Issue 194: Implementation dependency for _var and _ptr
Issue 195: _ptr member accessors for string and objref
Issue 196: illegal union access when discriminator is wrong
Issue 197: TypeCode/Value mismatch in ANY
Issue 198: Representation of void* returned from ANY
Issue 199: Levels of portability conformance requested
Issue 200: fixed- vs. variable-length types
Issue 201: example incorrect?
Issue 202: Assignment to T_var
Issue 203: Detection of initialization of T_var
Issue 204: string and objrev members of constructed types
Issue 205: Taking T out of T_var
Issue 206: Implementation description
Issue 207: C++ mapping complexity
Issue 208: Autoextension of sequences
Issue 209: Sequence implementation
Issue 210: State of release flag for sequence
Issue 211: Sequence maximum() call
Issue 212: References returned from sequence operator[] after realloc
Issue 213: Sequence lacks common features
Issue 214: Sequence buffer types
Issue 215: C vs. C++ coding style
Issue 216: Sequence creation
Issue 217: Copying of out parameters
Issue 218: Semantics of sequence length() operation
Issue 219: Array slice example
Issue 220: Return value of operator[] for array var
Issue 221: Array_forany
Issue 222: Global functions vs. T_var namespace
Issue 223: Storage ownership issue
Issue 224: Pointers vs. values
Issue 225: handling void* from Any
Issue 226: void* from Any for constructed types
Issue 227: anonymus types
Issue 228: callee-allocated storage modification
Issue 229: Typo in table 3?
Issue 230: _var types for fixed-length types
Issue 231: union accessors
Issue 232: Mapping for IDL context
Issue 234: accessor function on SystemException
Issue 235: A_ptr and A_var should be distinct types
Issue 236: operator>>= on strings and object references
Issue 237: Allocated storage for out and return strings
Issue 238: C++ namespaces
Issue 239: Implementation of parameter passing for T_var types
Issue 240: Any and IN_COPY_VALUE
Issue 241: allocbuf and initialization of elements
Issue 242: freebuf and destruction of elements
Issue 244: RTTI vs. _narrow for exceptions
Issue 245: accessor members for structs
Issue 246: Access to sequence elements
Issue 247: TypeCode mapping update for CORBA 2.)
Issue 248: nested ptr and var types
Issue 249: to/from string for Any type safety
Issue 250: union accessors require temporaries
Issue 251: decompose Any into constituent primitives
Issue 252: T_copy for string and array
Issue 253: Name field for SystemExceptions
Issue 254: iterating over Any primitives
Issue 255: Constructor taking discriminant as argument
Issue 256: Accessors for release flag of sequence
Issue 257: Any release flag and operator<<=
Issue 258: Accessors for the Any release flag
Issue 259: Accessor for exception id
Issue 260: Exception id for each exception type
Issue 261: TypeCode for each basic and IDL defined types
Issue 262: TypeCode interpreter
Issue 263: buffer classes for sequences
Issue 264: make String_var reference but not adopt
Issue 265: explicit copy/adopt for String_var
Issue 266: operator<< for ostreams and Exceptions
Issue 267: ANy release flag and operator
Issue 268: C++ semantics vs. IDL semantics
Issue 269: Default constructor for String_var
Issue 290: u++ binding for ServerRequest pseudo object
Issue 456: Interpretation of _narrow semantics
Issue 479: DII and DSI are useless with current Any
Issue 480: Persistent Any values
Issue 481: [q] intf name == op name
Issue 482: Defect with anonymus types in union mapping
Issue 484: OMG C++ Mapping: Implicit Conversion Operators
Issue 496: Double underscore identifier mapping
Issue 497: Legal IDL cannot map to C++
Issue 501: Bug in C++ NVList mapping
Issue 594: Boolean type left undefined by C++ mapping
Issue 599: const method qualification should be removed
Issue 600: String_var and Any_var are missing the T_ptr definition
Issue 601: Section 17..13.1 release()method should be added to mappping
Issue 605: Section 8.2: set_exception() supported by BOA?
Issue 608: Interface definition must be standardized
Issue 615: POA_*_tie classes in 18.1.4 can"t be supported
Issue 617: Why does get_principal() take an Environment parameter
Issue 618: IDL from Ennvironment has invalid attribute
Issue 621: C mapping for list_initial_services is incorrect
Issue 622: Section 16.2, Section 16.6: editorial
Issue 627: PortableServer:ObjectId_tow_wstring() and string_to_ObjectId()
Issue 637: Section 18.1.2: _this() and IMPLICIT_ACTIVATION need clarification
Issue 646: Blocking semantics of get_next_response not well specified
Issue 647: include files
Issue 653: sec. 18.1.2: explicit information on _this() is missing
Issue 663: Implementation problem with policy objects using root POA
Issue 673: C++ mapping of servants may result in ambigous run-time behavior
Issue 674: Multiple inheritance of C++ Servants is ill-defined
Issue 678: inout strings modifiable?
Issue 705: C and C++ Mapping question
Issue 721: Bounded strings
Issue 722: Wide string allocation (1)
Issue 723: Wide string allocation (2)
Issue 731: IDL generated C++ types and stream operators
Issue 732: Typo in C++ mapping
Issue 781: C++ mapping for IN object references
Issue 800: Missing Mappings for Object
Issue 801: Alias type codes in any values
Issue 803: C++ mapping: missing from_wchar and to_wchar
Issue 804: Typos in PIDL to C++ mappings
Issue 863: Read-only restrictions on parameters
Issue 902: CORBA::Bounds and CORBA::TypeCode::Bounds
Issue 914: Mappings for hash, is_equivalent, _is_a and _non_existent
Issue 920: ServantBase mappings
Issue 932: Semantics of >>= operator in C++ mapping
Issue 933: CORBA::ORB::InvalidName ambigious in C++ mapping
Issue 956: No conversion defined from a B_var to an A_ptr
Issue 1056: Fixed types in orbos/98-01-11
Issue 1069: Typos on p 20-34 of orbos/98-01-11
Issue 1070: macros for fixed arithmetic results
Issue 1072: fixed_digits and fixed_scale member functions
Issue 1073: Missing constructor for Fixed
Issue 1092: C++ mapping for fixed is broken (01)
Issue 1093: C++ mapping for fixed is broken (02)
Issue 1095: Old References in C++ mapping
Issue 1115: TypeCode_ptr base_typecode(TypeCode_ptr tc)
Issue 1124: C++ Fixed type issue (01)
Issue 1125: Fixed type (02)
Issue 1126: C++ Fixed Type (03)
Issue 1128: String member initialization
Issue 1134: C++ Sequence mapping Question
Issue 1137: Typos in parameter passing rules
Issue 1148: Typo in orbos/98-01-11
Issue 1149: _out parameter typo
Issue 1289: How to put a generic CORBA exception into an Any
Issue 1319: C++ Any mapping proposed change
Issue 1383: Missing operators in orbos/98-01-11
Issue 1384: Mapping for wide strings
Issue 1386: Any and WChar issue
Issue 1418: C++ _var type widening proposal
Issue 1519: _var & _out types problems (01)
Issue 1520: Spec does not mention the existance of an Any_out class
Issue 1521: Spec is too verse in defining the T_var types for fixed length
Issue 1534: Add _narrow() operation to each POA servant
Issue 1535: Do POA servant classes need to use virtual inheritance?
Issue 1538: Missing text describing fixed point constant mapping
Issue 1617: C++ mapping for strings
Issue 1626: C++ issue to coordinate with proposed resolution of issue 752
Issue 1627: Problems with deactivate_object()
Issue 1631: C++ Servants: Adding Reference counting
Issue 1655: Section 5.3.6.3 Value Factories
Issue 1656: C++ language mapping minor editorial revision
Issue 1657: Section 7.3.5 ValueBase editorial changes
Issue 1658: Parameter passing rules for ValueFactory
Issue 1659: Section 7.3.6: PortableServer::ValueRefCountBase
Issue 1686: resolve_initial_references missing from Orb interface
Issue 1700: void * functions for Any
Issue 1735: Servant management rules
Issue 1747: from_string issue
Issue 1776: New C++ issue about T_out classes
Issue 1777: DSI C++ issue
Issue 1783: Comparison operators for Fixed
Issue 1785: Passing Fixed to operations
Issue 1794: _ptr_type and _var_type typedefs
Issue 1799: struct containing Fixed type
Issue 1898: Fixed-point initialization
Issue 1899: Rounding and truncation of Fixed
Issue 1923: Is SystemException supposed to be concrete?
Issue 1937: Signature of _narrow in exceptions
Issue 1946: sequence allocbuf parameter != 0
Issue 1947: sequence max < length
Issue 1971: Extraction of strings from an Any
Issue 1983: Extraction of Fixed from Any
Issue 1984: Generic extraction of Fixed
Issue 2002: The C++ mapping for valuetype _narrow should not _add_ref
Issue 2003: Tie classes
Issue 2029: _primary_interface
Issue 2032: Typedef for ties?
Issue 2035: mapping IDL Unicode escapes to C++
Issue 2097: 98-09-03, exception inconsistency
Issue 2118: Any missing LongLong operators, etc?
Issue 2207: Need more info for custom marshalled value in C++
Issue 2215: Object reference members, _var, and widening
Issue 2222: Is public _ptr member mandatory?
Issue 2226: Errors in example code for boxed struct
Issue 2231: _raise() should be const
Issue 2234: String sequence and allocbuff
Issue 2253: portable includes
Issue 2285: Value Box Mapping
Issue 2286: string allocation functions -- description ambiguous
Issue 2288: C++ spec uses reserved names in global namespace
Issue 2306: Valuetypes as operation arguments
Issue 2309: Memory management of recursive value
Issue 2335: Extraction from Any by pointer
Issue 2345: "Diamond of Death" in CosLifeCycleReference
Issue 2346: Any inserters and extractors
Issue 2350: boxed types for floating point values
Issue 2351: CORBA2.3 C++ mapping for the TypeCode class (section 20.31.2)
Issue 2354: CustomMarshal mapping type
Issue 2355: ORB mapping re Policy
Issue 2357: Misleading text for DSI invoke() and _primary_interface()
Issue 2375: Transfer of C++ codes
Issue 2376: Interface issue
Issue 2441: tie doesn"t do ref counting
Issue 2443: C++ keyword mapping ambiguous
Issue 2445: add a _var type for each servant type
Issue 2453: Any inserters for strings need to use const pointers
Issue 2463: Incorrect types for type-safe Any extraction
Issue 2489: 20.17.9 Valuetype Inheritance
Issue 2496: generate concrete classes and factories for valuetypes without initializer
Issue 2497: Value boxes and sensible value issue
Issue 2498: narrow abstract interface class to concrete object?
Issue 2499: Add AbstractBase base type to IDL language?
Issue 2523: Valuetype argument passing
Issue 2525: string sequences and empty strings
Issue 2530: Sequences and get_buffer()
Issue 2560: Factories for StringValue and WStringValue
Issue 2561: Valuetypes and arbitrary graphs
Issue 2564: Valuetypes and _out classes in C++ mapping
Issue 2614: Setting the TypeCode of an Any without setting a value
Issue 2619: operator>> for String_var
Issue 2640: IDL that is not IDL!
Issue 2841: Two obvious typos in the C++ mapping for OBV (docs/formal/99-07-41.pdf)
Issue 2875: ValueBase::_copy_value clarification
Issue 2880: Union string member mapping defect?
Issue 2887: Contents of string members (01)
Issue 2888: Contents of string members (02)
Issue 2890: String extractor semantics undefined?
Issue 2895: Exception::_raise() should be const?
Issue 2897: Exception constructors should be protected
Issue 2902: Unary operators for Fixed class have wrong return types
Issue 2946: CORBA 2.3 Editorial problem in TypeCode
Issue 2947: Object _out class copy constructor & assignment op wrong
Issue 2948: Editorial typo in Section 1.36.3 of C++ mapping
Issue 2949: Fixed(const char *) constructor problem
Issue 2950: Fixed::round and truncate issue
Issue 2951: Inconsistency in 1.7 and 1.9 of mapping
Issue 2966: Standard object operations & DynamicImplementation
Issue 2967: NamedValue not only an NVList element
Issue 3055: _default_POA
Issue 3074: Problem with AbstractBase definition
Issue 3078: 1 of 4 issues with Abstract interfaces
Issue 3079: 2 of4 issues with Abstract interfaces
Issue 3080: don't understand the last paragraph of 1.18.2:
Issue 3081: 4 of 4 issues with Abstract interfaces
Issue 3092: Need Any::to_value operation?
Issue 3101: _var types for fixed-length underlying types
Issue 3103: Extraction operator for system exceptions?
Issue 3110: allocbuf() for bounded sequences?
Issue 3111: Abstract interface and DSI issue with C++
Issue 3113: Any::to_abstract_base needs statement about memory management
Issue 3150: Exceptions in servant constructors
Issue 3161: _out types and nested calls
Issue 3165: C++: ostream insertion
Issue 3206: Valuetype code typo in CORBA 2.3 C++ mapping
Issue 3217: Any and UnknownUserException
Issue 3222: C++ valuetype issue (01)
Issue 3223: Valuebox for object reference underspecified
Issue 3224: C++ Value Type issue (02)
Issue 3225: C++ ValueBox & Fixed question
Issue 3239: Obsolete text in 1.40.3
Issue 3242: C++ spec: Valuebase missing get_value_def
Issue 3245: Construction of _var types
Issue 3246: UnknownUserException and stubs
Issue 3247: fixed-length _var assignment from pointer
Issue 3248: Object Reference insertion/extration to Any
Issue 3298: Problem with OBV_ valuetype class constructor
Issue 3304: Problem with type specific valuetype factories in CORBA 2.3.1 C++ mapping
Issue 3326: ValueBase::_copy_value() function is underspecified
Issue 3328: Do valuetype POA servants get tie templates?
Issue 3331: Valuetype "copying" semantics underspecified? (C++ issue # 1)
Issue 3332: Valuetype "copying" semantics underspecified? (C++ Issue # 2)
Issue 3339: ref counting ambiguous?
Issue 3340: set_servant and null servant
Issue 3359: Issue with valuetypes & inout/out parameters
Issue 3380: Constructor for structures?
Issue 3381: _name and _rep_id
Issue 3401: void * operations on Any?
Issue 3532: DSI and implicit activation
Issue 3534: Null assignment to String_var?
Issue 3537: Sequence mapping & custom marshalling
Issue 3538: Read-only parameter remnants
Issue 3539: Variable-length out params and exceptions
Issue 3562: Supporting typedefs for _var types?
Issue 3563: Supporting typedefs for _var types?
Issue 3567: Any insertion for Boolean/Octet/Char
Issue 3574: unclear semantics for valuetype insertion into Any
Issue 3603: unspecified criterion for Any extraction
Issue 3604: Any extraction widening to ValueBase
Issue 3616: CORBA::Environment for EH compilers
Issue 3673: CORBA::release and CORBA::is_nil on POA_ptr
Issue 3796: Missing conversion operator on String_var
Issue 3797: Another issue with String_var
Issue 3944: CORBA::Fixed needs a to_string() conversion function
Issue 3966: _default_POA if no default ORB?
Issue 4002: CORBA::RequestSeq or CORBA::ORB::RequestSeq?
Issue 4114: Requiring ref counting in ServantBase
Issue 4119: questions to IDL - C++ mapping ( CORBA 2.3, valuebox)
Issue 4144: ORB::destroy() missing
Issue 4150: Optional parameters for _create_request?
Issue 4151: Passing two context lists to _create_request()
Issue 4153: _name & _rep_id pure virtual?
Issue 4157: publication of messaging / unchecked_narrow
Issue 4160: mapping of local interfaces
Issue 4166: Need for TIE template for skeletons for valuetypes that support
Issue 4172: LocalObject
Issue 4186: CORBA::Object & LocalObject
Issue 4199: Inserters/extractors for boxed strings?
Issue 4210: Non-exception neutral code in C++ mapping.
Issue 4243: Backward compatibility with C
Issue 4244: Remnant of read-only return values and out params
Issue 4245: How to create a local object reference?
Issue 4265: Server-side exception specifications and ISO C++ std::exception
Issue 4270: semantics of valuetype _downcast operation unclear
Issue 4274: There is an incorrect page reference
Issue 4288: ServantBase needs _get_domain_managers()?
Issue 4325: Deprecated Ref identifier
Issue 4340: Structure member ordering
Issue 4344: Typedefs for struct members?
Issue 4496: Local interfaces issue 1
Issue 4498: Escaped keyword mapping?
Issue 4499: Dangling reference
Issue 4530: Bug on _var references
Issue 4533: Fixed and truncation/rounding?
Issue 4539: UTF-8 and IDL character types in C++
Issue 4545: C++ mapping for CORBA::LocalObject
Issue 4567: ORB interface destroy() operation issue
Issue 4610: ValueRefCountBase::_add_ref
Issue 4743: Context PIDL mapping bug
Issue 4797: Add set of typedefs that would facilitate template programming
Issue 4871: Missin operations in Object interface, ptc/01-06-07
Issue 5440: Prohibit extracting from any into _out type?
Issue 5450: Typographical problems
Issue 5466: conversion algorithm not specified
Issue 5578: Initialized T_var?
Issue 5579: implementing local interfaces in C++
Issue 5580: No Mapping for Local interface in C++
Issue 5784: need mapping for get_orb and get_component on CORBA::Object
Issue 5807: String_var and C++ implicit conversions
Issue 5854: 1.16.3 Extraction from any
Issue 6163: _var's and valuetypes
Issue 6245: No portable way to create a OUT argument for a DII request
Issue 6276: Sequence _var needs const operator []
Issue 6413: Concrete ValueType _init class problem
Issue 11403: Section: 13.6 Server mapping
Issue 12856: Section 4.5.4: parameter to _narrow
Issue 12913: Servant_var + spec typo?
Issue 14169: make it possible to write more generic C++ code
Issue 14852: Describe operator != and == for all generated types
Issue 16283: C++ keywords should be updated
Issue 16355: Interface should add _out_type typedef
Issue 16356: valuetype classes should add _out_type typedef
Issue 16358: get_policy should return Policy, not Policy_ptr
Issue 16528: valuetype example has errors
Issue 16892: need unchecked narrow

Issue 52: Omission in union C++ mapping (cxx_revision)

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

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

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.

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?

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

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

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?

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?

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?

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

clarified

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

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.

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?

Summary: If I want to use the DII to send out multiple simultaneous requests, I don"t see a practical way to associate any client specific context that is C++ compliant to those requests.

deferred in June 2011 to the next RTF

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.

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.

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.

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

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

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

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().

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.

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()

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

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

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

Close 186 with no change. Making changes to fundamental parts of the API purely to for stylistic reasons is too high a price to
pay because it would break existing code.

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??

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

 Proposed resolution: Passing an objref implemented as an object (as opposed to a pointer) as a reference to const requires all the operations supported by that objref to be const member functions.

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.

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

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

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.

Close 192 with no change. We've discussed this in the past, and all the options we could come up with a worse than the
original problem. I haven't heard anyone complain about this in practice, so it's probably better to leave it alone.

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

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

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

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

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

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

Close with no change. The latest draft has already deprecated the void * member functions for type Any, so the issue is moot.

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.

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

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.

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?

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?

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

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?

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?

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 !!!!

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

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?

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?

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.

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

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.

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.

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

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?

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

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?

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?

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

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.

Close with explanation that application code must use the array_forany class in order to insert and extract arrays of the correct
type. The helper class is necessary because, otherwise, there would be no way to distinguish among arrays of the same element
type, but of different length.

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?

Close with no change. I dug up the old 2.0 spec (96-08-04.pdf), but the question obviously refers to some draft version of the
document. Neither section numbers nor page numbers match. It appears impossible to identify the document to which the
question refers to. Since it was simply a question without a proposal or defect, we should close it.

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.

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

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

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

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

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....")

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

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

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..

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

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

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

Close with no change. I agree, the discrepancy between user exceptions and system exceptions is jarring. However, there i too
much code out there that would break if we cleaned this up.

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)

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.

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.

Close no change. We believe the caller misread the text to say that the return buffer for bounded strings must always be the
maximum size, which is incorrect.

Summary: Implementation dependent: Namespaces available/not available

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

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...

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

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...

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.

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.

Close with no change. Accessor functions for structure members would have to have names that differ from the name of the
member because a C++ class cannot contain a data member and a member function that have the same name. However,
choosing a name for accessors is problematic because of potential name clashes with other members. In addition, making
stylistic changes like this now would complicate the mapping without substantial gain.

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.

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

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.

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

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

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

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

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.

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

Close with no change. The proposal would weaken the safety of union mapping (after we struggled for ages to make it safe). In
addition, the proposal would force every union class to carry code for default-initialization of union members. While we have
this functionality in DynAny, I don't think it is appropriate to force this into the static stubs as well.

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

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

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

Close with no change. Adding a release() member to type Any would confuse the memory management issues further. There is
no point in having two API calls to achieve the same thing, and we can hardly deprecate the current one.

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++

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();

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>

Close with no change. The type code constants have been with us in their present form since the day dot, and changing these to
functions now would achieve nothing except break code.

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

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

Close with no change. The sequence buffer functions have been a round a long time, and were updated with the 2.2 spec.
Mucking around with these again will make matters worse instead of better.

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

Close with no change. The _var type usage is so entrenched now that to change the memory-management behavior would
break just about every C++ CORBA program in existence.

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*);

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

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.

Close with no change. It is clear that, by default, type Any makes a deep copy on insertion. In addition, consuming insertion is
possible too, so there is no issue.

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

.

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

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)

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"?

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

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

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); };

.

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.

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)

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.

Proposed Resolution:

Close with no change. True, double underscores technically invade the C++ compiler's namespace but, in practice, it is rarely
(never?) a problem.

Changing the IDL identifier rules to outlaw double underscore strikes me as a bit drastic too. (I'd rather not muck around in the
core unless we really have to.) Because I've never come across a case where this is a practical problem, we should close the
issue.

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.

Close with no change. It's ugly to have these name clashes in the mapping, but the steps required to fix this aren't pretty either,
and the name clash is rarely (never?) a problem in practice.

Summary: NVList has an item () operation, which returns a NamedValue reference. The same special memory management rules should apply to item().

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

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.

Close with no change. The fact that IDL doesn't have const operations doesn't mean that member functions in the C++
mapping can't be const. In addition, making this change now can cause code that currently works to no longer compile.

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.

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

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

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?

 closed issue

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

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.

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

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

Summary: Section 14.29: The C mapping for list_initial_services is incorrect and should return a pointer to a sequence (example in corresponding archive file)

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

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

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?

 transferred from port-rtf to cxx_revision

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

 closed issue, resolved

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

Summary: There seems to be nothing in the spec that specifies the name of the include files for things in the CORBA module (e.g. type definitions). Add such a requirement to each language mapping

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

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

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

Summary: Please find example/discussion in corresponding archive file

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)

Close as fixed. The relevant example text now appears on page 23-103 of 99-03-04.

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++?

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

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

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.

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

Summary: C++ mapping in CORBA 2.1 has a typo in the array mapping (section 18.15 page 18-33).Same typo appears in orbos/97-05-15 in section 16.12 page 16-33. It would be nice to actually show the C++ definitions for the types F, V, and M. Find details in corresponding file

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&".

 closed issue

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.
 
 
 

Close with no change. These functions are mapped following the normal C++ mapping rules. The proposed
change for adding helper functions to the CORBA module is too intrusive and is not deemed to be valuable enough to add.

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.
 
 

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.
 

 fixed

Summary: I think that there is a pervasive Typo in Appendix A of chapter 18.
 A number of the PIDL classes include a member function _duplicate.
 It should be declared as a static member function
 with an argument; i.e. the pointer to be "duplicated".
 

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.
 
 

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.
 
 
 
 

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 ?
 

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.
 

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 >>= ?
 

Close 932 without change. The core already states that optional strings in type codes are the empty string, so it
follows that extraction of such a string results in an empty string. The remainder of the issue was resolved with the definition of
TypeCode::equivalent().

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.
 

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?
 

Close no change. The needed widening can easily be achieved using the B_var::in() function like this: 

A_var av = A::_duplicate(bv.in());

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:
 

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 ">"
 

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.
 

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).
 

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.
 

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.
 

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.
 

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.
 

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?
 

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

 received issue

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?
 

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.
 

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.
 
 

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?
 

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.
 

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 ...
 

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.
 

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.
 

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.
 

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.
 

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.
 

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
 
 

Summary: Michi Henning & Steve Vinoski have previously challenged people to come
 up with a modification to the C++ language mapping that would allow for
 type safe widening of object reference _var types for assignment or copy
 construction.  I believe I have come up with the solution, and Michi
 agrees with me:
 
 Proposal:
 
 For object reference _var types, replace the copy and assignment
 operators:
 
 class T_var {
 public:
     ...
     T_var(const T_var &);
     
     T_var &operator = (const T_var &);
     ...
 };
 
 with:
 
 class T_var {
 public:
     ...
     template <class C_var>
     T_var(const C_var &cv) : ptr_(T::_duplicate(cv.in()) {
     }
     
     template <class C_var>
     T_var &operator = (const C_var &cv) {
 	if ((void *)this != (void *)cv) {
 	    CORBA::release(ptr_);
 	    ptr_ = T::_duplicate(cv.in());
 	}
 	return *this;
     }
     ...
 private:
     T_ptr	ptr_;
 };
 

deferred in June 2011 to the next RTF

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&".
 

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.
 
 

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_;
 }
 

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.
 
 

  Add a _narrow() operation to each POA servant class in the

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()?
 

 A { };

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

 received issue

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.

Close with no change. While the suggestion in the issue's archive would work, it would be too intrusive.

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.
 

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.
 

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.
 

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.
 
 

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

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

 received issue

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

Summary: There is no mention of PortableServer::ValueRefCountBase after this
 page.  It is not clear why values that also implement interfaces
 do not use the same reference counting scheme as other values.
 
 
 

deferred in June 2011 to the next RTF

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.
 

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.
 

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.
 
 
 

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.
 

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.
 

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".
 
 

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?
 

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.
 

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.
 
 

Summary: Section 20.9, page 20-28 of orbos/98-07-12 describes what types are
 considered variable-length. Since the new Fixed class has non-trivial
 constructors, it should also be a considered a variable-length type. Note
 that any fixed-length struct containing one cannot be statically initialized.
 

deferred in June 2011 to the next RTF

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.
 
 

:Environment

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.
 
 

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.
 
 

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.
 
 

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).
 

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

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?
 

Summary: What happens if I write
 
 	CORBA::Any a = ...;
 	const char *p;
 
 	a >>= p;
 
 and the type code in the Any indicates a *bounded* string? Does the extraction
 succeed or fail? The mapping doesn"t say.
 
 

deferred in June 2011 to the next RTF

Summary: The mapping right now offers Any::to_fixed to get a Fixed value out of an Any:
 
         to_fixed(Fixed &f, UShort d, UShort s);
 
 The spec doesn"t state what should happen if the digits and scale do
 not match what is in the type code. I believe extraction should fail in
 this case.
 

deferred in June 2011 to the next RTF

Summary: 
 The C++ mapping does not permit extraction of a Fixed from an Any
 in a generic way -- I must always specify matching digits and scale in
 order to call Any::to_fixed(). This is inconvenient if an application
 wants to deal with Fixed values generically (because Fixed is a generic
 type in C++ anyway).
 
 Proposal:
 
 	Add an overloaded >>= operator for extraction of Fixed from an Any. 
 	The operator sets the Fixed value to whatever scale and digits
 	are present in the type code.
 
 							Cheers,
 
 								Michi.
 
 
 

deferred in June 2011 to the next RTF

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
 

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;
  
 };
 

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...
 

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
 		//
 	};
 

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.
 

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.
 

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

Summary: The current C++ chapter for custom marshalled values on p. 20-94 lacks
 information about how one implements a custom value.
 The "Value Type Semantics" chapter in "ptc/98-10-06, 15 Oct. 98[REVIEW]"
 p. 5-11 says,
     " The implementer of a custom value type shall provide an
     implementation of the CustomMarshaller operations. The manner
     in which this [sic] done shall be specified for each language mapping..."
 

deferred in June 2011 to the next RTF

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.

Summary: In a number of places in the sample code for the C++ binding, the symbol
 _ptr is used as a member variable in _var types. In all of these the
 actual member is shown as private, so it is clear that actual
 implementations could use something else.
 
 The one exception to this is in section 20.10 on the Mapping for Struct
 Types. This discusses (without sample code) the mapping for string and
 object reference members of structs.

deferred in June 2011 to the next RTF

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.
 

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.
 

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?
 

Summary: We all know that the names of the C++ #include files generated from IDL are
 not standardized, and are thus the one remaining major source portability
 issue. One way to fix this would be to agree on some standard filenames,
 but we"ve tried this before and have never succeeded.
 
 Just thinking out loud here, but another way to fix it would be to agree on
 some standard macro names that applications could use to portably include
 the appropriate files. For example, define one macro for a client-side
 include and one macro for a server-side include, both taking the basename
 of the IDL file as an argument:
 
 #ifndef CORBA_CXX_CLIENT_INCLUDE
 #define CORBA_CXX_CLIENT_INCLUDE(base) <base ## Client.hh>
 #endif
 
 #ifndef CORBA_CXX_SERVER_INCLUDE
 #define CORBA_CXX_SERVER_INCLUDE(base) <base ## Server.hh>
 #endif
 
 Obviously, the exact definition of the macro would depend on the names of
 the generated files.
 
 I believe these could then be used portably in the client and server source
 code like this:
 
 #include CORBA_CXX_CLIENT_INCLUDE(file)
 
 With this approach, nobody has to change the names of the files they
 currently generate.
 

deferred in June 2011 to the next RTF

Summary: This may be a naive question, but it seems like the C++ mapping
 for value boxes is incomplete.  As far as I can tell, the specification
 defines the mapping for the following types:
 
   basic types, enum, objref, string, wstring, struct, union, sequence, array, fixed, any
 
 But what about the types that have not been mentioned?
 
   value, value box, TypeCode, Principal, native, except
 
 If these types aren"t allowed, does the specification say that somewhere?
 

deferred in June 2011 to the next RTF

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.
 
 

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.
 

Summary: The C++ mapping document (98-09-03, p. 108) states that "... the callee
 shall receive a copy of each valuetype argument passed to it even if the
 caller and callee are collocated in the same process."
 
 In the collocated case, should the ORB invoke _copy_value() to produce
 the copy?
 
 Since the user could implement _copy_value() to return a nil value, it
 seems unlikely that the ORB could rely on this mechanism.  However, a
 properly implemented _copy_value() would likely provide a significant
 speed improvement over marshalling and unmarshalling.
 
 

deferred in June 2011 to the next RTF

Summary: Section 20.21, "Argument Passing Considerations," says that for valuetypes:
      "The caller shall eventually invoked _remove_ref on the valuetype
 instance it receives back as either an inout, out, or return value."
 
 For memory management purposes, this is not sufficient in some cases.
 
 

deferred in June 2011 to the next RTF

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.
 

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
 
 

:Relationship is inherited by two distinct paths:

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.
 

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).
 

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.
 

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

 received issue

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. 
 

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."
 

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?
 

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.
 

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!
 

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.

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.
 
 

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.
 

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.
 
 

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?
 

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

Summary:  Value Boxes inherit from CORBA::ValueBase and
 must therefore implement get_value_def(), but
 cannot return a sensible value.
 

deferred in June 2011 to the next RTF

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

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

Close no change. AbstractBase is already defined in IDL as a native type. Some disagree with this definition, and it may change
in the future, but nevertheless it is workable for now. 

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.
 
 

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.
 

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.
 

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.
 

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.
 

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.
 

Summary: Consider the following IDL:
 
 ----------------------------------------------------------------------
 // IDL
 typedef long MyArray[1000000];
 
 interface I
 {
     void set_array(in MyArray array);
 };
 ----------------------------------------------------------------------
 
 Now let"s assume that I want to implement this using the DSI:
 
 ----------------------------------------------------------------------
 // C++
 void
 I_impl::invoke(ServerRequest_ptr request) throw()
 {
     String_var name = request -> op_name();
 
     if(strcmp(name, "set_array") == 0)
     {
 	NVList_ptr list;
 	orb -> create_list(0, list);
 
 	Any* any = list -> add(ARG_IN) -> value();
 
         XXX
 
 	request -> params(list);
 
 	MyArray_forany arg;
 	*any >>= arg;
 
 	... // Do something with arg;
 
 	return;
     }
     else
     {
         NVList_ptr list;
 	orb -> create_list(0, list);
 	request -> params(list);
 
 	Any* any = new Any;
 	*any <<= new BAD_OPERATION();
 	request -> exception(any);
     }
 }
 ----------------------------------------------------------------------
 
 At the line I marked with XXX, I have to set the TypeCode of the
 Any.

deferred in June 2011 to the next RTF

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;
 

Summary: The C++ language mapping chapter contains many blocks of IDL like stuff
 with the comment 
 
 // IDL
 
 in the first line, but the stuff in the block is not valid IDL for
 various reasons:
 
 (i) Uses "pseudo" as an apparent keyword.
 
 (ii) Contains declarations like
 
 	attribute exception exception;
 
 I suggest that the comment "// IDL" be replaced by "// Augmented IDL
 (see "Usage" on page x-y)" cross-referencing to section 20.23 Usage, so
 that people know for sure that this is not IDL.
 
 Furthermore, to make the claim in section 20.23 true, the declaration:
 
 	attribute exception exception;
 
 should be fixed to be something else, or alternatively, the exceptional
 use of exception should be called out as a specific augmentation of IDL
 in section 20.23.
 

deferred in June 2011 to the next RTF

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?
 

Summary: The ValueBase::_copy_value() function is included in the discussion
 of the "reference counting interface" in section 1.17.5 of 99-07-41.
 Later, the description of the reference counting mix-in classes
 says:
 
   "Each of these classes shall be fully concrete and shall completely
    fulfill the ValueBase reference counting interface..."
 
 However, I do not believe that the intent was to require the mix-in
 classes to implement _copy_value().
 
 Therefore I suggest one of two clarifications:
 
 1) Move the discussion of _copy_value() out of the reference-counting
     section, or
 
 2) Specify which functions the mix-in classes are actually expected to
     implement, e.g.,
 
     "Each of these classes shall be fully concrete and shall completely
      fulfill the ValueBase reference counting interface (_add_ref,
      _remove_ref, and _refcount_value), ..."