Issues for IDL to C++11 V1.4 (IDL2CPP11) Revision Task Force

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

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

Jira Issues

Issue 17420: In-place construction of structure types Jira Issue CPP1113-5
Issue 18149: RFP requirement on DDS-PSM-Cxx compatibility is violated Jira Issue CPP1111-1
Issue 18385: typo exists in section 6.21 Jira Issue CPP1111-2
Issue 18386: Lack of factory reference type Jira Issue CPP1111-3
Issue 18387: Add support for _this on local objects Jira Issue CPP1111-4
Issue 18388: Add missing implicit widening to any Jira Issue CPP1111-5
Issue 18389: Font issue Jira Issue CPP1111-6
Issue 18390: Extend IDL type traits for template meta programming Jira Issue CPP1111-7
Issue 18392: Remove _narrow methods Jira Issue CPP1111-8
Issue 18404: Invalid struct initialization example Jira Issue CPP1111-9
Issue 18405: Fixed type mapping should provide (explicit) operator bool Jira Issue CPP1111-10
Issue 18406: Meaning of (u)intN_t types unclear Jira Issue CPP1111-11
Issue 18418: Missing specification of assignment operators of valuetypes Jira Issue CPP1111-12
Issue 18433: std::ostream insertion underspecified Jira Issue CPP1111-13
Issue 18453: Early detection of bound violation on bounded types Jira Issue CPP1111-14
Issue 18463: CORBA::Exception should not use std::string type for name and repo_id Jira Issue CPP1111-15
Issue 18498: Minor typos Jira Issue CPP1111-16
Issue 18500: Use () instead of (void) Jira Issue CPP1111-17
Issue 18523: Introduce trait for local interface base type Jira Issue CPP1111-18
Issue 18527: Replace all _downcase/downcase with narrow Jira Issue CPP1111-19
Issue 18533: IDL2C++11 issue : CORBA dependency of the C++11 mapping Jira Issue CPP1113-6
Issue 18536: Small typos in servant reference section Jira Issue CPP1111-20
Issue 18578: Remove final for structured types Jira Issue CPP1111-21
Issue 18655: Relax constructor argument rules Jira Issue CPP1111-22
Issue 18656: Add namespace level swap Jira Issue CPP1111-23
Issue 18660: Remove user defined literal support Jira Issue CPP1111-24
Issue 18761: Errors on code snippes related to skeleton classes Jira Issue ITCR-3
Issue 18762: Code fragment should use skel class Jira Issue ITCR-4
Issue 18832: Question on unions default member Jira Issue ITCR-5
Issue 18849: Destructors of strong reference types should be public Jira Issue ITCR-6
Issue 18850: Contructor declarations in Servant code are wrong Jira Issue ITCR-7
Issue 19035: provide unique class name as mapping of PortableServer::Servant Jira Issue ITCR-8
Issue 19036: wrong return type for Foo::some_function() Jira Issue ITCR-9
Issue 19207: Add missing default initialization for valuetypes Jira Issue ITCR-10
Issue 19260: Valuebox should also have swap support Jira Issue ITCR-11
Issue 19498: Clarify valuetype factory mapping Jira Issue ITCR-12
Issue 19499: Make mapping of sequences more flexible Jira Issue CPP1113-7
Issue 19575: Missing move assignment operator in class ColorValue Jira Issue ITCR-14
Issue 19576: Move constructor of ValueBase incorrect Jira Issue ITCR-15
Issue 19577: usage of OBV trait should be improved Jira Issue ITCR-16
Issue 19580: Mention move constructor with abstract Jira Issue ITCR-17
Issue 19581: Destructor should just be virtual Jira Issue ITCR-18
Issue 19582: fixed member types use incorrect type Jira Issue ITCR-19
Issue 19672: _this for skeleton, not for implementation Jira Issue ITCR-41
Issue 19678: replace POA_B by adequate skeleton Jira Issue ITCR-42
Issue 19686: abstract interfaces with corrected skeleton name Jira Issue ITCR-43
Issue 19697: Skeleton class as consistent template parameter for CORBA::servant_traits Jira Issue ITCR-44

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

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

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.

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

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 {  protected:  IDL::traits<LocalIF>::ref_type _this ();  };  Refs #2804

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

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

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

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

