The argument val of the method op2 of interface A is a basic type, so should be passed as int32_t by value in the example code

All methods having a return value should return by value, that is what the IDL4toCPP language mapping specifies, not as reference

Tthe traits template should be specialized on the <Bitmask> type, not on the <Bitmask>Bits type

The spec should also mandate that a default constructor is there which initialized all members to its default, so `MyStruct()` as constructor should be there

The mapping doesn't show or mention any initialization of the bitfields, which means that they get a random value at runtime, the spec should describe and show that the bitfields are all zero initalized

As struct/bitset support inheritance, at the moment there is a base a IDL::traits<>::base_type should be avilable for template meta programming

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

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?

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?

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

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