IDL4 to CPP Language Mapping Avatar
  1. OMG Specification

IDL4 to CPP Language Mapping — Closed Issues

  • Acronym: IDL4-CPP
  • Issues Count: 51
  • Description: Issues resolved by a task force and approved by Board
Closed All
Issues resolved by a task force and approved by Board

Issues Summary

Key Issue Reported Fixed Disposition Status
IDL4CPP-45 int8/uint8 mapping IDL4-CPP 1.0b1 IDL4-CPP 1.0b2 Closed; No Change closed
IDL4CPP-11 Bitmask mapping IDL4-CPP 1.0b1 IDL4-CPP 1.0b2 Resolved closed
IDL4CPP-12 Alternative struct mapping not complete IDL4-CPP 1.0b1 IDL4-CPP 1.0b2 Resolved closed
IDL4CPP-53 The text in the C++ mapping document for bitmasks appears to contradict the text in the IDL4 specification. IDL4-CPP 1.0a1 IDL4-CPP 1.0b2 Closed; No Change closed
IDL4CPP-36 Issue with mapping of bounded string and traits IDL4-CPP 1.0b1 IDL4-CPP 1.0b2 Resolved closed
IDL4CPP-38 what argument of exception constructor? IDL4-CPP 1.0b1 IDL4-CPP 1.0b2 Resolved closed
IDL4CPP-52 Typo fixes IDL4-CPP 1.0b1 IDL4-CPP 1.0b2 Resolved closed
IDL4CPP-13 Add bit_bound/underlying_type for enum IDL4-CPP 1.0b1 IDL4-CPP 1.0b2 Resolved closed
IDL4CPP-51 Bitmask chapter should describe argument passing rules IDL4-CPP 1.0b1 IDL4-CPP 1.0b2 Closed; No Change closed
IDL4CPP-30 @default on string and wstring? IDL4-CPP 1.0a1 IDL4-CPP 1.0b2 Closed; No Change closed
IDL4CPP-87 No type from omg::types available for arrays IDL4-CPP 1.0b1 IDL4-CPP 1.0b2 Resolved closed
IDL4CPP-85 Mapping of constants within an interface not correct, not compilable C++ code IDL4-CPP 1.0b1 IDL4-CPP 1.0b2 Resolved closed
IDL4CPP-10 bitset mapping IDL4-CPP 1.0b1 IDL4-CPP 1.0b2 Resolved closed
IDL4CPP-55 is_bounded/bound for none string/sequence types IDL4-CPP 1.0b1 IDL4-CPP 1.0b2 Resolved closed
IDL4CPP-56 @value annotation used for enum is ambiguously defined IDL4-CPP 1.0a1 IDL4-CPP 1.0b2 Closed; Out Of Scope closed
IDL4CPP-48 External mapping IDL4-CPP 1.0b1 IDL4-CPP 1.0b2 Resolved closed
IDL4CPP-44 enum_prefix/enum_postfix required IDL4-CPP 1.0b1 IDL4-CPP 1.0b2 Closed; No Change closed
IDL4CPP-41 Example VT1 not correct IDL4-CPP 1.0b1 IDL4-CPP 1.0b2 Resolved closed
IDL4CPP-35 String mapping IDL4-CPP 1.0b1 IDL4-CPP 1.0b2 Closed; No Change closed
IDL4CPP-42 Visibility destructor and constructors IDL4-CPP 1.0b1 IDL4-CPP 1.0b2 Resolved closed
IDL4CPP-29 Conflicting annotation application IDL4-CPP 1.0a1 IDL4-CPP 1.0b2 Closed; Out Of Scope closed
IDL4CPP-40 Example VT2 not correct IDL4-CPP 1.0b1 IDL4-CPP 1.0b2 Resolved closed
IDL4CPP-43 Map IDL struct to class? IDL4-CPP 1.0b1 IDL4-CPP 1.0b2 Resolved closed
IDL4CPP-31 Section A.1.2.4 needs to include maps as a potential bounded type. IDL4-CPP 1.0b1 IDL4-CPP 1.0b2 Resolved closed
IDL4CPP-49 Missing reference IDL4-CPP 1.0b1 IDL4-CPP 1.0b2 Resolved closed
IDL4CPP-47 Table 7.11 infers inheritance with something from the standard template library IDL4-CPP 1.0a1 IDL4-CPP 1.0b2 Closed; No Change closed
IDL4CPP-37 Map to fixed? IDL4-CPP 1.0b1 IDL4-CPP 1.0b2 Resolved closed
IDL4CPP-39 an_attribute not in IDL IDL4-CPP 1.0b1 IDL4-CPP 1.0b2 Resolved closed
IDL4CPP-33 long in C++ code IDL4-CPP 1.0b1 IDL4-CPP 1.0b2 Resolved closed
IDL4CPP-5 a_short in example code IDL4-CPP 1.0b1 IDL4-CPP 1.0b2 Resolved closed
IDL4CPP-6 Destructors should be override instead of virtual IDL4-CPP 1.0b1 IDL4-CPP 1.0b2 Resolved closed
IDL4CPP-7 Specify bounds checking IDL4-CPP 1.0b1 IDL4-CPP 1.0b2 Resolved closed
IDL4CPP-9 @value annotation does not fully specify its behavior IDL4-CPP 1.0a1 IDL4-CPP 1.0b2 Closed; Out Of Scope closed
IDL4CPP-2 Availability of IDL Type traits for anonymous types IDL4-CPP 1.0b1 IDL4-CPP 1.0b2 Resolved closed
IDL4CPP-3 bound type IDL4-CPP 1.0b1 IDL4-CPP 1.0b2 Closed; No Change closed
IDL4CPP-14 underlying_type traits IDL4-CPP 1.0b1 IDL4-CPP 1.0b2 Duplicate or Merged closed
IDL4CPP-8 Use of @range is inconsistent with IDL4 grammar IDL4-CPP 1.0a1 IDL4-CPP 1.0b2 Resolved closed
IDL4CPP-4 Mapping to string_view IDL4-CPP 1.0b1 IDL4-CPP 1.0b2 Closed; No Change closed
IDL4CPP-15 Clarify constructor IDL4-CPP 1.0b1 IDL4-CPP 1.0b2 Closed; Out Of Scope closed
IDL4CPP-28 Can multiple annotations be contained on a type? IDL4-CPP 1.0a1 IDL4-CPP 1.0b2 Closed; Out Of Scope closed
IDL4CPP-26 Annotations do not discuss how they interact with language mapped constructs. IDL4-CPP 1.0a1 IDL4-CPP 1.0b2 Closed; Out Of Scope closed
IDL4CPP-54 CORBA or non CORBA usage results in non compatible exceptions code IDL4-CPP 1.0b1 IDL4-CPP 1.0b2 Deferred closed
IDL4CPP-32 Implicit default and constructor IDL4-CPP 1.0b1 IDL4-CPP 1.0b2 Deferred closed
IDL4CPP-20 Add Example Transformation IDL4-CPP 1.0a1 IDL4-CPP 1.0b2 Deferred closed
IDL4CPP-50 std::shared_ptr should be passed by value IDL4-CPP 1.0b1 IDL4-CPP 1.0b2 Deferred closed
IDL4CPP-34 range/min/max underspecified IDL4-CPP 1.0b1 IDL4-CPP 1.0b2 Deferred closed
IDL4CPP-46 Remove IDL to C++11 spec extensions IDL4-CPP 1.0b1 IDL4-CPP 1.0b2 Deferred closed
IDL4CPP-27 Using floating point types to instantiate pre C++20 templates IDL4-CPP 1.0a1 IDL4-CPP 1.0b2 Deferred closed
IDL4CPP-1 Specify how IDL maps compare their keys IDL4-CPP 1.0a1 IDL4-CPP 1.0b2 Deferred closed
IDL4CPP-86 Use consistant initialization IDL4-CPP 1.0b1 IDL4-CPP 1.0b2 Deferred closed
IDL4CPP-16 Add mapping for C++20 modules IDL4-CPP 1.0b1 IDL4-CPP 1.0b2 Deferred closed

