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

IDL4 to C++ Language Mapping — Open Issues

  • Acronym: IDL4-CPP
  • Issues Count: 15
  • 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

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


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