The text talks about struct_mapping, but shouldn't the text refer to cpp_mapping and say that the default is STRUCT_WITH_PUBLIC_MEMBERS, the internal struct_mapping with the default is just an internal thing (maybe rename struct_mapping to just value), when I look at IDL4.2, it has in 8.3.1.2 the autoid annotation, there AutoidKind is just not mentioned and the user uses @autoid, and not @AutoidKind

IDL to C++11 defines a set of IDL::traits, but this spec uses the old CORBA::traits, section A has to be updated/cleaned to use IDL::traits

The proposed enum mapping makes it harder to migrate from C+03 to C11 or newer, why not map this to a class with a _flags enum as member (same as bitmask does). The _flags enum contains the enum elements as defined in IDL, this way user code can use AnEnum::zero independent whether C03 or C+11 is used

The example has the following operations for a_long (same issue happens with the others)

void a_long(int32_t value)

int32_t a_long() const

a_long is a basic type, so according to the text it should have:

<MemberType> <MemberName>()
<MemberType> <MemberName>() const;

Both return by value, but the example has one returning by reference.

Also the setter for a_struct doesn't match the text, seems this chapter needs some review and tweaks

Constructed types are types that are created by an IDL specification.

All types are created by an IDL specification, this is not a characterization that distinguishes constructed types.

I propose
     Constructed types are types that have members.

This would provide distinction from other types.

The spec defines that a bitfield can be a maximum of 64bits, but it doesn't say anything about the maximum size of the bitset, can we create a bitset with 1000 fields of each 64bits? Is that legal, or is there some limit to the maximum size of a bitset

The bitmask mapping lacks the operator&, operator|, operator^, operator~, see https://en.cppreference.com/w/cpp/named_req/BitmaskType, a bitmask type in C++ should have these

The text says that the code should use a _flags enum, but the example usees MyBitMaskBits

The text says

An implementation of the !=, &=, and ^= bitwise operators

But that should use operator |= and not !=

The struct MyBitMask as example code has the following buts:

• After `flag1 = 0x01 <<` the 1 is missing
• operator|= has an incorrect first implementation line, should be `_value |= other;`
• operator&= has a wrong argument , should be `std::uint32_t other`
• operator uint32_t() can be const

This section has:

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

Notice the typo, biset should be bitset

The spec is not clear when a type annotated with @default/@default_literal will really use these annotations

For example when I have in IDL the following:

@default(5) typedef long mylong;

When I now use in C++

mylong myvalue {};

What would be the value of myvalue, would it be 5 (the default I specified), or will it be 0?

Also when I have in IDL

enum Color

;

And in C++ I have

Color mycolor {};

What is the value of mycolor, RED or GREEN?

RTI support says these annotations are only used when the IDL type is used within a complex type (struct/union/exception), but if that is the case the IDL spec should mention this.

Some other related questions/thinking points

• What when using array/sequences/map of these types?
• what about @range?

As the class ValueFactoryBase has no base class the destructor should be virtual and not override, same error is made in more examples

Some text for the annotations refers to element, but the introduction in 8.3.1 says "They may be applied on almost all kinds of elements", but what is an element. It looks for example logical that optional/value/min/max/unit/range can also be applied to a typedef, for example "@optional typedef boolean opt_bool1;". In a DDS world these annotations are mostly only used for types, but with CORBA/LwCCM adding them to a typedef could also mean that for example a optional is passed with a method call.

The spec should be more precise whether applying annotations to a typedef is legal.

The definition of value_type says `Defines type - Type to be used as return C++ type.`, but in what context is return handled. For example in the struct class mapping for type T a const and non-const accesor is defined. Shouldn't be value_type defined as `The template parameter T.`, just as A.1.1 does?

The spec is not clear where optional may be applied, I wanted to use it with a typedef, see the test below, but it seems DDS XTypes disallowed it but IDL4 does seem to allow it, it says "This annotation may be used to set optionality on any element that makes sense to be optional.", my example makes sense about it. The spec should be more precise where this annotation (and others) maybe used

