Issues for Mailing list of the IDL to C++11 V1.1 (IDL2CPP11) Revision Task Force

To comment on any of these issues, send email to idl2cpp11-rtf@omg.org. (Please include the issue number in the Subject: header, thusly: [Issue ###].) To submit a new issue, send email to issues@omg.org.

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Issue 17420: In-place construction of structure types
Issue 18533: IDL2C++11 issue : CORBA dependency of the C++11 mapping
Issue 18761: Errors on code snippes related to skeleton classes
Issue 18762: Code fragment should use skel class
Issue 18832: Question on unions default member

Issue 17420: In-place construction of structure types (idl2cpp11-rtf)

Click here for this issue's archive.
Source: Real-Time Innovations (Dr. Sumant Tambe, sumant(at)rti.com)
Nature: Enhancement
Severity: Significant
Summary:
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

Resolution: The issues proposes an extension to the construction of structured types. A vendor could already add this as performance improvement without being it as part of the specification. Before adding this to the specification this addition first have to be shown in a concrete product to make sure it can be implemented and is usable for users. This hasn’t been done by any vendor yet which made us decide to defer this issue to a future RTF. Revised Text: Disposition: Deferred
Revised Text:
Actions taken:
June 11, 2012: received issue

Discussion:
The issues proposes an extension to the construction of structured types. A vendor could already add this as performance improvement without being it as part of the specification. Before adding this to the specification this addition first have to be shown in a concrete product to make sure it is implementable and usable for users. This hasn’t been done by any vendor yet which made us decide to defer this issue to a future RTF.


Issue 18533: IDL2C++11 issue : CORBA dependency of the C++11 mapping (idl2cpp11-rtf)

Click
here for this issue's archive.
Source: PrismTech (Nawel Hamouche, nawel.hamouche(at)prismtech.com)
Nature: Uncategorized Issue
Severity:
Summary:
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

Resolution: The IDLC++11 langauge mapping explicitly refers to CORBA v3.2 because there is no clean IDL spec yet. There should first be a clean IDL4 spec that is completely middleware agnostic and which gives generic guidelines for language mappings how to target specific middleware technologies like CORBA. At the moment there is an IDL4 spec with those guidelines we can update the IDL2C++11 spec accordingly June 11, 2013 41 Disposition: Deferred
Revised Text:
Actions taken:
March 7, 2013: received issue

Issue 18761: Errors on code snippes related to skeleton classes (idl2cpp11-rtf)

Click
here for this issue's archive.
Source: Remedy IT (Mr. Johnny Willemsen, jwillemsen(at)remedy.nl)
Nature: Clarification
Severity: Minor
Summary:
There is an error in 6.25.6 related to the skeleton classes. The skeleton classes should derive from each other, not from the traits, so it should be as below, also C_skel is lacking.


// C++
class A_skel : public virtual PortableServer::ServantBase {};
class B_skel : public virtual A_skel {};
class C_skel : public virtual A_skel {};
class D_skel : public virtual B_skel, public virtual C_skel {};


The other code bits in this section also have to be checked and see if they are ok.

Resolution:
Revised Text:
Actions taken:
June 6, 2013: received issue

Issue 18762: Code fragment should use skel class (idl2cpp11-rtf)

Click
here for this issue's archive.
Source: Remedy IT (Mr. Johnny Willemsen, jwillemsen(at)remedy.nl)
Nature: Clarification
Severity: Minor
Summary:

The code snippet for the _this method should be using the A_skel class which is derived from PortableServer::ServantBase, not the impl class

Resolution:
Revised Text:
Actions taken:
June 7, 2013: received issue

Issue 18832: Question on unions default member (idl2cpp11-rtf)

Click
here for this issue's archive.
Source: PrismTech (Nawel Hamouche, nawel.hamouche(at)prismtech.com)
Nature: Uncategorized Issue
Severity:
Summary:
In the section 6.14.2 on union mapping, it says :
"If there is a default case specified, the union is initialized to this default case. In case the union has an implicit default member it is initialized to that case. In all other cases it is initialized as empty."


I don't get the meaning of "empty" and it doesn't seem to be defined. For example, if we have a union with a boolean discriminator which defines the two cases true and false, what happens if we read one of the fields or if we call _d (with or without parameter)? Should they all throw BAD_PARAM?

Resolution:
Revised Text:
Actions taken:
July 25, 2013: received issue