The example in the middle of the page starts with:      // C++  S s = {10};      but the struct mapping (6.13.1 p.23) clearly says that "an explicit constructor accepting values for struct each member" shall be provided. Above initialization context is a copy-initialization context and would require a non-explicit constructor. The example should be fixed to use a direct-initialization context instead, either:      // C++  S s{10};      or      // C++  S s = S{10};

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) { ... }      But the similar inverse form      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!

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)

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.

The wording in 6.29 says      "For each IDL type (T) of type: [..] an ostream inserter with the following signature will be provided:      // C++  std::ostream& operator<<(std::ostream &, T);      For all other types an ostream inserter with the following signature will be provided:      // C++  std::ostream& operator<<(std::ostream &, const T&);"      1) This wording is not clear in which namespace the operator<< overload shall be provided. It could be within the global namespace or within the namespace of type T.       The prototype implementation that I have seen provides these operators in the global namespace which makes them behave irregular:       The reason is that overloaded operators such as these IO inserters are found by argument-dependent name-lookup. The lookup will consider all declarations that are found at the point of usage and will look in the associated namespaces of the operands to find them. Consider the following example:      #include <iostream>  #include <vector>  #include <iterator>      namespace n {    struct A {};  }  std::ostream& operator<<(std::ostream& os, n::A) { return os; }      int main() {    std::vector<n::A> v;    std::copy(v.begin(), v.end(), std::ostream_iterator<n::A>(std::cout));  }      This program will not compile, because the involved template cannot "see" the operator<< overload. TRhis is so, because it is provided in the global namespace, but the operands are in namespace std:: and namespace n, resp. Adding overloads to namespace std is not valid, therefore the only option is to add the operator<< overload to namespace n:      #include <iostream>  #include <vector>  #include <iterator>      namespace n {   struct A {};   std::ostream& operator<<(std::ostream& os, n::A) { return os; }  }      int main() {    std::vector<n::A> v;    std::copy(v.begin(), v.end(), std::ostream_iterator<n::A>(std::cout));  }      This works and lets the ostream operator<< of A::n behave normally.      This example was intended to demonstrate that the provided operator<< overloads should be provided in the same namespace as the declared mapped types from the IDL (that is within the IDL module). The wording in 6.29 should be clarified in that regard.      2) The second part of above wording,       "For all other types an ostream inserter with the following signature will be provided:      // C++  std::ostream& operator<<(std::ostream &, const T&);"      can be read to be applicable for the arithmetic IDL types (bool, short, wchar_t, char, double, uint32_t, ...) or typedefs thereof, but that surely cannot be intended, because that would result in a compiler ambiguity when user code would include such a mapping header and would attempt to print such an arithmetic type on any std::ostream, e.g.      #include <iostream>  #include "some_idl.h"      int main() {    std::cout << 12; // Error, ambiguity  }    The wording in 6.29 should make clear that *no* operator<< overloads shall be provided for the basic data types or for typedefs thereof.

Addressee: IDL to C++11 1.1 RTF <[email protected]>  Nature: Enhancement  Summary: Early detection of bound violation on bounded types      In the IDL to C++11 Mapping v1.0 (formal/13-02-04), the sections  6.9, 6.10, and 6.11 describe the mapping for string, wstring, and  sequence types, respectively. These sections also address the bounded  variant of those types:      " Implementations must (at run time) detect attempts to pass a  [string|wstring|sequence] value that exceeds the bound as a parameter  across an interface. It must raise a BAD_PARAM system exception to  signal the error. "      In practice, the point at which such a value is passed into an interface  method may be far away from the assignment causing a bound violation,  which makes the error source hard to find.      I propose doing a bound check not only at interface methods but also  at the setter functions for struct, union, and valuetype members.      The section quoted above could thus be extended as follows:      " Implementations must (at run time) detect attempts to pass a   [string|wstring|sequence] value that exceeds the bound as a parameter   across an interface, or passed to a setter method of a struct, union,  or valuetype. It must raise a BAD_PARAM system exception to   signal the error. "      Furthermore, the mapping standard does not define the bound check  behavior for arrays and sequences of bounded types.  IMHO the mapping standard should make explicit that the bound check  shall be performed on each bounded-type element of an array or sequence.      Example:        // IDL    typedef string<12> string12_t;    typedef string12_t string_arr_t[2][3];    typedef sequence<string12_t, 4> string_seq_t;    struct struct_t {      string_arr_t sarr;      string_seq_t sseq;    }      The sarr() and sseq() setter methods generated for struct_t should  iterate over their input parameter and perform the bound check on  each element. Similar checks should happen in the explicit constructor  which accepts values for each struct member.    

