IDL4 to C++ Language Mapping Avatar
  1. OMG Specification

IDL4 to C++ Language Mapping — Open Issues

  • Acronym: IDL4-CPP
  • Issues Count: 18
  • Description: Issues not resolved
Open Closed All
Issues not resolved

Issues Descriptions

Bitmask mapping

  • Key: IDL4CPP-11
  • Status: open   Implementation work Blocked
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The bitmask mapping allows misuse and is not really a modern API. At least for the users who map a struct to a class the bitmask mapping could for example use a strong enum (mappping now two bitmasks with the same member name will result in non compiling C++ code), but provide the operators ~, |, &, ^, |=, &=, and ^= to make it safe.

  • Reported: IDL4-CPP 1.0b1 — Mon, 31 Jul 2023 11:42 GMT
  • Updated: Mon, 2 Oct 2023 17:15 GMT

a_short in example code

  • Key: IDL4CPP-5
  • Status: open  
  • Source: Remedy IT Expertise BV ( Johnny Willemsen)
  • Summary:

    In the example code it lists
    const int16_t& a_short()

    {...}
    but shouldn't that be
    int16_t a_short() const {...}

    This should be a return by value, using `const int16_t` will lead to a compiler warning, so it should be 'int16_t', all accessors should be checked

  • Reported: IDL4-CPP 1.0b1 — Thu, 23 Mar 2023 14:10 GMT
  • Updated: Wed, 27 Sep 2023 05:54 GMT

bitset mapping

  • Key: IDL4CPP-10
  • Status: open   Implementation work Blocked
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    For anyone using the class mapping of a structure the spec should also provide a class mapping for a bitset, that way they have a consistent API. Also why is a inherited bitset not mapped to C++ inheritance, by removing the inheritance the inheritance relation can't be used in C++ also

  • Reported: IDL4-CPP 1.0b1 — Mon, 31 Jul 2023 11:36 GMT
  • Updated: Wed, 27 Sep 2023 05:52 GMT

Add bit_bound/underlying_type for enum

  • Key: IDL4CPP-13
  • Status: open  
  • Source: Remedy IT Expertise BV ( Johnny Willemsen)
  • Summary:

    The bit_bound annotation can also be applied to an enum, so add bit_bound/underlying_type also to the enum traits

  • Reported: IDL4-CPP 1.0b1 — Sat, 5 Aug 2023 14:49 GMT
  • Updated: Tue, 26 Sep 2023 22:33 GMT

@value annotation does not fully specify its behavior

  • Key: IDL4CPP-9
  • Status: open  
  • Source: Real-Time Innovations ( Fernando Garcia-Aranda)
  • Summary:

    The @value annotation does not fully specify the behavior. That includes:

    • The behavior for unannotated values.
    • The behavior for repeated values. Is it possible like in C++?

    DDS-XTYPES does specify the behavior of @value and such description should be added to IDL:

    7.3.1.2.1.5 Enumerated Literal Values
    Prior to this specification, it was impossible to indicate that objects of enumerated types could be stored using an integer size other than 32 bits. This specification uses the @bit_bound annotation defined in Sub Clause 8.3.4.1 of [IDL] for this purpose.

    It is important to note that the value member of the annotation may take any value from 1 to 32, inclusive, when this annotation is applied to an enumerated type. Furthermore, prior to this specification, it was impossible to provide an explicit value for an enumerated literal. The value was always inferred based on the definition order of the literals. That behavior is still supported. However, additionally, this specification allows enumerated literals to be given explicit custom values, just as they can be in the C and C++ programming
    languages. This can be done by means of the @value annotation defined in Sub Clause 8.3.1.5 of [IDL], which may be applied to individual literals.
    It is permitted for some literals in an enumerated type to bear the @value annotation while others do not. In such cases, as in C and C++ enumerations, implicit values are assigned in a progression starting from the most-recently specified value (or an implicit value of zero for the first literal, if there is no previous specified value) and adding one with each successive literal.

  • Reported: IDL4-CPP 1.0a1 — Tue, 20 Jun 2023 17:54 GMT
  • Updated: Tue, 26 Sep 2023 21:36 GMT

