This chapter says:

The Fixed(std::string&) constructor converts a string representation of a fixed-point literal, with an optional leading sign (+ or -) and an optional trailing ‘d’ or ‘D’, into a real fixed-point value.

But there is no constructor that accepts a non-const std::string&, the text should say

The Fixed(const std::string&) constructor converts a string representation of a
fixed-point literal, with an optional leading sign (+ or -) and an optional trailing ‘d’ or ‘D’, into a real fixed-point value.

Correct the spec text to match the source code

Add the missing "const" as described in the issue.

Double "to to" in the first sentence:

IDL bitset types are mapped to to C++ structs that meet the C++11 requirements for aggregate initialization.

Should be

IDL bitset types are mapped to C++ structs that meet the C++11 requirements for aggregate initialization.

Fix typo

As per issue description

The spec should mention how the IDL4-mentioned annotations impact the mapping, I think the spec should list at least @value, @default_literal, @default, @range @min @max @bit_bound @external

See IDL4 to CPP and the IDL4 spec itself

Add mappings for some more IDL 4 Standardized Annotations

New mappings for @value, @default_literal, @default, and @bit_bound – in each case drawing from uses in the beta IDL4-to-C++ mapping and/or XTypes.

In the specification an addition was made about the default argument when the union member has multiple legal discriminator values:

Union members associated with the "default" label and those associated with multiple labels may have multiple legal discriminator values. For these members, the modifiers (those that return void) have a second parameter which has the discriminator's type. This parameter has a default argument. For members associated with multiple labels, the value of the default argument is the value of the case label that appears first in IDL. For members associated with the default label, the value of the default argument is an implementation-defined value that selects the member.

There is nothing in the text that describes what happens when a discriminator value is passed which doesn't belong to the member, this is implicitly in the example code further down "u.obj(a, 2)", but this should be explicit in the text also, passing a not allowed discriminator should result in a BAD_PARAM exception

Add description of error handling for 2-parameter union modifier functions

To be consistent with the existing parts of the spec, make it clear that invalid parameters result in a BAD_PARAM exception.

Instead of `VariableExt(const Variable&, bool);` it should be `VariableExt(Variable, bool);` so that in the implementation we can use std::move, this is as all complex types are passed into the constructor of a struct

In example code, function signature of constructors is non-normative

In section 6.31.3 make it clear that the specific types of the constructor parameters (if they use pass by value or pass by const-reference) is up to the implementation.

The bitmask mapping is very basic, it doesn't give any type safety or more modern API. The spec should be improved, the <X>Bits type should be removed, only one type should be used. Also when there are multiple bitmasks with the same bitfield name they could result in a name clash. Maybe map to a enum class and add the operators ~,|,^,& for the enum class as inline operations to modify the enum class as a bitmask. At that moment the Bit type can be removed.

When time permits I will make a proof of concept for TAOX11

Defer breaking change to the bitmask mapping

The existing mapping in IDL-to-C++11 is based on DDS XTypes where it has been in a formal standard for a number of years.
There are certainly reasons to have a mapping that makes better use of the C++ type system, but this would come at a cost in terms of divergence from OMG precedent.

