In the submission document, Table 21 "IDL Built-in Annotations" does not list where the annotation @hashid can be applied.

Also, the @id annotation is can be applied to both Structure members and union members (except union discriminator), so it should be moved to the second row on the table.

This Issue was not resolved in this Task Force and was automatically deferred to the next Task Force

A big effort have been done to remove CORBA dependency from the IDL2C++11 mapping, but it still specifies a CORBA semantic to the IDL
interfaces and user exceptions. In 6.6.4, it is said "Conceptually, the Object class in the CORBA module is the base interface type for all objects;" this assertion breaks all that efforts. I think the semantic of IDL interfaces should be abstracted by defining a middleware-independent Object type as the super type of all IDL interfaces, it could be IDL::Object. Likewise, CORBA::UserException and CORBA::SystemException could be abstracted by defining IDL::UserExeption and IDL::SystemException.
Looking to the IDL3.5 specification, it is true that this specification is still tied to CORBA, but special care has been done to separate between the syntactical construct and its semantic. For instance, it is said 'See the CORBA 3.2 specfication Section 10.2 “Semantics of Abstract Interfaces” for CORBA implementation semantics associated with abstract interfaces.'. It means that there could be other semantics than CORBA.
I would suggest the following changes in the IDL2CPP11 specification :

• To introduce IDL::Object, IDL::LocalObject, IDL::UserExeption and IDL::SystemException.
• To not consider an IDL interface as a CORBA Object and rephrase section 6.6.4 accordingly.
• To not consider a user exception as a CORBA exeption and rephrase section 6.19 accordingly.
• To group all CORBA-dependent mappings and APIs in one section "CORBA mapping". This section would include :
  6.16 Mapping for the Any Type
  6.17 Mapping for Valuetypes
  6.18.1 Abstract Interface Base
  6.21 TypeCode
  6.22 ORB
  6.23 Object
  6.24 LocalObject
  ... until 6.28

Deferred

Deferred to future RTF

In 6.12 we define:

An unbounded sequence is mapped to a C++ std::vector.

For example a sequence of octets is now not optimal, in order for implementations to optimize sequences but users not to harm we propose to change this definition to

An unbounded sequence is mapped to a type delivering C++ std::vector semantics.

Deferred

Deferred

There are two main motivations:

(1) Performance: IDL types may be large and not all IDL types may have C++11 mapping with efficient move constructors. For example, an IDL structure containing an array does not have an efficient move-ctor. Current mapping for an IDL struct type (section 6.13.1) requires an explicit constructor accepting values for each member by value in the order they are specified in IDL. Although this method is sufficient in most cases, it is not optimal. Particularly, the types that don't support efficient move-ctor.

(2) Usability: Often C+11 standard library containers could be constructed using several alternatives. For instance, a string member in a struct may be constructed using any of its 9 constructors or a vector may be constructed using any of its 7 constructors. Currently, the IDL2C+11 specification allows construction of members of a structure using only two kinds of constructors: copy-ctor and move-ctor. (due to the pass-by-value rule mentioned above)

Resolution: The IDL2C++11 mapping of structures could be enhanced to construct large objects in-place. Provide a way to construct the member objects of a struct in-place using a perfect-forwarding constructor. The intent is to support all the ways of constructing all the member objects from the constructor of the parent object. Moreover, a perfect-forwarding constructor may eliminate the need for a move, which may lead to some performance improvements.

The solution relies on an idiom known as piecewise_construct idiom. It relies on a perfect-forwarding constructor that takes as many tuples as there are members in a struct. Each tuple encapsulates the parameters to construct one member. Tuples are needed because member ctor could take several parameters and the user may be interested in using them. For instance, using an allocator for std::vector. The user of the struct calls std::forward_as_tuple for each member object to group the parameters in a tuple. The special constructor simply forwards the tuples to the respective member.

The C++ standard library uses this idiom for std::map and std::unordered_map to construct complex objects in-place using the emplace operations. However, more general uses have been identified: http://cpptruths.blogspot.com/2012/06/perfect-forwarding-of-parameter-groups.html

