1. OMG Mailing List
  2. IDL to C++11 V1.4 (IDL2CPP11) Revision Task Force

All Issues

  • All Issues
  • Name: idl2cpp11-rtf
  • Issues Count: 80

Issues Summary

Key Issue Reported Fixed Disposition Status
CPP1114-12 Bullets before IDL::traits::narrow(ap) lost CPP11 1.3 CPP11 1.4 Resolved closed
CPP1114-9 OBV_Example constructor CPP11 1.3 CPP11 1.4 Resolved closed
CPP1114-8 Text alignment CPP11 1.3 CPP11 1.4 Resolved closed
CPP1114-7 Typo fixes CPP11 1.3b1 CPP11 1.4 Resolved closed
CPP1114-13 Only single argument constructors have to be explicit CPP11 1.3 CPP11 1.4 Closed; No Change closed
CPP1114-31 Add Delegation-Based Interface Implementation CPP11 1.3 CPP11 1.4 Resolved closed
CPP1114-29 Use C++11 using instead of typedef in all C++11 example code CPP11 1.3 CPP11 1.4 Resolved closed
CPP1114-14 Remove the setter operation for the discriminator of a union CPP11 1.3 CPP11 1.4 Resolved closed
CPP1114-5 Structure mapping change should be reverted CPP11 1.2 CPP11 1.4 Closed; No Change closed
CPP1114-6 Fixed is now broken CPP11 1.2 CPP11 1.4 Resolved closed
CPP1114-11 Reduce indent CPP11 1.3 CPP11 1.4 Resolved closed
CPP1114-10 Alignment _is_a and _non_existent CPP11 1.3 CPP11 1.4 Resolved closed
CPP1114-4 Errors in IDL Built-in Annotations Usage Table CPP11 1.2 CPP11 1.4 Closed; Out Of Scope closed
CPP1114-3 Make mapping of sequences more flexible CPP11 1.1 CPP11 1.4 Resolved closed
CPP1114-2 IDL2C++11 issue : CORBA dependency of the C++11 mapping CPP11 1.1 CPP11 1.4 Closed; Out Of Scope closed
CPP1114-1 In-place construction of structure types CPP11 1.0 CPP11 1.4 Closed; No Change closed
CPP1113-11 Errors in IDL Built-in Annotations Usage Table CPP11 1.2 CPP11 1.3 Deferred closed
CPP1113-7 Make mapping of sequences more flexible CPP11 1.1 CPP11 1.3 Deferred closed
CPP1113-6 IDL2C++11 issue : CORBA dependency of the C++11 mapping CPP11 1.1 CPP11 1.3 Deferred closed
CPP1113-5 In-place construction of structure types CPP11 1.0 CPP11 1.3 Deferred closed
CPP1113-10 Example C++ code in mapping for constants should use C++11 uniform initialization CPP11 1.2 CPP11 1.3 Resolved closed
CPP1113-13 Only a namespace level swap should be provided CPP11 1.2 CPP11 1.3 Resolved closed
CPP1113-8 CORBA::make_reference shouldn't explicitly imply perfect forwarding CPP11 1.2 CPP11 1.3 Resolved closed
CPP1113-4 Handle possible exception what conflict and improve Exception introduction text CPP11 1.2 CPP11 1.3 Resolved closed
CPP1113-3 Trivial grammatic fix in 6.14.1 CPP11 1.2 CPP11 1.3 Resolved closed
CPP1113-2 minor accessors of SystemException should use pass by value, minor should be uint32_t CPP11 1.2 CPP11 1.3 Resolved closed
CPP1113-1 IDL2C++11 mapping lacks support for the new IDL type map CPP11 1.1 CPP11 1.3 Resolved closed
CPP1113-9 Fix assignment operator of ColorValue CPP11 1.2 CPP11 1.3 Resolved closed
ITCR-39 Missing public specifier CPP11 1.1 CPP11 1.2 Resolved closed
ITCR-57 Fix unclarity in IDL Union description CPP11 1.1 CPP11 1.2 Resolved closed
ITCR-54 Update normative reference to point to CORBA 3.3 CPP11 1.1 CPP11 1.2 Resolved closed
ITCR-38 IDL2C++11 mapping lacks support for the new IDL type map CPP11 1.1 CPP11 1.2 Deferred closed
ITCR-28 Servant argument passing not precise enough CPP11 1.1 CPP11 1.2 Resolved closed
ITCR-44 Skeleton class as consistent template parameter for CORBA::servant_traits CPP11 1.1 CPP11 1.2 Closed; No Change closed
ITCR-43 abstract interfaces with corrected skeleton name CPP11 1.1 CPP11 1.2 Duplicate or Merged closed
ITCR-42 replace POA_B by adequate skeleton CPP11 1.1 CPP11 1.2 Resolved closed
ITCR-41 _this for skeleton, not for implementation CPP11 1.1 CPP11 1.2 Resolved closed
ITCR-19 fixed member types use incorrect type CPP11 1.1 CPP11 1.2 Resolved closed
ITCR-18 Destructor should just be virtual CPP11 1.1 CPP11 1.2 Resolved closed
ITCR-17 Mention move constructor with abstract CPP11 1.1 CPP11 1.2 Resolved closed
ITCR-16 usage of OBV trait should be improved CPP11 1.1 CPP11 1.2 Resolved closed
ITCR-15 Move constructor of ValueBase incorrect CPP11 1.1 CPP11 1.2 Resolved closed
ITCR-14 Missing move assignment operator in class ColorValue CPP11 1.1 CPP11 1.2 Resolved closed
ITCR-12 Clarify valuetype factory mapping CPP11 1.1 CPP11 1.2 Resolved closed
ITCR-11 Valuebox should also have swap support CPP11 1.1 CPP11 1.2 Closed; No Change closed
ITCR-10 Add missing default initialization for valuetypes CPP11 1.1 CPP11 1.2 Resolved closed
ITCR-9 wrong return type for Foo::some_function() CPP11 1.1 CPP11 1.2 Resolved closed
ITCR-8 provide unique class name as mapping of PortableServer::Servant CPP11 1.1 CPP11 1.2 Duplicate or Merged closed
ITCR-7 Constructor declarations in Servant code are wrong CPP11 1.1 CPP11 1.2 Resolved closed
ITCR-6 Destructors of strong reference types should be public CPP11 1.1 CPP11 1.2 Resolved closed
ITCR-5 Question on unions default member CPP11 1.1 CPP11 1.2 Resolved closed
ITCR-4 Code fragment should use skel class CPP11 1.0 CPP11 1.2 Closed; No Change closed
ITCR-3 Errors on code snippet related to skeleton classes CPP11 1.0 CPP11 1.2 Resolved closed
ITCR-1 In-place construction of structure types CPP11 1.0 CPP11 1.2 Deferred closed
ITCR-13 Make mapping of sequences more flexible CPP11 1.1 CPP11 1.2 Deferred closed
ITCR-2 IDL2C++11 issue : CORBA dependency of the C++11 mapping CPP11 1.1 CPP11 1.2 Deferred closed
CPP1111-24 Remove user defined literal support CPP11 1.0 CPP11 1.1 Resolved closed
CPP1111-23 Add namespace level swap CPP11 1.0 CPP11 1.1 Resolved closed
CPP1111-22 Relax constructor argument rules CPP11 1.0 CPP11 1.1 Resolved closed
CPP1111-21 Remove final for structured types CPP11 1.0 CPP11 1.1 Resolved closed
CPP1111-20 Small typos in servant reference section CPP11 1.0 CPP11 1.1 Resolved closed
CPP1111-19 Replace all _downcase/downcase with narrow CPP11 1.0 CPP11 1.1 Resolved closed
CPP1111-18 Introduce trait for local interface base type CPP11 1.0 CPP11 1.1 Resolved closed
CPP1111-17 Use () instead of (void) CPP11 1.0 CPP11 1.1 Resolved closed
CPP1111-16 Minor typos CPP11 1.0 CPP11 1.1 Resolved closed
CPP1111-15 CORBA::Exception should not use std::string type for name and repo_id CPP11 1.0 CPP11 1.1 Resolved closed
CPP1111-14 Early detection of bound violation on bounded types CPP11 1.0 CPP11 1.1 Resolved closed
CPP1111-13 std::ostream insertion underspecified CPP11 1.0 CPP11 1.1 Resolved closed
CPP1111-12 Missing specification of assignment operators of valuetypes CPP11 1.0b2 CPP11 1.1 Resolved closed
CPP1111-11 Meaning of (u)intN_t types unclear CPP11 1.0b2 CPP11 1.1 Resolved closed
CPP1111-10 Fixed type mapping should provide (explicit) operator bool CPP11 1.0b2 CPP11 1.1 Resolved closed
CPP1111-9 Invalid struct initialization example CPP11 1.0b2 CPP11 1.1 Resolved closed
CPP1111-8 Remove _narrow methods CPP11 1.0b2 CPP11 1.1 Resolved closed
CPP1111-7 Extend IDL type traits for template meta programming CPP11 1.0b2 CPP11 1.1 Resolved closed
CPP1111-6 Font issue CPP11 1.0b2 CPP11 1.1 Resolved closed
CPP1111-5 Add missing implicit widening to any CPP11 1.0b2 CPP11 1.1 Resolved closed
CPP1111-4 Add support for _this on local objects CPP11 1.0b2 CPP11 1.1 Resolved closed
CPP1111-3 Lack of factory reference type CPP11 1.0b2 CPP11 1.1 Resolved closed
CPP1111-2 typo exists in section 6.21 CPP11 1.0b2 CPP11 1.1 Resolved closed
CPP1111-1 RFP requirement on DDS-PSM-Cxx compatibility is violated CPP11 1.0b2 CPP11 1.1 Resolved closed

