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

For struct/exception/valuetype the spec describes that a constructor accepting values for all members has to generated as explicit constructor, but it only has to be explicit when there is one (1) member, when there are >1 member the constructor doesn't need to be explicit. This has to be updated in the text and examples

Reporter of the Issue has asked for it to be withdrawn

Closing this one by request of Reporter.

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.

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.

Flexible mapping for sequence and map types

Allow implementations more flexibility: in certain cases when the spec currently requires use of a C++ standard library type, the implementation should be able to use a substitute type that's interface-compatible.

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

IDL v4 is a standalone specification

This specification has no normative reference for IDL v4.

I have implementation experience applying portions of this spec to a non-CORBA middleware (which happens to be a DDS implementation). Those sections of this spec that apply (6.3, 6.4, 6.5, 6.6, 6.8-16, 6.30-31) do not use the CORBA module/namespace.

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

Existing alternatives for struct construction appear to be sufficient

Since the issue has been unresolved for a number of RTFs I'm proposing we close it now.
The proposed enhancement could be provided by implementations as an extension to the spec-mandated behavior.
I don't argue that there is some benefit from this approach, but there is also implementation complexity: when generating a struct constructor, the tool will need to know, for each struct member, which constructor parameters that member can take. Those parameters can vary based on versions of the C++ standard library (for types like std::string, vector, array, map).

Reduce the indent of public, should start on the first line, makes it all more readable

Update source code formatting

Remove extra indenting that can force line wrapping and make embedded source code hard to read.

There are tabs between bool and the method names, they should be removed

Update code in 6.26.2

Minor formatting change as suggested.

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.