Issues Descriptions

int8/uint8 mapping

  • Key: IDL4CPP-45
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    Given this is the old CORBA style, wouldn't it be more consistent to use CORBA::TinyShort and CORBA::UTinyShort, that matches the other types as defined in D.2.1.5

  • Reported: IDL4-CPP 1.0b1 — Thu, 25 Jan 2024 12:50 GMT
  • Disposition: Closed; No Change — IDL4-CPP 1.0b2
  • Disposition Summary:

    General consensus is to maintain the current mapping

    The general consensus is to maintain CORBA::Int8 and CORBA::UInt8 for mapping the int8 and uint8 types, instead of renaming them to CORBA::TinyShort and CORBA::UnsignedTinyShort.

  • Updated: Mon, 16 Sep 2024 14:15 GMT

Bitmask mapping

  • Key: IDL4CPP-11
  • Status: closed   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
  • Disposition: Resolved — IDL4-CPP 1.0b2
  • Disposition Summary:

    Mapping Bitmasks to structs containing an enum and several operators

    As suggested in the issue, mapping bitmasks to structs containing the former enum and several operators improves the usability of the mapped type.

  • Updated: Mon, 16 Sep 2024 14:15 GMT

Alternative struct mapping not complete

  • Key: IDL4CPP-12
  • Status: closed   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
  • Disposition: Resolved — IDL4-CPP 1.0b2
  • Disposition Summary:

    Add additional constructors and accessors to alternative mapping for structs

    Clause 8.1.1 provides an alternative mapping for structs using the @cpp_annotation and setting struct_mapping to CLASS_WITH_PUBLIC_ACCESSORS_AND_MODIFIERS. In this resolution, we provide extra constructors and accessor methods for usability purposes.

  • Updated: Mon, 16 Sep 2024 14:15 GMT

The text in the C++ mapping document for bitmasks appears to contradict the text in the IDL4 specification.

  • Key: IDL4CPP-53
  • Status: closed  
  • Source: Objective Interface Systems ( Mr. Chuck Abbott)
  • Summary:

    The IDL 4 spec states the default bit_bound is 32 bits the C++ mapping document states:
    IDL bitmask declarations shall be mapped to two C++ type names:

    • An unscoped enum named <Bitmask>Bits with an explicitly defined underlying type. That underlying type
      is the smallest mapped unsigned integer type that has sufficient bits for the bit_bound of the bitmask:
      uint8_t, for values between 1 and 8; uint16_t for bit_bound values between 9 and 16; uint32_t, for
      values between 17 and 32; and uint64_t for values between 33 and 64. The <Bitmask>Bits enumerators
      are the values defined in the scope of the IDL bitmask, with each enumerator explicitly initialized to its
      corresponding integer value.
  • Reported: IDL4-CPP 1.0a1 — Fri, 1 Mar 2024 22:17 GMT
  • Disposition: Closed; No Change — IDL4-CPP 1.0b2
  • Disposition Summary:

    IDL4 specifies the default size for Bitmasks

    Clause 7.4.13.4.3.3 of IDL 4.2 states that "By default, the size of a bit mask is 32." Therefore, if @bit_bound is unspecified, we should assume the underlying type is uint32_t. It also states that "Two annotations can be used to amend a bit mask definition:" @bit_bound and @position. While an explicit @bit_bound would change the size of the bit mask, as stated in IDL 4.2, "Possible positions range from 0, which corresponds to the less significant bit, up to (size – 1), which corresponds to the most significant one." Because this specification specifies the mapping for all possible values of @bit_bound, there is no need to specify the underlying type for the default as it is 32 per IDL 4.2.

    Future versions of this specification or IDL RTFs may include further clarifications to facilitate the understanding of default behaviors.

  • Updated: Mon, 16 Sep 2024 14:15 GMT