Issues Descriptions

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

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

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

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

    Make part of 6.7.6 a bulleted list

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

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

OBV_Example constructor

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

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

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

    Update OBV_Example class in 6.18.4

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

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

Text alignment

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

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

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

    Fix C++ code in 6.18.4

    Fixing a minor typo/formatting bug in this section.

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

Typo fixes

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

    Section 6.11 on page 11, 2nd paragraph:

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

    obligation

    Table 6.10 on page 14, bottom row, right column

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

    [...] dimensions of the array

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

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

    explicit ColorValue(Color);

    Section 6.19.1 on page 34, code for class AbstractBase

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

    AbstractBase(const AbstractBase&);

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

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

    Type of index argument should be uint32_t.

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

    Fix typos

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

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

Only single argument constructors have to be explicit

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

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

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

    Reporter of the Issue has asked for it to be withdrawn

    Closing this one by request of Reporter.

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

Add Delegation-Based Interface Implementation

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

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

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

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

    Mapping for implementing interfaces via delegation

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

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

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

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

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

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

    Use the C++11 type alias feature in examples

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

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

Remove the setter operation for the discriminator of a union

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

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

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

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

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

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

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

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

Structure mapping change should be reverted

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

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

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

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

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

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

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

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

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

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

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

Fixed is now broken

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

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

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

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

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

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

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

    Updates to the mapping of the IDL Fixed data type

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

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