module Test {
@optional
typedef long OptLongFoo;
struct Bar

;
};

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

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.

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.

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.

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

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.

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.

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.

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) {}

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.

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?

*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.

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

Fix typos identified in this issue

This issue addressed all reported typos.

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

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.

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

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.

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

@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.

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:

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.

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;

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.

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

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.

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)

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.

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

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.

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

Add extra restriction to the mapping of @external

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

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

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.

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

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.

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

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.

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

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.

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

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

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.

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;
};

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.

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

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.

The section is silent on maps.

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.

A link is broken, it mentions:

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

Fix broken cross references

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

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.

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.

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

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.

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

Fix example mapping of attribute in Interfaces - Full

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

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

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.

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

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.

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.

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;"

Convert virtual destructors in overrides

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

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

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.

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.

Issue to be addressed in IDL4.

This issue should be addressed in the IDL 4.3 RTF.

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

;

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.

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.

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

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.

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.

This issue will be addressed in IDL4CPP-11

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

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;
};

Fix @range example

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

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?

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.

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."

This issue is referring to a different specification

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

For instance is this legal:

struct S

;

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

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.

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).

This issue belongs in the IDL4 RTF.

This issue should be addressed in IDL4.

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

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.

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
    };

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

This issue is deferred until the resolution IDL43-94.

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.

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.

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).

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.

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?

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.

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

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.

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

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

MyTemplate<double, 5.0> x;

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.

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

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.

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

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.

With C++20 it would be nice when the mapping would specify a module mapping (see https://en.cppreference.com/w/cpp/language/modules).

C++20 Modules to be explored in future RTFs

The use of C++20 modules will be explored in future versions of this specification.

extensibility is heavily under specified in IDL4.2. It is listed as a general purpose annotation but it says nothing at the moment for the case appendable/mutable is specified and types are evolved. What are at that moment the rules for assignability/compatibility. Someone who just looks at IDL4 lacks a lot of required information

The specification is unclear of what the user can expect when using mutable and annotations like range, what when the old version of the type has a range of 1-10 and the new one range of 1-5. An old version is send with value 6, what does the receiver get? Very likely more annotations need to be extended in their description related to mutable

The specification just lists any as value for the min/max/default annotations, but that tells nothing about what is allowed as value, are for what about hex/octet values, floats, etc. Maybe make this more precise by referring to the value_expression rules `<const_expr>` as specified in 7.4.1.4.3 constants

Currently the key element type for maps is the same as the value element type, but that looks to be open, this allows for example a union, struct, reference, or other complex type as key type, all of them lack a comparison operator, very likely it is better to define a special map_key_type_spec just as we have for the union as switch_type_spec

The spec doesn't say anything about bitmask bit_value scoping. I think the spec currently allows

bitmask MyBitMask

;

This is problematic when a bitmask maps to an enum in C++. As a bitmask is pretty similar to an enum I do ask the following, in section 7.5.2 it says:

Enumeration value names are introduced into the enclosing scope and then are treated like any other declaration in that scope.

What about a bitvalue, shouldn't this also be done for a bitvalue (the members of a bitmask), that would allow a safe mapping to an enum in C++.

The spec should be clear about where bitmasks are introduced, within the bitmask scope itself, or in the enclosing scope

The spec says for bitfield " list of identifiers (<identifier>*).", shouldn't this be 1 or 0 identifiers, what if the user specifies 4 identifiers, how to separate them, what is the meaning?

In user code I want to use constexpr for IDL fixed values, for example

constexr F pi

;

But in order for that to work a constexpr constructor has to be available, the spec should define that

In the context of CORBA it is not legal to just compare object references with operator==/!= which are both provided by std:;shared_ptr. The fact that the local client proxy is different doesn't mean the called CORBA servant is different, in IDL to C+11 comparing two interfaces is illegal (see 6.7.2 of IDL to C+11). This specification should make it clear that omg::types::ref_type<T> should not be comparable

The spec says for structured types "A set of comparison operators, including at least "equal to" and "not equal to."", but that is not possible when the structure contains interfaces, valuetypes, valueboxes, abstract, all special types don't provide a operator==/!= so they can't be required when a structure contains any of these. This requirement has to be removed. CORBA doesn't provide equal for these special types because a local != doesn't mean that the references are not pointing to the same servant, object identity is not done through local pointers

CORBA::CustomerMarshal should be CORBA::CustomMarshal

The spec doesn't describe exactly to which element types @optional should be possible, leaving it to the vendor implementation. The spec should describe to which element type this annotation (but also the others) should be applied, struct members sounds logical, but what about union members, attributes, exception members?

If the numeric type is annotated by range:

    @range(min=1, max = 10) long f1;

or min

    @min(1) long f1;

or max

    @max(-1) long f1;

but does not specify a default, what is the default value since it cannot be 0.

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

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).

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

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?

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

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.

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

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