CORBA::Exception should not use std::string type for name and repo_id for 2 reasons:      1. C++ standard conformance; member types like std::string are discouraged because their constructors may throw exceptions where std::exception and derivatives are expected not to throw exceptions themselves  2. (minor) performance; using std::string these member values are unnecessarily copied while they immutable constant strings only ever read, never mutated      Changing the members to const char* values makes CORBA::Exception and the CORBA::SystemException classes optimal and c++ standard conformant.      This will not be the case for CORBA::UserException derivatives as these may have IDL defined attributes having IDL defined types which may definitely throw exceptions. However the ORB should be expected to handle situations where creating user exceptions unexpectedly throws another exception.    Refs #2958

2.1 refers to ISO/IEC 14822:2011 (which should be 14882:2011)      6.30 instead refers to ISO/IEC 14882:011 (again should be 14882:2011)      the table in 6.30 contains typos (alinas, alineof, constrexpr), names  that aren't keywords (int32_t, ...) and misses some keywords  (noexcept, char16_t, char32_t).

The specification uses in some examples like in 6.13.1 the construct "(void)" for a method with no arguments. This is old style, it should use "()"

The specification uses IDL::traits<T> for everything related to interface T, but for a local interface we just use T as base class. Proposal is to use IDL::traits<T>::base_type as base type trait for the local object implementation. This makes everything related to interfaces available through IDL::traits<T>

As done for the interfaces already, we propose to remove _downcase/_narrow for abstract/valuetype and only support IDL::traits<>::narrow. In the spec this has to be updated in text and code.

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  

Two small typos in sectin 6.25.3:  aks CORBA::weak_servant_reference<>   to   aka CORBA::weak_servant_reference<>       Than   Foo some_function()  to  Foo::some_function()

The mapping defines the mapping of IDL struct/union to a final class. The work "final" should be removed from the IDL to C++11 language mapping because it will prevent the implementation of the DDSXTypes Type Extensibility.

Currently the std::array doesn't have an efficient move constructor, passing an array by value to the constructor of a valuetype/struct isn't efficient. Instead of adding an exception to the spec we propose to relax the spec so that it just mentions that the constructor must be there, but not that arguments have to be passed by value, that is up to the implementor to decide

Everywhere where a specialization of std::swap is mentioned also mention the need for a namespace level swap

The fixed mapping uses operator"" and _fixed as user defined literal. This doesn't work with a C++ template, only with a class, so the usage of user defined literals should be removed

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.

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

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?  

The spec dictates that the destructor of a strong reference type should be protected. Implementing this will lead to compile errors. Seems that this is a left over from the beta 1 spec.

The code on page 42 has a class named 'Servant' but the constructors in this piece of code are declared as 'ServantBase'. Also the =-operators are referring to 'ServantBase' instead of 'Servant'.    The text that follows this piece of code also talks about 'ServantBase' (in bold) instead of 'Servant'

    Both Servant and ServantBase for the same purpose are used in the declaration of the mapping of PortableServer::Servant.    Throughout this chapter Servant should be used unambiguously.

The return type should be       IDL::traits<Test::Hello>::ref_type      instead of    CORBA::servant_traits<Test::Hello>::ref_type

In 6.18.2 Constructors, Assignment Operators, and Destructors the default constructor of the OBV classes is mentioned. This lacks a description that it should initialize members, proposal is to add to 6.18.2, OBV part, after the first sentence add:      The default constructor initializes object  reference members to appropriately-typed nil object references, basic datatypes to their default value as listed in  Table 6.2, and enums to their first value. All other members are initialized using their default constructors.

For valueboxes the spec should also describe swap support, they are complete so they can support swap. To be added:    A namespace level swap and a specialization of std::swap<> must be provided to exchange the values of two valueboxes in an efficient matter.

The valuetype factory mapping is too focused on the implementation, it should just refer to IDL<T>::factory_type as base class for the user provided factory implementation and shouldn't refer to ValueFactoryBase, that is an internal detail.     Ref devportal 3617

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.