Reduce indent

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

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

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

    Update source code formatting

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

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

Alignment _is_a and _non_existent

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

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

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

    Update code in 6.26.2

    Minor formatting change as suggested.

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

Errors in IDL Built-in Annotations Usage Table

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

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

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

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

    Issue was added to the wrong RTF

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

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

Make mapping of sequences more flexible

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

    In 6.12 we define:

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

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

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

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

    Flexible mapping for sequence and map types

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

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

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

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

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

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

    IDL v4 is a standalone specification

    This specification has no normative reference for IDL v4.

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

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

In-place construction of structure types

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

    There are two main motivations:

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

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

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

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

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

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

    Existing alternatives for struct construction appear to be sufficient

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

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

Errors in IDL Built-in Annotations Usage Table

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

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

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

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

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

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

Make mapping of sequences more flexible

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

    In 6.12 we define:

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

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

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

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

    Deferred

    Deferred

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

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

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

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

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

    Deferred

    Deferred to future RTF

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

In-place construction of structure types

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

    There are two main motivations:

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

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

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

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

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

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

    Deferred

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

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

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

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

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

    Should be
    const std::string name

    {"testing"}

    ;
    static constexpr float pi

    {3.14159}

    ;

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

    IDL constants should use C++ direct list initializaiton

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

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