Issue with mapping of bounded string and traits

  • Key: IDL4CPP-36
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The spec says for bounded strings " For interoperability purposes, implementers shall always define omg::types::bounded_string<N>, which may be declared as an alias to std::string". There is a problem when a bounded string is mapped to just a typedef/using of a std::string. At that moment it is not a distinct type so the traits will not work, as example, when defining this IDL

    typedef string<5> bounded_bar1;
    typedef string<5> bounded_bar2;

    And both map to just std::string, the following code will not work correctly

    if (traits<Test::bounded_bar>::is_bounded ()) {}
    if (traits<Test::bounded_bar>::bound () == 5) {}

  • Reported: IDL4-CPP 1.0b1 — Thu, 25 Jan 2024 12:15 GMT
  • Disposition: Resolved — IDL4-CPP 1.0b2
  • Disposition Summary:

    Clarify that omg::types::bounded_<type><N> shall always be defined for potential trait specializations

    With this resolution, the specification makes it clear that implementers shall always define omg::types::bounded_string<N> for potential use of trait specializations.

    Future versions of this spec may explore different avenues for mapping bounded strings.

  • Updated: Mon, 16 Sep 2024 14:15 GMT

what argument of exception constructor?

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

    In the example code it lists "AnException(int32_t error_code, const char* what)

    {...}

    ", but the what argument is not described anywhere, it is not in IDL, where is it coming from?

  • Reported: IDL4-CPP 1.0b1 — Thu, 25 Jan 2024 12:21 GMT
  • Disposition: Resolved — IDL4-CPP 1.0b2
  • Disposition Summary:

    *Add requirement for implementation of what() method in exceptions *

    Specify that the mapped Exception class shall implement the virtual what() method declared by std::exception, which the mapped Exception inherits from, and at a minimum provide a mechanism to provide such explanatory information in the explicit constructor that provides a mechanism to set the value of all exception members.

  • Updated: Mon, 16 Sep 2024 14:15 GMT

Typo fixes

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

    1.
    In table 7.1 5th row (struct is_bounded) right column:

    Indicates whether a type is bounded or not.,

    → Remove comma at end.

    2.
    In section A.1.7.4 TypeCode Replacement, there is a small typo,

    Omg::types::ref_type<CORBA::TypeCode> type() const;

    The beginning should be omg:: not Omg::.

    3.
    Section title,
    D.2.1.3.3 Bitmask Tye

    → Bitmask Type

    4.
    In section D.3.1.3.2 Bitsets,

    IDL biset types shall be mapped as defined in Clause 7.14.3.2 of this specification.

    bitset types

  • Reported: IDL4-CPP 1.0b1 — Tue, 27 Feb 2024 14:15 GMT
  • Disposition: Resolved — IDL4-CPP 1.0b2
  • Disposition Summary:

    Fix typos identified in this issue

    This issue addressed all reported typos.

  • Updated: Mon, 16 Sep 2024 14:15 GMT

Add bit_bound/underlying_type for enum

  • Key: IDL4CPP-13
  • Status: closed  
  • 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
  • Disposition: Resolved — IDL4-CPP 1.0b2
  • Disposition Summary:

    Add bit_bound and underlying_type traits to enums

    This issue adds the bit_bound and underlying_type traits to enums consistently to the traits we have added to bitmasks.

  • Updated: Mon, 16 Sep 2024 14:15 GMT

Bitmask chapter should describe argument passing rules

  • Key: IDL4CPP-51
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The spec should be describe that bitmasks do follow the same argument passing rules as a enum/basic type, for an in argument they should be passed by value. Also for union accessors it should describe that they follow the enum rules

  • Reported: IDL4-CPP 1.0b1 — Fri, 2 Feb 2024 13:39 GMT
  • Disposition: Closed; No Change — IDL4-CPP 1.0b2
  • Disposition Summary:

    No longer an issue with resolution of IDL4CPP-11

    Per the resolution of IDL4CPP-11, Bitmasks no longer result on built-in types or enums, so the rules for the rest of types apply.

  • Updated: Mon, 16 Sep 2024 14:15 GMT

@default on string and wstring?

  • Key: IDL4CPP-30
  • Status: closed  
  • Source: Objective Interface Systems ( Mr. Chuck Abbott)
  • Summary:

    Can a default annotation be applied to string types (bounded and unbounded)?

  • Reported: IDL4-CPP 1.0a1 — Wed, 10 Jan 2024 19:45 GMT
  • Disposition: Closed; No Change — IDL4-CPP 1.0b2
  • Disposition Summary:

    @default on string and wstring are allowed

    While there is no example indicating how to use @default with strings or wstrings, there's nothing in the IDL4 specification or its C++ language mapping that prevents its use. No changes in the spec are necessary.

  • Updated: Mon, 16 Sep 2024 14:15 GMT

No type from omg::types available for arrays

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

    Section 7.2.4.2 Template Types makes available types in namespace omg::types that may be used as substitutes for the native C++ types.

    The same does not apply to section 7.2.4.4 for arrays.
    Please change the first phrase in 7.2.4.4 to:

    IDL arrays shall be mapped to a C++ std::array<T>, or to a type named omg::types::array<T> that delivers std::array<T> semantics.

  • Reported: IDL4-CPP 1.0b1 — Mon, 6 May 2024 13:31 GMT
  • Disposition: Resolved — IDL4-CPP 1.0b2
  • Disposition Summary:

    Add omg::types::arrays for consistency

    This issue adds the definition of omg::types::arrays, for consistency with other types that are mapped to either std:: equivalents or omg::types.

  • Updated: Mon, 16 Sep 2024 14:15 GMT