The class ColorValue as example is missing the move assignment operator which should be:    ColorValue(& operator= (ColorValue(&&)

The listed move constructor of ValueBase is incorrect, it should be    ValueBase(ValueBase&&);

The specicification currently lists:      The application developer then overrides the pure virtual functions corresponding to valuetype operations in a concrete class derived directly or indirectly from the OBV  trait.      It is not precise enough to juset say OBV traits, it should say      The application developer then overrides the pure virtual functions corresponding to valuetype operations in a concrete class derived directly or indirectly from the IDL::traits<>::obv_type  trait.

for 6.19.1 to the bullet list should be added     a protected move constructor

for 6.19.1 to the bullet list mentions       a protected pure virtual destructor      This should be       a protected virtual destructor    it is not pure, see the example later on

In table 6.11 digits/scale are described, they should use uint16_t instead of uint32_t, see the above template, there also uint16_t is used

_this() method example should be given for the skeleton (eg. A_skel), not for implementation (A_impl):      // C++  class A_skel    : public virtual PortableServer::Servant  {    IDL::traits<A>::ref_type _this();    ...  }

drop POA_B for skeleton class deriveved from abstract class and replace it adequately:      // C++  class A { ... }  class B_skel : public virtual ... /* maybe PortableServer::Servant */,                 protected virtual A  {     ...  };

� 6.26.6, to the end, about abstract interfaces:      I guess the C++ snippet should be like      // C++  class A { ... }  class B_skel : public virtual ... /* maybe PortableServer::Servant */,                 protected virtual A  {     ...  };    dropping the old POA_B thing.

Instead of the IDL interface class, the skeleton class should be used as template parameter for CORBA::servant_traits<>.      Rationale:      1. The servant which the traits describe is realized by an instance of a class derived from the skeleton class which in turn (directly or indireclty) inherits PortableServer::Servant but not necessarily the interface class.      PortableServant::Server < ... < CORBA::servant_traits<A_skel>::base_type < A_impl      instead of       PortableServant::Server < ... < CORBA::servant_traits<A>::base_type < A_impl        (A, A_skel and A_impl are arbitrary names denoting the interface, the skeleton and the implementation class, resp.).                   2. In chapter 6.26.4 "Servant argument passing", we have CORBA::servant_traits<PortableServer::Servant>; this takes (the very basic) servant class as template parameter.      CORBA::servant_traits<PortableServer::Servant>::ref_type < CORBA::servant_traits<A_skel>::ref_type      instead of       CORBA::servant_traits<PortableServer::Servant>::ref_type < CORBA::servant_traits<A>::ref_type      3. In chapter 6.26.3 "Servant references" CORBA::make_reference<...> takes the implementation class as argument to create a CORBA::servant_traits<...>::ref_type. This would be more consistent with CORBA::make_reference<...> taking an interface class as parameter to create IDL::traits<...>::ref_type.      CORBA::make_reference<A_impl> -> CORBA::servant_traits<A_skel>::ref_type      like      CORBA::make_reference<A> -> IDL::traits<A>::ref_type      instead of      CORBA::make_reference<A_impl> -> CORBA::servant_traits<A>::ref_type      4. CORBA::servant_traits<...>::base_type is used as base class for implementation classes in �� 6.26.6 and 6.26.7. Having CORBA::servant_traits<A_impl>::base_type instead of CORBA::servant_traits<A>::base_type is more consistent with the use of IDL::traits<LocalIF>::base_type denoting CORBA::LocalObject or something derived from CORBA::LocalObject.      CORBA::servant_traits<A_skel>::base_type < A_impl      like      IDL::traits<LocalIF>::base_type < MyLocalIf      instead of      CORBA::servant_traits<A>::base_type < A_impl      This affects all uses of servant_traits in �� 6.26.3, 6.26.5, 6.26.6, 6.26.7.      The disadvantage to be considered is that the naming of the skeleton class is not standardized, so implementation classes to be provided by a programmer using an IDL to C++11 framework package cannot longer inherit a well-specified base class like CORBA::servant_traits<A>::base_type. Instead something like CORBA::servant_traits<skeleton<A>>:base_type would be required where skeleton<...> is a framework-specific template.