MyTemplate<double, 5.0> x;

With C++20 it would be nice when the mapping would specify a module mapping (see https://en.cppreference.com/w/cpp/language/modules).

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

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
    };

There are currently a number of numeric annotations presented in the spec. These are annotations that impact the numerical behavior of a type (like its allowed ranges). Right now, the spec doesn't clearly specify where these annotations may be applied and where they may not be applied. It would be wise to extend the section that introduces these annotations with a paragraph that clearly lays out these restrictions.

It is unclear whether or how annotations such as "unit" and "range" apply to the values in an array or sequence. Other annotations may have similar ambiguity.

Do they apply to each contained value, or do do they somehow apply to the aggregate value? What about multi-dimensional arrays or nested sequences?

Does the range somehow apply to the sequence length, perhaps as a minimum?

Where do they belong in the array or sequence definitions – before the keyword, before the type name, or somewhere else?

Do the different locations accept different annotations? Do the annotations change meaning depending on location?

There is nothing explained what the expected behavior is when an annotation is applied at multiple levels, for example see the changed example from 8.3.3, what is the range for Foo:bar2, is it min=10,max=20 or min=5,max=10

@range (min=10, max=20)
typedef long MyLong;
...
struct Foo

;

Section 8.3.3
Has the normative example;

@range (min=10, max=20)
typedef long MyLong;

It is unclear to me if the annotation applies to the typedef keyword or to the type in the typedef definition.

As a OMG IDL user, I have messages that treat NaN or infinity as a significant value. I would like to specify this as a default for a field.

Currently, the OMG IDL specification says that a floating point value must include an integer part. It does not mention how to set or use special floating point values.

Per IEEE-754, there are a few types of NaN. It would be desirable for OMG DDS IDL to interpret NaN as a quiet NaN, which matches C++ and Python.

In ROS-IDL, it would look like this:
float32 float32_nan NaN
float64 float64_nan nan

In ROS 2, I proposed an implementation that sets NaN. In the IDL generator, it creates the following IDL file, which is not supposedly valid according to the standard:

module rosidl_generator_tests {
module msg {
module NanValueConstant_Constants

;
struct NanValueConstant

;
};
};

Can the specification be amended to support NaN, +inf, and -inf? This is blocking implementation in ROS 2.

Currently only TRUE or FALSE are allowed boolean values, but why not allow true and false (all lower case) as values

The spec clearly specifies that when a union has an explicit default member, then this member should be chosen in its default constructor. When this is not the case, it would pick the first available case that is listed for its first available member.
However, it makes sense that if there is an implicit default member, then it is picked by the default constructor for the union.
Finally, it should be stated that you cannot overrule in any way what member the default constructor of a union will pick by using the @default annotation on any specific member,

Should the IDL4 grammar specify that @value annotations, if specified for one enum field, MUST be used on all enum fields?
Regardless of whether we make this restriction, the specification should clearly state what happens when one field is annotated, but the next one is not.

The annotation optional impacts the language mapping, for example in C it results in a pointer, with C++11 it could be a IDL::optional<>. The usage of an annotation is very weak in terms of semantics, it is much better to use a new optional keyword as optional heavily impacts the type presented to the programmer. Adding optional will break existing user code, it is not only something that is checked by a concrete middleware.