Only a namespace level swap should be provided

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

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

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

    Remove std::swap requirement

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

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

CORBA::make_reference shouldn't explicitly imply perfect forwarding

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

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

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

    Relax requirement for perfect forwarding in 6.7.1

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

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

Handle possible exception what conflict and improve Exception introduction text

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

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

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

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

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

    Possible name conflict involving "what" and exceptions.

    See Johnny's comment on issue #4

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

Trivial grammatic fix in 6.14.1

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

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

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

    This should be

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

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

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

    Edit section 6.14.1 for clarity

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

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

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

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

    For SystemException class on page 36 mentions

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

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

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

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

    const CompletionStatus completed() const;

    to

    CompletionStatus completed() const;

    As last the constructor

    explicit SystemException(int32_t minor, CompletionStatus status);

    Should be

    SystemException(uint32_t minor, CompletionStatus status);

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

    SystemException updates

    Proposed resolution is included in Issue #2 description

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

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

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

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

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

    Import the mapping of IDL Map from XTypes 1.2

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

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

Fix assignment operator of ColorValue

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

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

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

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

    Fix argument type of copy assignment operator in 6.18.7.2

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

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

Missing public specifier

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

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

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

    Add missing public specifier

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

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

Fix unclarity in IDL Union description

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

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

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

    Clarify discriminant

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

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

Update normative reference to point to CORBA 3.3

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

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

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

    Update reference

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

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

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

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

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

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

    Defer to future RTF

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

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

Servant argument passing not precise enough

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

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

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

    Servant argument passing not precise enough

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

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

Skeleton class as consistent template parameter for CORBA::servant_traits

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

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

    Rationale:

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

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

    instead of

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

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

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

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

    instead of

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

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

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

    like

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

    instead of

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

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

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

    like

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

    instead of

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

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

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

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

    Keep referring to A instead of A_skel

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

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

abstract interfaces with corrected skeleton name

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

    § 6.26.6, to the end, about abstract interfaces:

    I guess the C++ snippet should be like

    // C++
    class A

    { ... }

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

    { ... }

    ;

    dropping the old POA_B thing.

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

    Duplicated issue

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

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

replace POA_B by adequate skeleton

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

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

    // C++
    class A

    { ... }

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

    { ... }

    ;

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

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

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

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

_this for skeleton, not for implementation

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

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

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

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

    Correct code example for _this

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

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

fixed member types use incorrect type

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

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

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

    Replace uint32_t with uint16_t as proposed

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

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

Destructor should just be virtual

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

    for 6.19.1 to the bullet list mentions

    a protected pure virtual destructor

    This should be

    a protected virtual destructor

    it is not pure, see the example later on

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

    Make destructor just virtual

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

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

Mention move constructor with abstract

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

    for 6.19.1 to the bullet list should be added

    a protected move constructor

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

    Correct constructors of AbstractBase

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

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

usage of OBV trait should be improved

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

    The specicification currently lists:

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

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

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

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

    Correct usage of OBV trait

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

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

Move constructor of ValueBase incorrect

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

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

    ValueBase(ValueBase&&);

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

    Correct move constructor of ValueBase

    Proposal is to accept the changed as made by submitter

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