Use of @range is inconsistent with IDL4 grammar

  • Key: IDL4CPP-8
  • Status: open  
  • Source: Real-Time Innovations ( Fernando Garcia-Aranda)
  • Summary:

    According to IDL4, annotations like range need to specify the arguments that are set. However, in the example we include for the mapping of @range we don't specify min and max in the arguments.

    We need to address that as follows:

    struct StructureOfRangedValues {
        @range(min=-10, max=10) long x;
    };
    
  • Reported: IDL4-CPP 1.0a1 — Tue, 20 Jun 2023 17:54 GMT
  • Updated: Tue, 26 Sep 2023 21:34 GMT

Specify bounds checking

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

    Reporting this for bounded sequences, but very likely this has to be addressed for all bounded types. The spec says "NOTEā€”In any case, bound checking on bounded sequences may be performed at serialization time, raising an
    exception or reporting an error if necessary", but this should be more strict to my idea, the bounds check must be performed, and the spec should specify which exception is raised when the bound is not respected

  • Reported: IDL4-CPP 1.0b1 — Sat, 25 Mar 2023 10:41 GMT
  • Updated: Tue, 26 Sep 2023 21:32 GMT

Destructors should be override instead of virtual

  • Key: IDL4CPP-6
  • Status: open  
  • Source: Remedy IT Expertise BV ( Johnny Willemsen)
  • Summary:

    In the example code the destructors in classes that derive from a base should be marked override, not virtual, this applies to

    • 6.18.4: Change "virtual ~Example();" to "~Example() override;" and "virtual ~OBV_Example();" to "~OBV_Example() override;"
    • 6.20: Change "virtual ~Exception();" to "~Exception() override;" and "virtual ~SystemException();" to "~SystemException() override;"
    • 6.25: Change "virtual ~MyLocalIF();" to "~MyLocalIF() override;"
    • 6.26.6: Change "virtual ~A_skel ();" to "~A_skel () override;" and "virtual ~A_impl ();" to "~A_impl () override;"
    • 6.26.8: Change "virtual ~TIE() = default;" to "~TIE() override = default;"
  • Reported: IDL4-CPP 1.0b1 — Thu, 23 Mar 2023 14:18 GMT
  • Updated: Tue, 26 Sep 2023 21:27 GMT

Mapping to string_view

  • Key: IDL4CPP-4
  • Status: open  
  • Source: Remedy IT Expertise BV ( Johnny Willemsen)
  • Summary:

    As there is no conversion implicit from a std::string_view to a std::string there is no possibility to easily pass now a IDL defined string to an operation expecting an IDL string input, will this mapping proposal work for the users?

  • Reported: IDL4-CPP 1.0b1 — Thu, 23 Mar 2023 14:06 GMT
  • Updated: Tue, 26 Sep 2023 21:19 GMT

bound type

  • Key: IDL4CPP-3
  • Status: open  
  • Source: Remedy IT Expertise BV ( Johnny Willemsen)
  • Summary:

    This mapping defines the bound as std::integral_constant<size_t, b> but in most compilers size_t is 64bit where sequences/strings are bound to 32bit by IDL, so shouldn't size_t be replaced by uint32_t. If this is changed here, also check all other size_t types in this mapping

  • Reported: IDL4-CPP 1.0b1 — Thu, 23 Mar 2023 14:04 GMT
  • Updated: Tue, 26 Sep 2023 20:49 GMT