The

The spec is silent about the relationship between min/max/range annotations and the default value. When I have an unsigned long and define min=10/max=20, is that legal without specifying a default value annotation? The default of an unsigned long is zero, so what should be generated in the code now as default? Or should the spec say that when min/max/range are used and the default value of the type is not in the range of those default should be specified by the user?

The IDL 4.2 page has a download link for the spec as published as an ISO: https://www.omg.org/spec/IDL/ISO/19516/PDF

All (?? - verification left as an exercise but there's 926 instances) the internal document links look to be screwy.

Search for e.g. "Reference source not found"

An example (from page 102):

Annex A
Consolidated IDL Grammar
This annex gathers all the rules from all the building blocks.
Error! Reference source not found.:
Error! Reference source not found. Error! Reference source not found.
Error! Reference source not found. Error! Reference source not found.
Error! Reference source not found. Error! Reference source not found.
... etc...

For all c++ code in this chapter the destructor should be override, not virtual

The raise operation should be _raise, that way any derived user exception can have a raise member, similar to _name and _rep_id. Looks an oversight when adding the code from TAOX11, we use _raise always there

The data retrieval of described rules of constants entity during document compilation failed.

With a bitset/bitfield I assume you can use @default to specify a default value, would be nice if a binary constant could be used, as with C++, a binary constant consists of a sequence of ‘0’ and ‘1’ digits, prefixed by ‘0b’ or ‘0B’ for example 0b101010

IDL 4.2 says for bitset the following, but to our idea the IDL spec goes to far, how the data is organized in memory is something IDL can't enforce, probably not all programming languages provide such a direct way to control the memory layout. Middleware could control how a bitset is transferred on the wire, but I think IDL should not enforce the layout

Bit sets are sequences of bits stored optimally and organized in concatenated addressable pieces called bit fields,
themselves stored optimally. "Stored optimally" means that one bit uses just one bit in memory. "Concatenated" means
that each bit field will be placed in memory just after its predecessor within the bit set (no alignment considerations
apply).

I assume that in a map keys may not be unique (this should be added to 7.4.13.4.3.1), in case that is a restriction for a map, I propose to add a multimap which allows keys to be duplicate.

Now that with IDL4 the user can use @default to specify a specific default it would be good to also specify the default for all basic types when no @default is used. That way the user (or tool) can make a decision whether it must use @default in IDL or not

In the footnote the link to http://www.bipm.org/en/measurement-units/ is mentioned, but this seems to be dead, the link should probably be https://www.bipm.org/en/measurement-units/

Add ruby as language, there is a formal OMG language mapping for that, maybe just add all programming languages for which the OMG already has a formal language mapping

For int8 a new signed_type_int is defined, but I think it should just do the following so that anywhere where octet is used now int8 can be used

<octet_type> ::+ "int8",

IDL 4.2 syntax supports inheritance of only interfaces, valuetypes, and structures.

There are multiple scenarios where it would be useful to inherit other types, specifically Unions and Enumerations.

(1) Inheritance of unions

This would be very useful in some specs where unions are automatically generated. For example unions are created interface definitions in DDS-RPC and derived interfaces would like to use unions that "inherit" the unions in the base interfaces.

This would be useful when a "derived" union wants to add some more cases to the base union.

The derived union would have to use the same discriminator type. All it can do is add new discriminator cases that do not conflict with the non-default discriminator in the base union.

It can add a default case if not present in the base union.

Proposed syntax would be:

union DerivedUnion : BaseUnion {
    case 1 :
       Case1Type case1meber;
...
};

(2) Inheritance of enumerations

This is useful to add literals to an existing enumeration without touching the original definition.

The literals on the derived union would be constrained to not conflict the literals in the base class.

Proposed syntax would be:

enum DerivedEnum : BaseEnum {
    AdditionalLiteral1,
    ...
};

For bitmask the spec says "By default, the size of a bit mask is 32", but what unit is 32, I assume the spec wants to say "By default, the size of a bit mask is 32 bits"

All constructed types map to a C+11 class with accessors, but the new bitset mapping is an exception now, it delivers no accessor methods which gives a different API to the programmer. We propose to map to a class with accessors, similar like struct, or fastdds does in their implementation (see https://fast-dds.docs.eprosima.com/en/latest/fastddsgen/dataTypes/dataTypes.html#bitsets). Also the IDL inheritance is gone in C11, propose to use a derived class, so that in the C+11 code there is also an inheritance

There is a general need to document the IDL. However the IDL language does not provide any standard way to do this. As a consequence people may be forced to define custom annotations which would preclude the use across projects and/or development of general tools that are documentation aware.

To remediate this the suggestion is to add some built-in annotations that maybe used to document the IDL. For example the @documentation annotation below:

@annotation documentation {
    string value default "TBD";
};

This annotation could applied to a type declaration or to a member / element, as in:

@documentation("This documents the type Foo")
struct Foo {
    @documentation("documentation for member m1")
    long m1;
    @documentation("documentation for member m2")
    long m2;
 };

@documentation("This documents the type MyEnum")
enum MyEnum {
    @documentation("documentation for literal L1")
    L1,

    @documentation("documentation for literal L2")
    L2
 };

When map/bitset/bitmask are added it looks formal_parameter_type is not extended to allow these new types to be used as templated module arguments.

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

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.

Section 7.4.13.4.3.1 defines IDL Maps but doesn't specify:

• Which types may be keys
• If maps need to de-duplicate equivalent entries
• If maps need to preserve order

The most essential of these is the first. It's currently unrestricted but this causes problems for language mappings where some additional operations (like less-than or equal-to) must be defined for these types. In order to prevent different language mappings adding different (conflicting) restrictions, the IDL spec should define this.

One approach to this would be that each building block should define how its types can (or can't) be used in maps. For example: everything in core data types is allowed; interfaces are not allowed; valuetypes are not allowed; etc.

The section Imports contains

The effects of an import statement are as follows:

• [...]
• Importing a name scope recursively imports all name scopes nested within it.

This looks counter intuitive to me.

Example:

module commontypes {
   module nested1 {
      enum RGBColor { RED, GREEN, BLUE };
   }
   module nested2 {
      enum TrafficLight { READ, YELLOW, GREEN };
   }
};

What happens if another module does "import commontypes"?

If, as the standard says, all name scopes nested within "commontypes" are recursively imported then this would lead to errors:
The enum values RED and GREEN would be directly visible and would be in conflict with each other.

The 'Group of Annotations General Purpose' includes the @autoid annotations which can optionally specify a HASH as in @autoid(HASH).

To be useful this must be augmented with the @hashid("MyString") annotation that allows an ID to be explicitly assigned by computing the hash of a string using the same algorithm that @autoid(HASH) uses.

ptc/19-07-02 section 7.2.4.2.1 defines the mapping of sequences of basic and non basic types in terms of Java interfaces.
However, the classes implementing the interfaces are not defined.
The implementation classes are required for actual programming.
If it is intended that the user shall provide own implementations then this should be expressly stated.

7.4.15.4.2 on p.101 contains the rule

(225) <annotation_appl> ::= "@" <scoped_name> [ "(" <annotation_appl_params> ")" ]

The nature of the EBNF notation leaves room for interpreting that between the @ and the <scoped_name> there could appear spaces, tabs, or even comments.

On the other hand, 7.4.15.4.1 on p.100 contains:

(220) <annotation_header> ::= "@annotation" <identifier>

Here, it is clear that @annotation shall be treated as a single token without intermittent characters between @ and annotation.

I propose adding a clarification in the explanations at the beginning of p.102 (following rule 227):

Applying an annotation consists in prefixing the element under annotation with:

• The annotation name ( <scoped_name> ) prefixed with the at symbol( @ ), also known as commercial at. There shall be no intermittent spaces, tabs, or comments between @ and <scoped_name>.

The last sentence is my proposed addition.

Table 7-13 (Integer types) should have a little bit wider column 1 and the font size "See Building Block Extended Data" should match the other font in this table