The following typo error exists in section 6.21:

Following text in spec
... TypeCode reference constants, <type> refer to the local name of the type ...
should be
... TypeCode reference constants, <type> refers to the local name of the type ...

Refs #2877

The V1.0 spec doesn’t have this typo, so closing this with no change
Disposition: Closed

The current mapping for struct violates the RFP requirements that mandated compatibility with the DDS-PSM-Cxx. Areas of incompatibilities include the use of the C++11 array type and the use of move operators.

The revised submission explicitly mentioned that this requirement was not met because
this is a C+11 language mappping, not focusing on C+03 which is the focus of the
DDS-PSM-Cxx. Also in the mean time the DDS-PSM-Cxx has adopted the same
mapping for arrays/enums and mentions move semantics when C++11 support is
available. Given the fact this is a C++11 language mapping this issue has been closed
without a change.
Disposition: Closed, no change

The specification defines IDL::traits<A>::factory_type as C++ trait for getting the base C++ class for the factory. It does lack a trait for passing a reference for a certain factory around.

To be added:
For a valuetype A, a strong reference to its valuetype factory is known as IDL::traits<A>::factory_ref_type. The weak object reference to its valuetype factory is known as IDL::traits<A>::weak_factory_ref_type.

Refs #2727

Accepting this addition as proposed

The description for Any lacks the support for implicit widening as it was available with the C++ mapping. Proposal is to add implicit widening to section 6.16.3. The following text is proposed to be added:

Any object reference, valuetype reference, or abstract references has to extractable as its base reference type from an Any.

Also in the last sentence of 6.13, any as bold should be Any with a capital A

Refs #2873

Accepting this addition as proposed with the remark that 6.13 should be 6.17.3 and it
talks about the Any C++ class, not the any IDL type.

With the new IDL2C+11 mapping we can't create object references with new, we have to use the CORBA::make_reference<> factory method. In a servant we can use _this to get a reference to itself, but that is not available for local objects. With the old C+ binding people could just use the C++ this to get a _ptr to a local object, but that is not possible with the C++11 binding in general.

Proposal is to add to 6.24:

In order to get an object reference referring to an already created local object the _this() method must be used.

In the code part add as method

class LocalIF

;
Refs #2804

Accepting this addition as proposed

Section 6.17.2 is titled "Constructors, Assignment Operators, and Destructors" but does not say anything about assignment operators albeit the title promises to do so.

The following examples seems to indicate that both assignment operators are supposed to be deleted. This should be spelled out.

It also seems as if the maiing for interfaces as of 6.6 is intended to create class types with deleted copy/move assignment operators. This should also be made more clear.

Accepting this issue as proposed

Section 6.5 (Table 6.1) loosely describes that the OMG IDL integer types are mapped to "a basic C++11 type" denoted by

int16_t int32_t int64_t uint16_t uint32_t uint64_t uint8_t

It doesn't really say, what these typedefs are supposed to be. Furthermore 6.5 (Table 6.2) describes the names

int16_t int32_t int64_t uint16_t uint32_t uint64_t uint8_t

as "keywords from the C++11 specification (ISO/IEC 14882:011)".

Surely there are no such keywords in C+11 (nor in C11 or C99) and never had been. What C+11 inherits from the C99 library specification are the typedefs

std::int16_t std::int32_t std::int64_t std::uint16_t std::uint32_t
std::uint64_t std::uint8_t

from header <cstdint>, but those are not keywords and they are library components that belong to namespace std. I think that the specification of the basic integer type mapping (6.5) intends to refer to these typedefs from <cstdint>, but this should be made clear in 6.5.

Also, section 6.30 should not declare them as C+11 keywords, even though these names need to be protected by a cxx prefix as described by 6.2. Presumably a better name is needed (e.g. "protected C+11 names" or some such)

Accepting this issue as proposed

Given the specification of the class template Fixed provides

operator int64_t () const;
operator long double() const;

and

bool operator!() const;

This allows to test some Fixed instantiation within a boolean context as in a useful way as follows:

typedef IDL::Fixed<5,2> F;
F f = ...;
if (!f)

will cause an ambiguity error between the two conversion functions to int64_t and long double. User code is required to write the obfuscated form

if (!!f)

to realize the same thing. This is unfortunate and there is a simple means to solve this problem: The specification should add

explicit operator bool() const;

to the class template synopsis with the same semantics as negating operator!

Accepting this issue as proposed. Also during the discussion it was proposed to add a
namespace level to_string

The example in the middle of the page starts with:

// C++
S s =

;

or

// C++
S s = S

;

Accepting this issue as proposed

Given interface T the specification defines IDL::traits<T>::narrow as a way to narrow to T. As convenience it also defined T::_narrow. The issue is that T::_narrow is implicitly linked to IDL::traits<T>::narrow and can cause confusion and possible misuse when other traits are added for more specific traits. We propose to remove T::_narrow from the specification completely, users must just use IDL::traits<T>::narrow

Accepting this issue as proposed

The specification defines IDL::traits<> as type trait, but uses it only for reference types.

We propose to extend IDL::traits<> as generic type trait for IDL2C++11. This type trait delivers traits with information coming from IDL.

For example object reference traits it can also deliver local and abstract as traits, which are booleans that indicate whether the IDL type was local or abstract.

For sequence we can add traits indicating the type of the element and in case of bounded sequences the bound.

The proposal is to add a new paragraph which describes the IDL type traits that are all available as part of IDL::traits<> for a specific IDL type.

Ref #2802

Extending the IDL::traits<> with more types for template meta programming will be useful
for the users that would like to program C++11 templates using the IDL defined types.
Therefor a new set of type traits will be added to the specification.

In section 6.25.6, in the line:

This guarantees that the POA skeleton class inherits only one version of each operation, and also allows optional
inheritance of implementations. In this example, the implementation of interface B reuses the implementation of interface
A:

The font of A should also be IDL type just as B

Accepting this addition as proposed