IDL to C++11 Language Mapping Avatar
  1. OMG Specification

IDL to C++11 Language Mapping — All Issues

  • Acronym: CPP11
  • Issues Count: 11
  • Description: All Issues
Open Closed All
All Issues

Issues Descriptions

Errors in IDL Built-in Annotations Usage Table

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

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

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

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

    Issue was added to the wrong RTF

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

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

Structure mapping change should be reverted

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

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

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

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

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

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

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

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

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

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

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

Fixed is now broken

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

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

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

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

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

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

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

    Updates to the mapping of the IDL Fixed data type

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

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

Errors in IDL Built-in Annotations Usage Table

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

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

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

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

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

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

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

Fix assignment operator of ColorValue

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

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

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

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

    Fix argument type of copy assignment operator in 6.18.7.2

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

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

CORBA::make_reference shouldn't explicitly imply perfect forwarding

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

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

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

    Relax requirement for perfect forwarding in 6.7.1

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

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

Handle possible exception what conflict and improve Exception introduction text

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

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

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

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

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

    Possible name conflict involving "what" and exceptions.

    See Johnny's comment on issue #4

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

Trivial grammatic fix in 6.14.1

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

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

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

    This should be

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

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

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

    Edit section 6.14.1 for clarity

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

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

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

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

    For SystemException class on page 36 mentions

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

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

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

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

    const CompletionStatus completed() const;

    to

    CompletionStatus completed() const;

    As last the constructor

    explicit SystemException(int32_t minor, CompletionStatus status);

    Should be

    SystemException(uint32_t minor, CompletionStatus status);

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

    SystemException updates

    Proposed resolution is included in Issue #2 description

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

Only a namespace level swap should be provided

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

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

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

    Remove std::swap requirement

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

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