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;

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

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

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

A link is broken, it mentions:

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

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

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.

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

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

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

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

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

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

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

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

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

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

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

The section is silent on maps.

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

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

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

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

MyTemplate<double, 5.0> x;

For instance is this legal:

struct S

;

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

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

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.

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

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

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.

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.

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.

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

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

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

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.

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?

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

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.

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

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

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

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?

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?

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

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

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

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)

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

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

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

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