Deferred

Without specific spec wording from someone who has implemented it, I don't think we can standardize this feature.

The mapping for constants should use uniform initialization in section 6.8 instead of using the assignment. The code
const std::string name = "testing";
static constexpr float pi = 3.14159;

Should be
const std::string name

;
static constexpr float pi

;

IDL constants should use C++ direct list initializaiton

When IDL constants are mapped to C++, they become namespace or class scoped const (or constexpr) objects. Use direct list initialization to give these objects values.

The DDS-XTypes specification extends the IDL type system which will be integrated into the IDL4 specification. The IDL2C++11 mapping should be extended with a new section describing the support for the IDL map type.

Import the mapping of IDL Map from XTypes 1.2

XTypes 1.2 (beta) ptc/17-03-06 section 7.5.1.3.4 maps the IDL Map type to "Modern C++", that mapping can be used by this spec directly

The code example as part of 6.18.7.2 has:
ColorValue& operator=(const Color&);

but this should be
ColorValue& operator=(const ColorValue&);

Fix argument type of copy assignment operator in 6.18.7.2

Looks to be a typo in the original spec. The class name is ColorValue which should be used here

In section 6.7.1 in the 4th paragraph the CORBA::make_reference<> is mentioned, but it ends using "using perfect forwarding". Where this is probably the best way to implement this, it shouldn't be mandated by the specification. Propose to remove "using perfect forwarding" from the text of this paragraph

Relax requirement for perfect forwarding in 6.7.1

The C++ idea of "perfect forwarding" doesn't need to be specified here. An implementation may decide to use it.

Because of the mapping of Exception to something derived from std::exception where is a possible conflict when the user has an exception member with the member name "what" because std::exception provides an operation what(). We propose to change the start of section 6.20 to the text below instead of the first two bullets currently in the specification

An OMG IDL exception is mapped to a C++ class that derives from the standard UserException class. Each OMG IDL exception member maps to a set of corresponding member methods as described in “Mapping for Structured Types” on page 14. When the IDL exception member identifier is "what", the string “cxx” is prepended to the identifier to resolve a conflict with the std::exception what() operation.

The copy constructor, move constructor, copy assignment operator, move assignment operator, and destructor automatically copy, move, or free the storage associated with the exception. For convenience, the mapping also defines an explicit constructor with one parameter for each exception member in the order they are specified in IDL—this constructor initializes the exception members to the given values. The default constructor initializes all members to their default values as described in “Mapping for Structured Types” on page 14.

Possible name conflict involving "what" and exceptions.

See Johnny's comment on issue #4

In 6.14.1 (mapping for struct type) the second sentence is

Additionally to the methods as described in “Mapping for Structured Types” on page 14 an explicit constructor accepting values for struct each member in the order they are specified in IDL.

This should be

Additionally to the methods as described in “Mapping for Structured Types” on page 14 an explicit constructor accepting values for each struct member in the order they are specified in IDL.

The order of "struct" and "each" should be swapped

Edit section 6.14.1 for clarity

Updated prose description of mapped struct, C++ remains unchanged.

For SystemException class on page 36 mentions

const int32_t& minor() const;
void minor(const int32_t&);

But this is a basic type which we pass by value. Also minor should be an uint32_t, the code should list

uint32_t minor() const;
void minor(uint32_t);

Also the CompletionStatus is returned by value, no need for a const, so change

const CompletionStatus completed() const;

to

CompletionStatus completed() const;

As last the constructor

explicit SystemException(int32_t minor, CompletionStatus status);

Should be

SystemException(uint32_t minor, CompletionStatus status);

SystemException updates

Proposed resolution is included in Issue #2 description

The specification mentions that besides a namespace level swap a specialization of std::swap<> has to be provided, but that shouldn't, see http://en.cppreference.com/w/cpp/concept/Swappable. Only a namespace level swap should be enough. This impacts the text of section 6.7.1, the example and text of 6.14.1, example of 6.14.2

Remove std::swap requirement

Overload swap() in the appropriate namespace, do not do anything with std::swap.