Availability of IDL Type traits for anonymous types

  • Key: IDL4CPP-2
  • Status: open  
  • Source: Remedy IT Expertise BV ( Johnny Willemsen)
  • Summary:

    This new spec seems to try to support anonymous types (at least it doesn't disallow them like IDL to C++11), but how are then the type traits provided for anonymous types. For example the type

    struct TopicA

    { sequence<long, 5> l5s; }

    ;

    Is there a way for the user to get the IDL traits for bound/is_bounded for the l5s member? If that is not possible for anonymous types this language mapping should make that clear, that anonymous types don't have a type trait.

  • Reported: IDL4-CPP 1.0b1 — Thu, 23 Mar 2023 14:02 GMT
  • Updated: Tue, 26 Sep 2023 19:46 GMT

Specify how IDL maps compare their keys

  • Key: IDL4CPP-1
  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Adam Mitz)
  • Summary:

    Keys of maps can be any IDL type. How should the generated C++ code support key comparison of any type?

  • Reported: IDL4-CPP 1.0a1 — Tue, 21 Mar 2023 17:53 GMT
  • Updated: Tue, 26 Sep 2023 19:10 GMT


Clarify constructor

  • Key: IDL4CPP-15
  • Status: open  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The spec says " In addition to the methods as described in 6.14, the class has an explicit constructor accepting values for each struct member in the order they are specified in IDL.", all values should be by value, so better it is to day " In addition to the methods as described in 6.14, the class has an explicit constructor accepting values for each struct member by value in the order they are specified in IDL."

  • Reported: IDL4-CPP 1.0b1 — Mon, 14 Aug 2023 14:46 GMT
  • Updated: Wed, 23 Aug 2023 20:18 GMT

underlying_type traits

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

    The underlying_type traits is maybe something to remove, std::underlying_type does the same at the moment bitmask is implemented using an enum. Also I am doubting whether an enum or enum class is the best mapping, have you tried to implement some user code, there is no operator bool() for example, some for checking if a bit is set we always have to cast. Maybe mapping to a class with operator is easier for the user, or use an enum class with operators.

  • Reported: IDL4-CPP 1.0b1 — Mon, 7 Aug 2023 11:21 GMT
  • Updated: Tue, 8 Aug 2023 17:56 GMT

Alternative struct mapping not complete

  • Key: IDL4CPP-12
  • Status: open   Implementation work Blocked
  • Source: Remedy IT Expertise BV ( Johnny Willemsen)
  • Summary:

    The mapping for alternative struct mapping is lacking the constructors, member initialization, non-const accessors, description of how it works when using IDL4 struct inheritance, etc, see the IDL to C++11 language mapping for a full description

  • Reported: IDL4-CPP 1.0b1 — Thu, 3 Aug 2023 07:30 GMT
  • Updated: Thu, 3 Aug 2023 17:09 GMT

Problem with member accessor

  • Status: open  
  • Source: Remedy IT Expertise BV ( Johnny Willemsen)
  • Summary:

    The spec gives:

    const <MemberType>& <MemberName>() const

    But for basic types/int this will result in a warning, for basic/enum it should be

    <MemberType> <MemberName>() const

  • Reported: IDL4-CPP 1.0b1 — Tue, 4 Apr 2023 07:47 GMT
  • Updated: Tue, 4 Apr 2023 19:11 GMT

Spec should specify behaviour

  • Status: open  
  • Source: Remedy IT Expertise BV ( Johnny Willemsen)
  • Summary:

    The spec says:

    A public constant accessor method with the name of the union member that returns a constant reference to
    its value:
    const <MemberType>& <MemberName>() const;
    Accessing an invalid union member may result in an undefined error.

    A language mapping should be precise and very clear to my idea, the user should know what happens if an invalid union member is accessed, this could happen in some cases, the spec should specify which exception will be thrown so that the programmer can react on this, saying it is undefined is not enough.

  • Reported: IDL4-CPP 1.0b1 — Wed, 29 Mar 2023 07:50 GMT
  • Updated: Fri, 31 Mar 2023 18:26 GMT