Missing move assignment operator in class ColorValue

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

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

    ColorValue(& operator= (ColorValue(&&)

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

    Correct provided signature for valuebox types

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

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

Clarify valuetype factory mapping

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

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

    Ref devportal 3617

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

    Clarify valuetype factory mapping

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

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

Valuebox should also have swap support

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

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

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

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

    Valueboxes should have swap support

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

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

Add missing default initialization for valuetypes

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

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

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

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

    Add missing behavior of the default constructor

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

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

wrong return type for Foo::some_function()

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

    The return type should be

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

    instead of

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

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

    Correct return type of example method

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

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

provide unique class name as mapping of PortableServer::Servant

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

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

    Throughout this chapter Servant should be used unambiguously.

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

    Provide correct mapping for Servant

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

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

Constructor declarations in Servant code are wrong

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

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

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

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

    Correct constructor declarations of Servant

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

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

Destructors of strong reference types should be public

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

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

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

    Destructor of reference types should be public

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

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

Question on unions default member

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

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

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

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

    Improve description of union

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

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

Code fragment should use skel class

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



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

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

    Code fragment should use skel class

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

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

Errors on code snippet related to skeleton classes

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

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

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

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

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

    Correct skeleton inheritance

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

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

In-place construction of structure types

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

    There are two main motivations:

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

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

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

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

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

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

    Defer to future RTF

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

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

Make mapping of sequences more flexible

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

    In 6.12 we define:

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

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

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

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

    Defer to future RTF

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

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

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

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

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

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

    Defer to future RTF

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

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

Remove user defined literal support

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

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

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

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

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

Add namespace level swap

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

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

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

    Accepting this issue as proposed

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

Relax constructor argument rules

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

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

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

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

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

Remove final for structured types

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

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

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

    Accepting this issue as proposed

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

Small typos in servant reference section

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

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

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

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

    Change text as proposed

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

Replace all _downcase/downcase with narrow

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

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

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

    Accepting this issue as proposed

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

Introduce trait for local interface base type

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

    The specification uses IDL::traits<T> for everything related to interface T, but for a local interface we just use T as base class. Proposal is to use IDL::traits<T>::base_type as base type trait for the local object implementation. This makes everything related to interfaces available through IDL::traits<T>

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

    Accepting this issue as proposed

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

Use () instead of (void)

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

    The specification uses in some examples like in 6.13.1 the construct "(void)" for a method with no arguments. This is old style, it should use "()"

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

    Accepting this issue as proposed

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

Minor typos

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

    2.1 refers to ISO/IEC 14822:2011 (which should be 14882:2011)

    6.30 instead refers to ISO/IEC 14882:011 (again should be 14882:2011)

    the table in 6.30 contains typos (alinas, alineof, constrexpr), names
    that aren't keywords (int32_t, ...) and misses some keywords
    (noexcept, char16_t, char32_t).

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

    Accepting this issue as proposed

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

CORBA::Exception should not use std::string type for name and repo_id

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

    CORBA::Exception should not use std::string type for name and repo_id for 2 reasons:

    1. C++ standard conformance; member types like std::string are discouraged because their constructors may throw exceptions where std::exception and derivatives are expected not to throw exceptions themselves
    2. (minor) performance; using std::string these member values are unnecessarily copied while they immutable constant strings only ever read, never mutated

    Changing the members to const char* values makes CORBA::Exception and the CORBA::SystemException classes optimal and c++ standard conformant.

    This will not be the case for CORBA::UserException derivatives as these may have IDL defined attributes having IDL defined types which may definitely throw exceptions. However the ORB should be expected to handle situations where creating user exceptions unexpectedly throws another exception.

    Refs #2958

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

    Update exception as proposed. During the discussion also it was proposed to define
    what() as noexcept which also has been done

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

Early detection of bound violation on bounded types

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

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

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

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

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

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

    The section quoted above could thus be extended as follows:

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

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

    Example:

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

    { string_arr_t sarr; string_seq_t sseq; }

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

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

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

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

std::ostream insertion underspecified

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

    The wording in 6.29 says

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

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

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

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

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

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

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

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

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

    { return os; }


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


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


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


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

    }

    int main()

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

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

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

    2) The second part of above wording,

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

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

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

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

    int main()

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

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

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

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

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

