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

IDL to C++11 Language Mapping — All Issues

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

Issues Descriptions

Add mapping for @optional

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

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

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

    Map optional struct members

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

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

Impact of @final on union/struct mapping

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

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

    struct Foo final {}

    or

    struct Foo {}

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

    Extensibility annotations do not impact the language mapping

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

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

Add IDL::traits<>::bit_bound

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

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

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

    Add traits member specification to Bit Masks section

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

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

Invalid constructor in example code

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

    The example code has

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

    But this is not correct, it should be

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

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

    Fix invalid example code

    A closing parenthesis was missing from the example code.

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

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

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

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

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

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

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

    Move make_reference into the traits class

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

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

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

  • Key: CPP1116-15
  • Status: closed  
  • Source: Leonardo S.p.A ( Simon McQueen)
  • Summary:

    Page footers look like:

    C++11 Language Mapping, v1.4 iii

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

    This issue is a duplicate of issue 5

    Apols for not checking before raising.

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

Struct inheritance mapping strange

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

    The spec says the following:

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

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

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

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

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

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

    Update struct inheritance mapping

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

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

Incorrect footer

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

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

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

    No RTF change needed

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

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

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

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

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

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

    enum MyBitMaskBits : std::uint8_t

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

    ;

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

    Update bitmask IDL traits

    Update IDL traits for bitmask types.

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

Remove std namespace from example code

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

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

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

    Duplicates issue 8

    Duplicate of issue 8

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

Why not map bitset inheritance to struct inheritance

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

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

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

    No change needed

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

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

Missing override

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

    The destructor should change from

    virtual ~V_factory();

    to

    ~V_factory() override;

    The virtual is redundant, that is already in the base

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

    Update the code in 6.18.10.2

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

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

Remove std namespace from example code

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

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

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

    No change needed

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

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

Missing override

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

    In the example code the destructor should change from

    virtual ~ColorValue();

    to

    ~ColorValue() override;

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

    Update the code in 6.18.7.2

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

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

Annotation for union discriminator name

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

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

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

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

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

    Depends on an IDL spec change

    Defer until the IDL 4.3 RTF resolves IDL43-42.

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