Mapping of constants within an interface not correct, not compilable C++ code

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

    The spec maps a constant within an IDL interface to a constexpr member, but this doesn't compile:

    i.cpp:8:1: error: non-static data member ‘PI’ declared ‘constexpr’
    8 | constexpr double PI = 3.14;

    ^~~~~~~~~
  • Reported: IDL4-CPP 1.0b1 — Fri, 12 Apr 2024 09:41 GMT
  • Disposition: Resolved — IDL4-CPP 1.0b2
  • Disposition Summary:

    Constants declared in the context of an interface shall be marked as static

    To avoid build errors, constants declared in the context of an interface (full) shall be mapped to static constexpr.

  • Updated: Mon, 16 Sep 2024 14:15 GMT

bitset mapping

  • Key: IDL4CPP-10
  • Status: closed   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
  • Disposition: Resolved — IDL4-CPP 1.0b2
  • Disposition Summary:

    Change bitset inheritance behavior

    This issue replaces the inheritance behavior for bitsets, which was based on adding inherited members to the struct, to a C++ inheritance scheme.

  • Updated: Mon, 16 Sep 2024 14:15 GMT

is_bounded/bound for none string/sequence types

  • Key: IDL4CPP-55
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    it is not clear what the traits is_bounded/bound are for non string/sequence types, for example a long. The spec says the trait is empty, but it is there, what is the value then. When looking at the std traits, it seems better that is_bounded returns false_type (follows https://en.cppreference.com/w/cpp/types/is_bounded_array) and bound returns 0 (follows https://en.cppreference.com/w/cpp/types/rank)

  • Reported: IDL4-CPP 1.0b1 — Sun, 3 Mar 2024 07:31 GMT
  • Disposition: Resolved — IDL4-CPP 1.0b2
  • Disposition Summary:

    Remove is_bounded and bound traits from the list of common type traits

    This resolution removes is_bounded and bound traits from the list of common type traits, as they only applied to types that can may have bounds, such as strings, sequences, or maps.

  • Updated: Mon, 16 Sep 2024 14:15 GMT

@value annotation used for enum is ambiguously defined

  • Key: IDL4CPP-56
  • Status: closed  
  • Source: Objective Interface Systems ( Mr. Chuck Abbott)
  • Summary:

    Should the C++ mapping document specify that @value annotations, if specified for one field, MUST be used on all fields.

  • Reported: IDL4-CPP 1.0a1 — Mon, 18 Mar 2024 20:10 GMT
  • Disposition: Closed; Out Of Scope — IDL4-CPP 1.0b2
  • Disposition Summary:

    This issue shall be addressed in IDL 4.3 RTF

    We have filed IDL43-93 to address this issue in the IDL 4.3 RTF. The IDL to C++ Language Mapping specification does not need to define the syntax or scope of @value at this moment.

  • Updated: Mon, 16 Sep 2024 14:15 GMT

External mapping

  • Key: IDL4CPP-48
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The mapping of external in this section is not similar to 7.17.4. In 7.17.4 it is a std::shared_ptr, so a pointer to something which is shared, when copying the struct where the external is a member of the external data will not be copied, just a refcount increment, but in D2.3.4 it is descriibed that when the struct which contains the external member is copied a deep copy is done. Also what is exactly "copy functions", is that the copy constructor or something else? This looks very unspecified, the user doesn't know the exact API and the semantics should be the same as in 7.17.4

  • Reported: IDL4-CPP 1.0b1 — Fri, 26 Jan 2024 07:39 GMT
  • Disposition: Resolved — IDL4-CPP 1.0b2
  • Disposition Summary:

    Add extra restriction to the mapping of @external

    For consistency purposes, this resolution adds an extra restriction to the mapping of @external.

  • Updated: Mon, 16 Sep 2024 14:15 GMT

enum_prefix/enum_postfix required

  • Key: IDL4CPP-44
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    As far as I understand it enum_prefix/enum_postfix are a way to change the enum mapping but I don't understand why, because the enums itself are added to the enclosing module, so the following IDL is already illegal, red can't be defined twice
    scope. For example the following IDL is illegal

    enum Colors { red, green, blue };
    enum Colors2 { red, green, blue };
    

    See IDL4.2, chapter 7.5.2, search for "Enumeration value names are introduced into the enclosing scope and then are treated like any other declaration in that

  • Reported: IDL4-CPP 1.0b1 — Thu, 25 Jan 2024 12:48 GMT
  • Disposition: Closed; No Change — IDL4-CPP 1.0b2
  • Disposition Summary:

    Enum prefixes and postfixes prevent conflicts with external C++ code

    In C++ 98, the mapping of IDL enums does not prevent conflicts of IDL-defined literals with the C++ code a user might be mixing or linking against. That's why even though the IDL grammar does not allow conflicts in literals within the same IDL code (such conflicts are illegal in IDL), an end user might have conflicts in the generated code, which can only be prevented adding prefix or postfix enum literal names. Mapping enums to enum classes does address this issue, but such functionality is unavailable in C++ 98.

  • Updated: Mon, 16 Sep 2024 14:15 GMT

Example VT1 not correct

  • Key: IDL4CPP-41
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    For IDL type VT1 the example code is not correct:

    • virtual is missing for all pure virtual methods
    • a_long_attr is an attribute, so "int32_t& a_long_attr() = 0;" should be removed
  • Reported: IDL4-CPP 1.0b1 — Thu, 25 Jan 2024 12:30 GMT
  • Disposition: Resolved — IDL4-CPP 1.0b2
  • Disposition Summary:

    Fix mapping of VT1 in example mapping of Clause 7.6 "Value Types"

    The C++ mapping for VT1 in Clause 7.6 contains a number of errors, this resolution addresses such errors providing the correct code snippet.

  • Updated: Mon, 16 Sep 2024 14:15 GMT

String mapping

  • Key: IDL4CPP-35
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The mapping says "IDL strings shall be mapped to C++ std::string, or to a type named omg::types::string that delivers std::string semantics", but when I now have CORBA and use an interface with operation "void set_string (in string text);", what is now the C++ signature I have to override in my servant implementation, it could be "void set_string(const std::string& text) override;", or "void set_string(const omg::types::string& text) override;" which could lead to portability issues when some vendor uses std::string and another omg::types::string. For defining data it doesn't make a real difference, but it is a problem when using CORBA

  • Reported: IDL4-CPP 1.0b1 — Thu, 25 Jan 2024 12:07 GMT
  • Disposition: Closed; No Change — IDL4-CPP 1.0b2
  • Disposition Summary:

    Question has been addressed in Jira Issue

    There is nothing to change in the specification. Future versions of the specification could add further instructions on how to deal with various implementations of omg::types::strings.

  • Updated: Mon, 16 Sep 2024 14:15 GMT

Visibility destructor and constructors

  • Key: IDL4CPP-42
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The text describes that the destructor and other constructors are protected, but the example code shows them all public, the C++ code should be updated to match the text

  • Reported: IDL4-CPP 1.0b1 — Thu, 25 Jan 2024 12:37 GMT
  • Disposition: Resolved — IDL4-CPP 1.0b2
  • Disposition Summary:

    Fix indentation of protected and replace use of std::string with omg::types::string

    This issue fixes the indentation of protected and replaces the use of std::string with omg::types::string in clause A.1.10.2.

  • Updated: Mon, 16 Sep 2024 14:15 GMT

Conflicting annotation application

  • Key: IDL4CPP-29
  • Status: closed  
  • Source: Objective Interface Systems ( Mr. Chuck Abbott)
  • Summary:

    What happens when the following is present in an IDL file:

    typedef @min(2) @max(1) long Huh;

  • Reported: IDL4-CPP 1.0a1 — Wed, 10 Jan 2024 19:42 GMT
  • Disposition: Closed; Out Of Scope — IDL4-CPP 1.0b2
  • Disposition Summary:

    Issue to be addressed in IDL 4.3 RTF

    This issue refers to the IDL grammar, rather than the language mapping. Therefore, it will be addressed in the IDL 4.3 RTF.

  • Updated: Mon, 16 Sep 2024 14:15 GMT

Example VT2 not correct

  • Key: IDL4CPP-40
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The valuetype VT2 is defined in IDL, but the example C++ code is not correct, it says

    class VT2 : public virtual VT1 {
    public:
    virtual void op() = 0;
    virtual int32_t third_long() const = 0;
    virtual int32_t& third_long() const = 0;
    virtual void third_long(int16_t value) = 0;
    };
    

    But it should be

    class VT2 : public virtual VT1 {
    public:
    virtual void op() = 0;
    virtual int32_t third_long() const = 0;
    virtual int32_t& third_long() = 0;
    virtual void third_long(int32_t value) = 0;
    };
    
  • Reported: IDL4-CPP 1.0b1 — Thu, 25 Jan 2024 12:27 GMT
  • Disposition: Resolved — IDL4-CPP 1.0b2
  • Disposition Summary:

    Fix mapping of VT2 in Clause 7.6 "Value Types"

    Clause 7.6 "Value Types" contains a typo in the mapping of a long, this issue fixed the typo mapping the IDL long to int32_t instead of int16_t.

  • Updated: Mon, 16 Sep 2024 14:15 GMT

Map IDL struct to class?

  • Key: IDL4CPP-43
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    Why does this example code for "C.2.1.2.4 Naming Data Types" map the IDL struct to a C++ class, that is the alternative mapping, but as far as I understand it the mapping prefers to map a IDL struct to a C++ struct by default

  • Reported: IDL4-CPP 1.0b1 — Thu, 25 Jan 2024 12:40 GMT
  • Disposition: Resolved — IDL4-CPP 1.0b2
  • Disposition Summary:

    Fix mapping of naming data types in C.2.1.2.4

    In clause C.2.1.2.4, IDL struct MyType is mapped to a class, instead of a struct, which is the correct mapping. This issue addresses that mistake.

  • Updated: Mon, 16 Sep 2024 14:15 GMT

Section A.1.2.4 needs to include maps as a potential bounded type.

  • Key: IDL4CPP-31
  • Status: closed  
  • Source: Objective Interface Systems ( Mr. Chuck Abbott)
  • Summary:

    The section is silent on maps.

  • Reported: IDL4-CPP 1.0b1 — Wed, 17 Jan 2024 16:32 GMT
  • Disposition: Resolved — IDL4-CPP 1.0b2
  • Disposition Summary:

    Refer to Maps in clause A.1.2.4

    Clause A.1.2.4, which addresses the exception type for bounded types shall refer to strings, wstrings, sequences, and maps.

  • Updated: Mon, 16 Sep 2024 14:15 GMT

Missing reference

  • Key: IDL4CPP-49
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    A link is broken, it mentions:

    Maps shall provide the following specializations for the type traits defined in Clause Error: Reference source not found:

  • Reported: IDL4-CPP 1.0b1 — Fri, 26 Jan 2024 07:41 GMT
  • Disposition: Resolved — IDL4-CPP 1.0b2
  • Disposition Summary:

    Fix broken cross references

    The specification includes a number of broken cross references. This issue replaces broken cross references with the appropriate sections.

  • Updated: Mon, 16 Sep 2024 14:15 GMT

Table 7.11 infers inheritance with something from the standard template library

  • Key: IDL4CPP-47
  • Status: closed  
  • Source: Objective Interface Systems ( Mr. Chuck Abbott)
  • Summary:

    The text:
    "Inherits std::integral_constant<uint32_t, b> where b indicates
    the bit_bound of the bitmask."

    should instead state

    Defines value - Where the value is mapped as the underlying bit_bound of the bit mask.

  • Reported: IDL4-CPP 1.0a1 — Thu, 1 Feb 2024 19:12 GMT
  • Disposition: Closed; No Change — IDL4-CPP 1.0b2
  • Disposition Summary:

    Type traits may be inherited

    Type traits may be inherited, and it is indeed a common practice, so the mapping should remain as is. The restriction would be to inheritance of classes that have a state, such as std::vector or std::string.

  • Updated: Mon, 16 Sep 2024 14:15 GMT

Map to fixed?

  • Key: IDL4CPP-37
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    As all types in the spec are lower case, shouldn't IDL fixed be mapped to C++ fixed (all lower case)

  • Reported: IDL4-CPP 1.0b1 — Thu, 25 Jan 2024 12:16 GMT
  • Disposition: Resolved — IDL4-CPP 1.0b2
  • Disposition Summary:

    Renaming Fixed to fixed for consistency purposes

    This specification defines common C++ types using lowercase names, such as bounded_string, bounded_sequence, etc. Therefore, for consistency purposes, the Fixed class shall be renamed to fixed.

  • Updated: Mon, 16 Sep 2024 14:15 GMT

an_attribute not in IDL

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

    The example for interfaces full lists in IDL the attribute "an_attribute", but the cod example uses "attribute", which is not correct

  • Reported: IDL4-CPP 1.0b1 — Thu, 25 Jan 2024 12:23 GMT
  • Disposition: Resolved — IDL4-CPP 1.0b2
  • Disposition Summary:

    Fix example mapping of attribute in Interfaces - Full

    The example for Interfaces - Full contains an error in the mapped name of an attribute.

  • Updated: Mon, 16 Sep 2024 14:15 GMT

long in C++ code

  • Key: IDL4CPP-33
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    In the example code there is "using Length = long;", but long is not portable, shouldn't be this be int32_t?

  • Reported: IDL4-CPP 1.0b1 — Tue, 16 Jan 2024 09:46 GMT
  • Disposition: Resolved — IDL4-CPP 1.0b2
  • Disposition Summary:

    Replace use of C++ long in example code with int32_t

    IDL longs are mapped to C++ int32_t, the example in clause 7.2.4.6 makes the mistake of mapping a typedef long to a using of long instead of int32_t.

  • Updated: Mon, 16 Sep 2024 14:15 GMT

a_short in example code

  • Key: IDL4CPP-5
  • Status: closed  
  • 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
  • Disposition: Resolved — IDL4-CPP 1.0b2
  • Disposition Summary:

    Update mapping of a_short in example code

    Accessors for members of the union for which the mapped type results in primitive types and enums shall return by value. Therefore, the updated example reflects that:

    // ...
    void a_long(int32_t value) {...}
    int32_t a_long() const {...}
    // ...
    

    The updated example also includes members that result in non-primitive types like strings or structs.

    As part of the resolution of this issue we also provide a method to set the discriminator to a specific legal value when the union definition has an implicit default member (the current mapping only provides a _default() that sets the discriminator to a legal default value).

    We also mandate that non-primitive members provide two getters:

    const Foo& a_foo() const {}
    Foo& a_foo() {}
    

    and primitive members the following two getters:

    int16_t a_long() const {}
    int16_t& a_long() {}
    

    If the getter selects a branch that does not match the discriminator value, the getter should throw an error.

  • Updated: Mon, 16 Sep 2024 14:15 GMT

Destructors should be override instead of virtual

  • Key: IDL4CPP-6
  • Status: closed  
  • 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
  • Disposition: Resolved — IDL4-CPP 1.0b2
  • Disposition Summary:

    Convert virtual destructors in overrides

    To resolve this issue, all virtual destructors are converted to overrides.

  • Updated: Mon, 16 Sep 2024 14:15 GMT

Specify bounds checking

  • Key: IDL4CPP-7
  • Status: closed  
  • 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
  • Disposition: Resolved — IDL4-CPP 1.0b2
  • Disposition Summary:

    Specify that middleware implementations may mandate specific bound checking mechanisms

    This issue tries to convey that middleware implementations may introduce more explicit bound checking mechanisms.

  • Updated: Mon, 16 Sep 2024 14:15 GMT

@value annotation does not fully specify its behavior

  • Key: IDL4CPP-9
  • Status: closed  
  • Source: Real-Time Innovations ( Mr. 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
  • Disposition: Closed; Out Of Scope — IDL4-CPP 1.0b2
  • Disposition Summary:

    Issue to be addressed in IDL4.

    This issue should be addressed in the IDL 4.3 RTF.

  • Updated: Mon, 16 Sep 2024 14:15 GMT

Availability of IDL Type traits for anonymous types

  • Key: IDL4CPP-2
  • Status: closed  
  • 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
  • Disposition: Resolved — IDL4-CPP 1.0b2
  • Disposition Summary:

    Add a note to clause 7.15 to illustrate type traits for anonymous types

    This resolution adds an example that shows how to aquire acquire the declared type of a struct member and use it in a traits declaration.

  • Updated: Mon, 16 Sep 2024 14:15 GMT

bound type

  • Key: IDL4CPP-3
  • Status: closed  
  • 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
  • Disposition: Closed; No Change — IDL4-CPP 1.0b2
  • Disposition Summary:

    IDL Language Mappings Should Not Impose Bound Limits

    Limits on bound sizes are imposed by the serialization format of middleware such as CORBA and DDS (e.g., CORBA specifies the behavior for the serialization for sequences bigger than uint32_t, and that should be enough for the middleware implementer). IDL and the corresponding IDL language mappings need not impose such limits.

  • Updated: Mon, 16 Sep 2024 14:15 GMT

underlying_type traits

  • Key: IDL4CPP-14
  • Status: closed  
  • 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
  • Disposition: Duplicate or Merged — IDL4-CPP 1.0b2
  • Disposition Summary:

    This issue will be addressed in IDL4CPP-11

    The resolution of this issue will be addressed in IDL4CPP-11.

  • Updated: Mon, 16 Sep 2024 14:15 GMT

Use of @range is inconsistent with IDL4 grammar

  • Key: IDL4CPP-8
  • Status: closed  
  • Source: Real-Time Innovations ( Mr. 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
  • Disposition: Resolved — IDL4-CPP 1.0b2
  • Disposition Summary:

    Fix @range example

    This issue fixes the use of @range in the examples.

  • Updated: Mon, 16 Sep 2024 14:15 GMT

Mapping to string_view

  • Key: IDL4CPP-4
  • Status: closed  
  • 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
  • Disposition: Closed; No Change — IDL4-CPP 1.0b2
  • Disposition Summary:

    Middleware Implementations Should Deal with Conversions

    Solving conversion issues would be a task for the specific middleware implementation. If the mapping were to use char*, implementers would have to deal with the same issue.

  • Updated: Mon, 16 Sep 2024 14:15 GMT

Clarify constructor

  • Key: IDL4CPP-15
  • Status: closed  
  • 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
  • Disposition: Closed; Out Of Scope — IDL4-CPP 1.0b2
  • Disposition Summary:

    This issue is referring to a different specification

    This issue is actually pointing to the IDL to C++11 specification.

  • Updated: Mon, 16 Sep 2024 14:15 GMT

Can multiple annotations be contained on a type?

  • Key: IDL4CPP-28
  • Status: closed  
  • Source: Objective Interface Systems ( Mr. Chuck Abbott)
  • Summary:

    For instance is this legal:

    struct S

    { @min(2) @max(5) @default(3) long f1; }

    ;

    typedef @min(2) long MyMin;
    typedef @max(5) MyMin MyMinMax;
    typedef @default(3) MyMinMax defaultedMyMinMax;

  • Reported: IDL4-CPP 1.0a1 — Wed, 10 Jan 2024 19:38 GMT
  • Disposition: Closed; Out Of Scope — IDL4-CPP 1.0b2
  • Disposition Summary:

    Issue Refers to IDL Grammar

    This issue will be addressed in the IDL 4.3 RTF, as it refers to the IDL grammar rather than the language mapping.

  • Updated: Mon, 16 Sep 2024 14:15 GMT

Annotations do not discuss how they interact with language mapped constructs.

  • Key: IDL4CPP-26
  • Status: closed  
  • Source: Objective Interface Systems ( Mr. Chuck Abbott)
  • Summary:

    Each annotation specified, either pre-defined or user-defined/custom, should discuss how it interacts with the IDL4 grammar such that the annotation has the desired effect (e.g. @range on a union).

  • Reported: IDL4-CPP 1.0a1 — Wed, 10 Jan 2024 19:29 GMT
  • Disposition: Closed; Out Of Scope — IDL4-CPP 1.0b2
  • Disposition Summary:

    This issue belongs in the IDL4 RTF.

    This issue should be addressed in IDL4.

  • Updated: Mon, 16 Sep 2024 14:15 GMT

CORBA or non CORBA usage results in non compatible exceptions code

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

    The spec describes that with CORBA an invalid usage of union can result in a CORBA::BAD_PARAM exception, for bounded string/vector also a CORBA::BAD_PARAM, but when not using CORBA when IDL4CSP11-9 is resolved a different exception is thrown for an union (for vector it seems this still has to be added also). When a user now has appliation code that uses IDL defined data types with and without CORBA their exception code is different. In order to achieve portability of user code I think the spec should define a omg::bad_param alias type which maps to CORBA::BAD_PARAM or the selected std exception. That way user code can be written portable when the user has data types defined by IDL and wants to support use cases with and without CORBA

  • Reported: IDL4-CPP 1.0b1 — Sun, 3 Mar 2024 07:23 GMT
  • Disposition: Deferred — IDL4-CPP 1.0b2
  • Disposition Summary:

    Error handling and exceptions will be treated in feature versions of the spec

    By design, the current version of this specification does not specify explicit mechanisms to report errors (e.g., which exception should be thrown or whether exceptions should be thrown at all). The intention was to be able to support both environments where exceptions are valid and are allowed, as well as environments where applications may not throw or handle exceptions.

    Future versions of this specification may define explicit mechanisms to report errors, and will aim to harmonize them across middleware implementations.

  • Updated: Mon, 16 Sep 2024 14:15 GMT

Implicit default and constructor

  • Key: IDL4CPP-32
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    Spec says:

    If the union has a default case, the default constructor shall initialize the discriminator, and the selected
    member field following the initialization rules described in Clause 7.2.4.3.1. If it does not, the default
    constructor shall initialize the union to the first discriminant value specified in the IDL definition.

    But when there is an implicit default member, that should be selected, for example, the example below (

      enum DataType
      {
        dtEmpty,
        dtLong,
        dtShort,
        dtString,
        dtPoint,
        dtTrack,
        dtGlobal
      };
    
      union Data switch (DataType)
        {
          case dtLong: long longData;
          case dtShort: short shortData;
          case dtString: string stringData;
          case dtPoint: string pointData;
          case dtTrack: string trackData;
          case dtGlobal: string globalData;
          // by default (implicit), empty union
        };
    
  • Reported: IDL4-CPP 1.0b1 — Tue, 16 Jan 2024 09:36 GMT
  • Disposition: Deferred — IDL4-CPP 1.0b2
  • Disposition Summary:

    Defer the resolution of this issue to the resolution of the related IDL RTF issue

    This issue is deferred until the resolution IDL43-94.

  • Updated: Mon, 16 Sep 2024 14:15 GMT

Add Example Transformation

  • Key: IDL4CPP-20
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Daniel Brookshier)
  • Summary:

    Not sure where (not necessarily in the noted paragraph) should include a reference to an electronic mapping file as an example. Could also include test sample IDL and corresponding C++ output. This should probably be informational and could also be in an Annex. The key reason is to show the actual transformation as well as a test/verification of the mappings. Perhaps also include versions of tools/compiler used in which the transformations were validated. In addition unit tests could be referenced or included as informative content to the spec.

  • Reported: IDL4-CPP 1.0a1 — Thu, 28 Sep 2023 20:50 GMT
  • Disposition: Deferred — IDL4-CPP 1.0b2
  • Disposition Summary:

    Example Transformations To Be Incoporated in Future Versions of the Standard

    We think this is an interesting concept, but it hasn't been addressed in the existing IDL4 to Language Mappings. To better align version 1.0 with the existing mappings, we think this proposal should be addressed in subsequent RTFs.

  • Updated: Mon, 16 Sep 2024 14:15 GMT

std::shared_ptr should be passed by value

  • Key: IDL4CPP-50
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The spec in 7.4 says that only basic types/enum should be passed by value for an in argument, but that should also include all shared_ptr types, see https://herbsutter.com/2013/06/05/gotw-91-solution-smart-pointer-parameters/ for some information (more can be found on the internet).

  • Reported: IDL4-CPP 1.0b1 — Fri, 2 Feb 2024 13:36 GMT
  • Disposition: Deferred — IDL4-CPP 1.0b2
  • Disposition Summary:

    Passing shared_ptr by value could introduce certain issues

    If we pass by value we could introduce certain issues, like locking (having to increase the reference counter). It's unclear to us whether this would be beneficial. If we pass it by const reference, we're guaranteeing that the object won't be destroyed until the end of the function.

    After a discussion within the IDL WG, we agreed on leaving the mapping as it currently is and reevaluate improvements to the mapping in future RTFs.

  • Updated: Mon, 16 Sep 2024 14:15 GMT

range/min/max underspecified

  • Key: IDL4CPP-34
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    A few remarks on 7.17.3:

    • formatting of code in text is not done
    • what is the impact of range when applied to a typedef of a basic type on all argument passing rules when that typedef is passed with a function, stored in an union or exception?
    • how should min/max be implemented, shouldn't also omg::types::ranged be used?
    • what should be done when min/max but also range are used as annotation?
  • Reported: IDL4-CPP 1.0b1 — Wed, 24 Jan 2024 08:58 GMT
  • Disposition: Deferred — IDL4-CPP 1.0b2
  • Disposition Summary:

    Defer until the resolution of the related IDL RTF issue

    The IDL RTF must address some of the underlying issues when applying @min, @max, @range, and @default annotations (e.g., see IDL43-89). Therefore, we are deferring the implementation of an updated mapping until the IDL RTF tackles the underlying issue.

  • Updated: Mon, 16 Sep 2024 14:15 GMT

Remove IDL to C++11 spec extensions

  • Key: IDL4CPP-46
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    I find it not very maintainable to extend in this spec silently the IDL to C++11 language mapping. In the v1.7 revision I think all is already mapped, so I propose to remove D.3 completely from this spec

  • Reported: IDL4-CPP 1.0b1 — Thu, 25 Jan 2024 12:53 GMT
  • Disposition: Deferred — IDL4-CPP 1.0b2
  • Disposition Summary:

    Defer to future versions of this specification

    Future versions of this specification may remove Clause D.3 or replace its content with pointers to the appropriate clauses in the IDL to C++11 v1.7 specification. However, because this specification originally targeted v1.6 of such specification, it will require some research and agreement on the best path forward within the MARS IDL WG.

  • Updated: Mon, 16 Sep 2024 14:15 GMT

Using floating point types to instantiate pre C++20 templates

  • Key: IDL4CPP-27
  • Status: closed  
  • Source: Objective Interface Systems ( Mr. Chuck Abbott)
  • Summary:

    Prior to C++20, the following template cannot be instantiated:

    template <typename T, const T thingy>
    class MyTemplate {};

    MyTemplate<double, 5.0> x;

  • Reported: IDL4-CPP 1.0a1 — Wed, 10 Jan 2024 19:33 GMT
  • Disposition: Deferred — IDL4-CPP 1.0b2
  • Disposition Summary:

    Mapping for min, max, and ranged remains the same

    In this case, an alternative implementation would introduce too much complexity. For that reason, we propose to defer this issue to future RTFs. State of the art compilers supporting C++20 work with the proposed mapping. Future RTFs may add additional information for implementers that require compatibility with earlier compilers.

  • Updated: Mon, 16 Sep 2024 14:15 GMT

Specify how IDL maps compare their keys

  • Key: IDL4CPP-1
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Mr. 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
  • Disposition: Deferred — IDL4-CPP 1.0b2
  • Disposition Summary:

    List of Valid Key Types for Maps Will Be Provided in IDL 4.3

    This issue is tightly coupled with IDL43-70, which aims to determine the list of valid key types for IDL maps. Because the current IDL4 to C++ Language mapping targets IDL 4.2 (which does not specify the list of valid types), this FTF will no't be adding further restrictions.

    Future versions of the IDL4 to C++ Language mapping may add key map type restrictions compliant with the resolution of IDL43-70.

  • Updated: Mon, 16 Sep 2024 14:15 GMT

Use consistant initialization

  • Key: IDL4CPP-86
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    the code examples use = and {} to initialize the constants, recommend to make this consistent by always using {}

  • Reported: IDL4-CPP 1.0b1 — Fri, 12 Apr 2024 09:55 GMT
  • Disposition: Deferred — IDL4-CPP 1.0b2
  • Disposition Summary:

    Defer to future revisions of the specification

    In this case, we chose to use {} only when necessary, and use = instead for when both options were possible. Having said that, given the current trend leaning towards the use of {}, future versions of this specification may change this coding convention.

  • Updated: Mon, 16 Sep 2024 14:15 GMT

Add mapping for C++20 modules