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.

Issue was added to the wrong RTF

This issue is not in IDL-to-C++11.

The C++11 IDL language mapping for IDL struct datatypes was changed to a Java-style getter & setter interface. This should be reverted for the following reasons:

1. The original struct mapping (just use data members) performs better at compile and runtime. The new mapping compiles slower by changing each data member to 4! different accessor functions, and at runtime is slower due to the need for the function call. (Modern compilers cannot optimize this call away without global optimization, which is not generally available in C++ implementations, or else the accessor functions must all be defined inline for the compiler to optimize away the function call.)

2. Java style getter and setter interfaces are not considered good C++ style by the experts. https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#c131-avoid-trivial-getters-and-setters

3. The change breaks massive amount of user code for no benefit.

Structure mapping shouldn't change within a minor revision of IDL-to-C++11

Keep in mind that IDL-to-C++ and IDL-to-C++11 are independent specifications. In cases where IDL-to-C++11 takes a different approach to mapping the same IDL features, this isn't a "change" from the spec's point of view.

However, I'm sympathetic to the notion that it could be a "change" from an implementer/user's point of view as a single IDL translation tool that previously used just IDL-to-C++ could, in a new version, use IDL-to-C++11 (either exclusively or as an option). Since I help maintain some IDL translation tools that do this, I've had to deal with this myself.

One thing to note is that nothing in IDL-to-C++11 prevents the implementation from providing public data members in mapped structs. Unfortunately the names of those data members would be non-standard. Also, as described in the comments on the parent issue, direct data member usage makes upcoming IDLv4 features like @min/@max harder to support.

The fixed type was changed from the old C++ mapping, removing the non-template Fixed class and mandating that Fixed be implemented as a template. These changes disrupted the careful design of Fixed support for C++ in several ways:

1. There is now no information or guidance about what type is used when declaring a fixed constant in IDL.

2. The original specification was careful to not mandate whether the C++ mapping used a template definition to enforce constant digits and scale values for fixed point data defined in IDL, yet specifically states that the user should only use the typedefs generated by the IDL compiler Thus the current specification unnecessarily limits implementation choice for fixed point support for no useful implementation purpose.

3. Removal of the non-template Fixed class makes it harder for the implementation to meet the "double precision (62 digit)" arithmetic guarantee.

The C++ mapping for Fixed should be restored use the language of the old C++ 1.3 language mapping.

Updates to the mapping of the IDL Fixed data type

Change the mapping of the IDL fixed type data to allow some more implementation flexibility and familiarity from the IDL-to-C++ mapping.

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

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