For some use cases it would be more efficient to map a IDL map to a std::unordered_map (see https://en.cppreference.com/w/cpp/container/unordered_map), maybe standardize an annotation which can be used to override the mapping to std::map to the type as specified by the annotation?

Defer

Other languages have similar issues like using TreeMap or HashMap in Java.

Defer resolution on this until standard annotation can be provided in the IDL 4 spec or the IDL Working Group has a common approach to use across language mappings.

using M2 = IDL::bounded_map<std::string, T, 20;

should be

using M2 = IDL::bounded_map<std::string, T, 20>;

Typo is not in base document

ptc/21-11-02 doesn't have this typo

The section says:

"For all primitive types, enums, and
reference types, an in argument A of type P, that argument is passed as P. For all other types, an in argument A of type P is
passed as const P&. For an inout and out argument it is passed as P&. If we return a type of P, it is returned as P."

This is the only use of "primitive types" in the spec. "Basic Data Types" should be preferred. Would suggest:

"For all Basic Data Types [link/ref to 6.6 Mapping for Basic Data Types], enums [link/ref to 6.9 Mapping for Enums], and
reference types [link/ref to 6.7.1 Reference Types], an in argument A of type P, that argument is passed as P. For all other types, an in argument A of type P is
passed as const P&. For an inout and out argument it is passed as P&. If we return a type of P, it is returned as P."

Update text in Arg Passing to refer to Basic Data Types

Update as specified in parent issue

The spec defines the type trait bit_bound as `std::integral_constant<uint32_t, b>`, but as bit_bound is maximal of 64, this could be `std::integral_constant<uint8_t, b>`

Update type used for bit_bound in bit mask traits

The integral_constant template from the C++ standard library should be instantiated with uint8_t instead of uint32_t

The bit_bound annotation can be applied to the enum, so the bit_bound and underlying_type traits should also be added to the enum

Add type traits for enums

Including this in the resolution to CPP1117-13.

The specification should specify the mapping of @optional, maybe maybe to IDL::optional which could be an using of std::optional with C+17, only for C11/C+14 at that moment the API of IDL::optional should be specified

Map optional struct members

Unlike other standardized annotations that are impact the middleware platform, the IDL @optional annotation impacts the language mapping.

The @extensibilty(FINAL) or @final annotation is one of the new annotations in IDL4.2, see 8.3.16 of IDL4.2. Should the generated class for a struct/union which is annotated with @final be generated as a C++11 final class or not? So

struct Foo final {}

or

struct Foo {}

Extensibility annotations do not impact the language mapping

The concept of type extensibility is defined in IDL4.2 as "specifying how
the element is allowed to evolve." The language mappings determine how each IDL source file is mapped. In terms of this "evolution," the mapping is just capturing a single point in time. Neither of the IDL4-specific mappings (C# or Java) map extensibility to a programming language feature.

For template programming it could be helpful to have a IDL::traits<>::bit_bound trait of type std::integral_constant which returns the bit_bound set in IDL for a bitmask

Add traits member specification to Bit Masks section

Specify the bit_bound member of IDL::traits for Bit Masks

The example code has

OBV_Example (int16_t, int32_t, std::string, IDL::traits<Example>::ref_type;

But this is not correct, it should be

OBV_Example (int16_t, int32_t, std::string, IDL::traits<Example>::ref_type);

Fix invalid example code

A closing parenthesis was missing from the example code.

For creating a client side reference the specification uses currently CORBA::make_reference but this logic is not really CORBA specific and in a LwCCM system which only uses local interfaces the usage of CORBA is polluting user code. One of the key concepts of IDL to C++11 is that the user doesn't need to remember any special naming rules so we don't want to tie a factory function to some implementation name. The IDL to C++11 specification already uses the IDL::traits<> concept which is specialized based on the IDL type. We propose to extend the IDL::traits<> for interfaces/valuetypes for a make_reference factory method so that user code given an interface A can create an object reference using IDL::traits<A>::make_reference.

In the specification we propose the following changes:
6.7.1, replace CORBA::make_reference with IDL::traits<>::make_reference
6.18.7.1 replace CORBA::make_reference <StringValue> with IDL::traits<StringValue>::make_reference
6.18.10.2 replace CORBA::make_reference<> with IDL::traits<>::make_reference
6.25 replace CORBA::make_reference<> with IDL::traits<>::make_reference and CORBA::make_reference <MyLocalIF> (); with IDL::traits<MyLocalIF>::make_reference ();

The CORBA::make_reference() can be easily kept by an implementation for backwards compatibility but this proposal enables the user to write code that is more CORBA independent

Move make_reference into the traits class

The CORBA::make_reference function template as currently specified is a top-level member of the CORBA namespace. Some uses of IDL (and this mapping) are non-CORBA, for example lightweight CCM/UCM or DDS. This change moves make_reference into the traits which lives in the IDL top-level namespace.

Page footers look like:

C++11 Language Mapping, v1.4 iii

This issue is a duplicate of issue 5

Apols for not checking before raising.

The spec says the following:

The constructor which “accepts values for each struct member in the order they are specified in IDL” also accepts, as its first parameter, an object of the mapped base type (passed by const reference)

As user of a IDL inherited struct I would expect I can pass the members of the base type after the members of the inherited struct, not an instance of the base type. So, when there is a 2DPoint with members X and Y and a 3DPoint derived from that with member Z, I would expect to call a constructor with Z, X, Y .

Also the spec should require that a the inheriting constructor concept should be supported (see https://arne-mertz.de/2015/08/new-c-features-inherited-and-delegating-constructors/), so we can initialize a 3DPoint with only X and Y where Z receives its default value.

The remark of "passed by const reference" which is now part of the spec should be removed, that is an implementation decision, it could be that pass by value is more performant (see for example https://abseil.io/tips/117)

An example would be really helpful in this case, provide an example IDL construct with the example C++11 code expected.

Update struct inheritance mapping

The section "Structures with Single Inheritance" needs a minor update and an example

In the footer it says "C++11 Language Mapping, v1.4", but it should be "C++11 Language Mapping, v1.5"

No RTF change needed

Footer is correct in formal/21-05-01 (IDL-to-C++11 1.5).

The IDL to C++11 tries to prevent the user from remembering all kind of special naming rules. The spec now uses "<Bitmask>Bits" but that is something we want to prevent, we propose to use a IDL::traits<>::bits which can be used as a generic way to use this special "<Bitmask>Bits" type in code. It could happen that there is also a user type "<Bitmask>Bits" in IDL, how is this now handled? When IDL::traits<>::bits is used the naming of the implied type is an implementation decision

Also a C++11 strong enum should be used instead of an old enum to prevent the enumerator values to pollute the containing namespace, the current approach doesn't work when there are 2 bitmasks with the same set of enumerators, the code below doesn't compile

enum MyBitMaskBits : std::uint8_t

;

Update bitmask IDL traits

Update IDL traits for bitmask types.

We propose to replace std::uint8_t in the example code with uint8_t, for all integer types the spec doesn't list the std namespace

Duplicates issue 8

Duplicate of issue 8

Why is bitset inheritance not mapped to struct inheritance, that would simplify the code for BitSet2 in this example.

No change needed

Using struct inheritance would mean that the last member of the base couldn't share the same byte with the first member of the derived. Essentially this is a difference between what C++ inheritance of structs means when structs have bitfields and the semantics defined by IDL.

The destructor should change from

virtual ~V_factory();

to

~V_factory() override;

The virtual is redundant, that is already in the base

Update the code in 6.18.10.2

Modern C++ usage is to prefer the override keyword to virtual.

We propose to replace std::uint8_t in the example code with uint8_t, for all integer types the spec doesn't list the std namespace

No change needed

The identifier uint8_t is defined by the ISO C++ standard as a member of namespace std, so this spec uses the namespace as well.

In the example code the destructor should change from

virtual ~ColorValue();

to

~ColorValue() override;

Update the code in 6.18.7.2

Modern C++ usage is to prefer the override keyword to virtual.

For the switch of unions, the C++ mapping uses the name _d.
It would be desirable to permit names that reflect the users' application domain.
Example:

  enum environment_t { air, water, land };

  union env_info_t switch (@switchname("environment") environment_t) {
    case air:
      air_info_t air_info;
    case water:
       [...]
  };

The @switchname annotation would cause a getter/setter of the given name to be generated in addition to the _d() accessors.
In the above example:

  void environment(environment_t);  // alias for _d(environment_t)
  environment_t environment() const;  // alias for _d()

Depends on an IDL spec change

Defer until the IDL 4.3 RTF resolves IDL43-42.

IDL4.2 defines in section 8.3 a set of standardized annotations where it looks some of them impact the IDL to C++11 language mapping like @optional, @final, @range, @default and maybe others. There should be a new paragraph in the IDL to C++11 language mapping which describes how these standardized annotations map to C++11, like @optional to std::optional, @final to final, etc

Defer work on this issue

IDL 4.2 has 24 Standardized Annotations which vary widely in terms of their applicability to a language mapping. Since other RTF issues request specific annotations that are more urgent, defer this broad issue to the next RTF.

In the TIE chapter replace ServantBase with Servant, ServantBase is from the old IDL to C++ spec, in C++11 this should be Servant, see CPP1115-2

Replace ServantBase with Servant

The term ServantBase appears in section 6.26.8, this is a holdover from the original IDL-to-C++ mapping. The term Servant should now replace it.

C++11 introduced the "using" keyword (see https://en.cppreference.com/w/cpp/language/type_alias) as alternative way to specify a type alias. In terms of C++11 support usage it would be a good thing to update all example C++11 code within the specification to use "using" instead of "typedef"

Use the C++11 type alias feature in examples

C++11 has type aliasing with the "using" keyword, which is typically preferred to using the "typedef" syntax inherited from C.

The IDL to C++11 language mapping section 6.31 should be extended for struct inheritance as it is now part of IDL4 (Building Block Extended Data-Types)

Support for struct inheritance

Add mapping for IDL4 struct inheritance

Add support for int8 which is a new type, the other (u)int(8/16/32/64) are just aliases so don't need to be in the language mapping

Add int8/uint8 mapping

Add a new subsection in 6.31 for IDL int8/uint8

The V_factory should have deleted assignment/copy so add
private:
V_factory (const V_factory&) = delete;
V_factory (V_factory&&) = delete;
V_factory& operator =(const V_factory&) = delete;
V_factory& operator =(V_factory&&) = delete;

In the text change
Each generated factory class has a protected virtual destructor, a protected default constructor.
to
Each generated factory class has a protected virtual destructor, a protected default constructor, deleted copy/move constructors, and deleted copy/move assignment operators

Add deleted special member functions to type-specific value factories

Use the "= delete" feature of C++11.

ValueBase has only a protected copy/move copy constructor to allow a derived class to make a copy, the assignment operators are deleted, because of this also for a valuebox the assignment operators should be deleted, so the 3rd bullet should be updated from

Protected copy and move assignment operators

to

Private deleted copy and move assignment operators

And in the code example

ColorValue& operator=(const ColorValue&);
ColorValue& operator=(ColorValue&&);

to

ColorValue& operator=(const ColorValue&) = delete;
ColorValue& operator=(ColorValue&&) = delete;

Duplicates issues CPP1115-5

This appears to be a duplicate

The valuebox created should be using final, so add to the bullets of 6.18.7.2 a first bullet saying "Must be final" and change in the code
class ColorValue : public ValueBase
to
class ColorValue : public ValueBase final

Use the C++ final specifier on value box classes

Make use of the "final" capability of C++11

ValueBase has only a protected copy/move copy constructor to allow a derived class to make a copy, the assignment operators are deleted, because of this also for a valuebox the assignment operators should be deleted, so the 3rd bullet should be updated from

Protected copy and move assignment operators

to

Private deleted copy and move assignment operators

And in the code example

ColorValue& operator=(const ColorValue&);
ColorValue& operator=(ColorValue&&);

to

ColorValue& operator=(const ColorValue&) = delete;
ColorValue& operator=(ColorValue&&) = delete;

Value box classes shouldn't be assignable

Update to work with ValueBase

ValueFactoryBase should have deleted assignment/copy operators so add to the code part

private:
ValueFactoryBase (ValueFactoryBase&&) = delete;
ValueFactoryBase (const ValueFactoryBase&) = delete;
ValueFactoryBase& operator =(const ValueFactoryBase&) = delete;
ValueFactoryBase& operator =(ValueFactoryBase&&) = delete;

Add deleted special member functions to ValueFactoryBase

Use the C++11 "= delete" feature for ValueFactoryBase.

Any C++11 operation in the spec which uses override shouldn't have virtual, that is redundant and shouldn't be done, so for example

virtual void val2 (int32_t) override;

Should be

void val2 (int32_t) override;

Easiest is to search for override and check that any operation that has override doesn't have virtual

Remove uses of the C++ virtual keyword that aren't needed

Member functions declared with "override" should not also have "virtual"

The operation _default_POA currently declared as

IDL::traits<PortableServer::POA>::ref_type _default_POA()

Should be

IDL::traits<PortableServer::POA>::ref_type _default_POA() override

Also the formatting of the constructor of the TIE template should be changed, hard to read. Initializing the members could use std::move so change

: tied_object_(t), poa_(poa)

to

: tied_object_(std::move(t)), poa_(std::move(poa))

Updated code for Delegation-Based Interface Implementation

Update code to reflect C++ best practices

The IDL to C++11 language mapping section 6.31 should be extended for bitset/bitfield/bitmask from IDL4 (Building Block Extended Data-Types)

Bitset and Bitmask mapping

Bitsets and bitmasks are "top-level" IDL4 extended data types that can each be mapped to C++11.

The current IDL to C++11 language mapping only describes an inheritance based interface implementation in chapter 6.26.6. The IDL to C++ language mapping also described a delegation based implementation. We propose to add a delegation based implementation to the IDL to C++11 specification.

I will attach a proposal new chapter 6.26.7, only the formatting of IDL and C++ types has to be done in the final document, especially types in the text itself need to be formatted. In the first paragraph there is a number 126, that has to be updated.

Mapping for implementing interfaces via delegation

This issue adds the mapping for implementing interfaces via delegation, a feature of the IDL-to-C++ mapping that has been lacking in this spec.

The C++11 mapping of an IDL union seems to follow that of the classic C++ mapping, where the discriminator does not only have a getter-operation, but also a setter operation. This operation has been added for situations where more than one case label applies to to the same union branch, and the setter operation for that union branch implicitly sets the discriminant value to the first case label that was specified. If you want to pick another value, you should do so by invoking the setter function for the discriminant.

However, this setter operation is confusing to many users, and some seem to think you need to use it every time you passed a value into a branch different than the current branch. On top of that. it seems cumbersome to have to make two separate method invocations to request a single modification that is intended to set branch value and corresponding discriminator value atomically.

Much better would be to take the route that has been adopted in the Java language mapping for the union: if there is more than one case label that applies to a union branch, you add an overloaded setter method for that branch that does not only allow you to pass the value for that branch, but also the value for the discriminator. This overloaded setter function will than validate whether the discriminant value you pass actually applies to the branch that you are trying to set.

Unions: Provide a way to set both the discriminator and value at the same time

Enhance the mapping of IDL union to allow setting the discriminator at the same time a new union element value is provided. This change maintains compatibility for applications written to the current spec version.

Compared to V1.2 in 6.7.6 four bullets before IDL::traits<A>::narrow(ap) got removed

Make part of 6.7.6 a bulleted list

This was somehow lost between v1.2 and v1.3.

The OBV_Example constructor has multiple arguments and shouldn't be explicit. Also a closing ) is lacking from the example code. The operations for val2 should also use "override"

Update OBV_Example class in 6.18.4

Updates as suggested, making the C++ example code consistent with the prose of 6.18.2 and common conventions.

The operation "virtual int16_6& val1() = 0;" is not aligned correctly in the code example

Fix C++ code in 6.18.4

Fixing a minor typo/formatting bug in this section.

Section 6.11 on page 11, 2nd paragraph:

Implementations of the bounded wide string are under no oblication to perform a bounds check [...]

obligation

Table 6.10 on page 14, bottom row, right column

dimensions

std::integral_constant type of value_type uint32_t indicating the number of dimensaions of the array

[...] dimensions of the array

Section 6.18.7.2 page 30 top, continuation of code from p.29

protected:
      ColorValue();
      xplicit ColorValue(Color);

explicit ColorValue(Color);

Section 6.19.1 on page 34, code for class AbstractBase

class AbstractBase {
      public:
            virtual IDL::traits<Object>::ref_type _to_object();
            virtual IDL::traits<ValueBase>::ref_type _to_value();
      protected:
            AbstractBase();
            bstractBase(const AbstractBase&);

AbstractBase(const AbstractBase&);

Section 6.22.2 on page 40 top (code continued from p.39)

            int16_t fixed_scale() const;
            Visibility member_visibility(uin32_t index) const;

Type of index argument should be uint32_t.

Fix typos

The submitted issue (CPP1114-7) lists a few other typos, but those are already fixed in formal/18-01-06.