Missing specification of assignment operators of valuetypes

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

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

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

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

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

    Accepting this issue as proposed

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

Meaning of (u)intN_t types unclear

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

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

    int16_t int32_t int64_t uint16_t uint32_t uint64_t uint8_t

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

    int16_t int32_t int64_t uint16_t uint32_t uint64_t uint8_t

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

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

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

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

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

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

    Accepting this issue as proposed

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

Fixed type mapping should provide (explicit) operator bool

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

    Given the specification of the class template Fixed provides

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

    and

    bool operator!() const;

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

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

    { ... }


    But the similar inverse form


    if (f) { ... }

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

    if (!!f)

    { ... }

    to realize the same thing. This is unfortunate and there is a simple means to solve this problem: The specification should add

    explicit operator bool() const;

    to the class template synopsis with the same semantics as negating operator!

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

    Accepting this issue as proposed. Also during the discussion it was proposed to add a
    namespace level to_string

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

Invalid struct initialization example

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

    The example in the middle of the page starts with:

    // C++
    S s =

    {10};


    but the struct mapping (6.13.1 p.23) clearly says that "an explicit constructor accepting values for struct each member" shall be provided. Above initialization context is a copy-initialization context and would require a non-explicit constructor. The example should be fixed to use a direct-initialization context instead, either:


    // C++
    S s{10}

    ;

    or

    // C++
    S s = S

    {10}

    ;

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

    Accepting this issue as proposed

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

Remove _narrow methods

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

    Given interface T the specification defines IDL::traits<T>::narrow as a way to narrow to T. As convenience it also defined T::_narrow. The issue is that T::_narrow is implicitly linked to IDL::traits<T>::narrow and can cause confusion and possible misuse when other traits are added for more specific traits. We propose to remove T::_narrow from the specification completely, users must just use IDL::traits<T>::narrow

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

    Accepting this issue as proposed

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

Extend IDL type traits for template meta programming

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

    The specification defines IDL::traits<> as type trait, but uses it only for reference types.

    We propose to extend IDL::traits<> as generic type trait for IDL2C++11. This type trait delivers traits with information coming from IDL.

    For example object reference traits it can also deliver local and abstract as traits, which are booleans that indicate whether the IDL type was local or abstract.

    For sequence we can add traits indicating the type of the element and in case of bounded sequences the bound.

    The proposal is to add a new paragraph which describes the IDL type traits that are all available as part of IDL::traits<> for a specific IDL type.

    Ref #2802

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

    Extending the IDL::traits<> with more types for template meta programming will be useful
    for the users that would like to program C++11 templates using the IDL defined types.
    Therefor a new set of type traits will be added to the specification.

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

Font issue

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

    In section 6.25.6, in the line:

    This guarantees that the POA skeleton class inherits only one version of each operation, and also allows optional
    inheritance of implementations. In this example, the implementation of interface B reuses the implementation of interface
    A:

    The font of A should also be IDL type just as B

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

    Accepting this addition as proposed

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

Add missing implicit widening to any

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

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

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

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

    Refs #2873

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

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

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

Add support for _this on local objects

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

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

    Proposal is to add to 6.24:

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

    In the code part add as method

    class LocalIF

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

    ;
    Refs #2804

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

    Accepting this addition as proposed

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

Lack of factory reference type

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

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

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

    Refs #2727

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

    Accepting this addition as proposed

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

typo exists in section 6.21

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

    The following typo error exists in section 6.21:

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

    Refs #2877

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

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

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

RFP requirement on DDS-PSM-Cxx compatibility is violated

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

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

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

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

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