IDL to C++11 Language Mapping Avatar
  1. OMG Specification

IDL to C++11 Language Mapping — All Issues

  • Acronym: CPP11
  • Issues Count: 30
  • Description: All Issues
Open Closed All
All Issues

Issues Summary

Key Issue Reported Fixed Disposition Status
CPP1114-1 In-place construction of structure types CPP11 1.0 CPP11 1.4 Closed; No Change closed
CPP1113-5 In-place construction of structure types CPP11 1.0 CPP11 1.3 Deferred closed
ITCR-4 Code fragment should use skel class CPP11 1.0 CPP11 1.2 Closed; No Change closed
ITCR-3 Errors on code snippet related to skeleton classes CPP11 1.0 CPP11 1.2 Resolved closed
ITCR-1 In-place construction of structure types CPP11 1.0 CPP11 1.2 Deferred closed
CPP1111-25 Reduce dependency on CORBA CPP11 1.0 CPP11 1.1 Resolved closed
CPP1111-24 Remove user defined literal support CPP11 1.0 CPP11 1.1 Resolved closed
CPP1111-23 Add namespace level swap CPP11 1.0 CPP11 1.1 Resolved closed
CPP1111-22 Relax constructor argument rules CPP11 1.0 CPP11 1.1 Resolved closed
CPP1111-21 Remove final for structured types CPP11 1.0 CPP11 1.1 Resolved closed
CPP1111-20 Small typos in servant reference section CPP11 1.0 CPP11 1.1 Resolved closed
CPP1111-19 Replace all _downcase/downcase with narrow CPP11 1.0 CPP11 1.1 Resolved closed
CPP1111-18 Introduce trait for local interface base type CPP11 1.0 CPP11 1.1 Resolved closed
CPP1111-17 Use () instead of (void) CPP11 1.0 CPP11 1.1 Resolved closed
CPP1111-16 Minor typos CPP11 1.0 CPP11 1.1 Resolved closed
CPP1111-15 CORBA::Exception should not use std::string type for name and repo_id CPP11 1.0 CPP11 1.1 Resolved closed
CPP1111-14 Early detection of bound violation on bounded types CPP11 1.0 CPP11 1.1 Resolved closed
CPP1111-13 std::ostream insertion underspecified CPP11 1.0 CPP11 1.1 Resolved closed
CPP1111-12 Missing specification of assignment operators of valuetypes CPP11 1.0b2 CPP11 1.1 Resolved closed
CPP1111-11 Meaning of (u)intN_t types unclear CPP11 1.0b2 CPP11 1.1 Resolved closed
CPP1111-10 Fixed type mapping should provide (explicit) operator bool CPP11 1.0b2 CPP11 1.1 Resolved closed
CPP1111-9 Invalid struct initialization example CPP11 1.0b2 CPP11 1.1 Resolved closed
CPP1111-8 Remove _narrow methods CPP11 1.0b2 CPP11 1.1 Resolved closed
CPP1111-7 Extend IDL type traits for template meta programming CPP11 1.0b2 CPP11 1.1 Resolved closed
CPP1111-6 Font issue CPP11 1.0b2 CPP11 1.1 Resolved closed
CPP1111-5 Add missing implicit widening to any CPP11 1.0b2 CPP11 1.1 Resolved closed
CPP1111-4 Add support for _this on local objects CPP11 1.0b2 CPP11 1.1 Resolved closed
CPP1111-3 Lack of factory reference type CPP11 1.0b2 CPP11 1.1 Resolved closed
CPP1111-2 typo exists in section 6.21 CPP11 1.0b2 CPP11 1.1 Resolved closed
CPP1111-1 RFP requirement on DDS-PSM-Cxx compatibility is violated CPP11 1.0b2 CPP11 1.1 Resolved closed

Issues Descriptions

In-place construction of structure types

  • Key: CPP1114-1
  • Legacy Issue Number: 17420
  • Status: closed  
  • Source: Real-Time Innovations ( Sumant Tambe)
  • 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

  • Reported: CPP11 1.0 — Mon, 11 Jun 2012 04:00 GMT
  • Disposition: Closed; No Change — CPP11 1.4
  • Disposition Summary:

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

  • Updated: Mon, 1 Apr 2019 18:18 GMT

In-place construction of structure types

  • Key: CPP1113-5
  • Legacy Issue Number: 17420
  • Status: closed  
  • Source: Real-Time Innovations ( Sumant Tambe)
  • 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

  • Reported: CPP11 1.0 — Mon, 11 Jun 2012 04:00 GMT
  • Disposition: Deferred — CPP11 1.3
  • Disposition Summary:

    Deferred

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

  • Updated: Tue, 19 Dec 2017 20:21 GMT

Code fragment should use skel class

  • Key: ITCR-4
  • Legacy Issue Number: 18762
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • 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

  • Reported: CPP11 1.0 — Fri, 7 Jun 2013 04:00 GMT
  • Disposition: Closed; No Change — CPP11 1.2
  • Disposition Summary:

    Code fragment should use skel class

    After carefully reviewing the specification and comparing it with our implementation we came to the conclusion that this issue is not correct. The specification is correct and nothing has to be changed in this chapter.

  • Updated: Wed, 8 Jul 2015 11:43 GMT

Errors on code snippet related to skeleton classes

  • Key: ITCR-3
  • Legacy Issue Number: 18761
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • 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.

  • Reported: CPP11 1.0 — Thu, 6 Jun 2013 04:00 GMT
  • Disposition: Resolved — CPP11 1.2
  • Disposition Summary:

    Correct skeleton inheritance

    The traits shouldn't be used in this example, those are for user code.

  • Updated: Wed, 8 Jul 2015 11:43 GMT

In-place construction of structure types

  • Key: ITCR-1
  • Legacy Issue Number: 17420
  • Status: closed  
  • Source: Real-Time Innovations ( Sumant Tambe)
  • 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

  • Reported: CPP11 1.0 — Mon, 11 Jun 2012 04:00 GMT
  • Disposition: Deferred — CPP11 1.2
  • Disposition Summary:

    Defer to future RTF

    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.

  • Updated: Wed, 8 Jul 2015 11:43 GMT

Reduce dependency on CORBA

  • Key: CPP1111-25
  • Legacy Issue Number: 17534
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    This new language mapping has CORBA in several places. Part of it are really dependent on CORBA, but not all places. In order to make it more generable usable the spec has to be updated to reduce the dependency on CORBA by

    • Rename all CORBA::foo_traits<> to IDL::traits<>
    • Move CORBA::Fixed to IDL::Fixed
  • Reported: CPP11 1.0 — Wed, 1 Aug 2012 04:00 GMT
  • Disposition: Resolved — CPP11 1.1
  • Disposition Summary:

    As proposed by the issue we are removing the CORBA::foo_traits<> and use the generic new IDL::traits<>. This makes the client code independent on CORBA. We do keep the CORBA::make_reference to create a CORBA reference, CORBA::servant_traits<> for CORBA servant, and CORBA::Any

  • Updated: Fri, 6 Mar 2015 23:16 GMT

Remove user defined literal support

  • Key: CPP1111-24
  • Legacy Issue Number: 18660
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    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

  • Reported: CPP11 1.0 — Fri, 12 Apr 2013 04:00 GMT
  • Disposition: Resolved — CPP11 1.1
  • Disposition Summary:

    The usage of operator”” and _fixed will be removed from the specification

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Add namespace level swap

  • Key: CPP1111-23
  • Legacy Issue Number: 18656
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

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

  • Reported: CPP11 1.0 — Fri, 12 Apr 2013 04:00 GMT
  • Disposition: Resolved — CPP11 1.1
  • Disposition Summary:

    Accepting this issue as proposed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Relax constructor argument rules

  • Key: CPP1111-22
  • Legacy Issue Number: 18655
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    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

  • Reported: CPP11 1.0 — Fri, 12 Apr 2013 04:00 GMT
  • Disposition: Resolved — CPP11 1.1
  • Disposition Summary:

    We remove the restriction that the arguments have to be passed by value to the
    constructor of a structured type. This is a way implementations can deliver optimizations
    if needed. This change will not impact any user code in terms of portability

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Remove final for structured types

  • Key: CPP1111-21
  • Legacy Issue Number: 18578
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    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.

  • Reported: CPP11 1.0 — Fri, 22 Mar 6013 04:00 GMT
  • Disposition: Resolved — CPP11 1.1
  • Disposition Summary:

    Accepting this issue as proposed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Small typos in servant reference section

  • Key: CPP1111-20
  • Legacy Issue Number: 18536
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

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

  • Reported: CPP11 1.0 — Fri, 8 Mar 2013 05:00 GMT
  • Disposition: Resolved — CPP11 1.1
  • Disposition Summary:

    Change text as proposed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Replace all _downcase/downcase with narrow

  • Key: CPP1111-19
  • Legacy Issue Number: 18527
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    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.

  • Reported: CPP11 1.0 — Tue, 5 Mar 2013 05:00 GMT
  • Disposition: Resolved — CPP11 1.1
  • Disposition Summary:

    Accepting this issue as proposed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Introduce trait for local interface base type

  • Key: CPP1111-18
  • Legacy Issue Number: 18523
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    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>

  • Reported: CPP11 1.0 — Mon, 4 Mar 2013 05:00 GMT
  • Disposition: Resolved — CPP11 1.1
  • Disposition Summary:

    Accepting this issue as proposed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Use () instead of (void)

  • Key: CPP1111-17
  • Legacy Issue Number: 18500
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    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 "()"

  • Reported: CPP11 1.0 — Mon, 25 Feb 2013 05:00 GMT
  • Disposition: Resolved — CPP11 1.1
  • Disposition Summary:

    Accepting this issue as proposed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Minor typos

  • Key: CPP1111-16
  • Legacy Issue Number: 18498
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

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

  • Reported: CPP11 1.0 — Sun, 24 Feb 2013 05:00 GMT
  • Disposition: Resolved — CPP11 1.1
  • Disposition Summary:

    Accepting this issue as proposed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CORBA::Exception should not use std::string type for name and repo_id

  • Key: CPP1111-15
  • Legacy Issue Number: 18463
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    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

  • Reported: CPP11 1.0 — Mon, 18 Feb 2013 05:00 GMT
  • Disposition: Resolved — CPP11 1.1
  • Disposition Summary:

    Update exception as proposed. During the discussion also it was proposed to define
    what() as noexcept which also has been done

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Early detection of bound violation on bounded types

  • Key: CPP1111-14
  • Legacy Issue Number: 18453
  • Status: closed  
  • Source: Airbus Group ( Oliver Kellogg)
  • Summary:

    Addressee: IDL to C++11 1.1 RTF <idl2cpp11-rtf@omg.org>
    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.

  • Reported: CPP11 1.0 — Wed, 13 Feb 2013 05:00 GMT
  • Disposition: Resolved — CPP11 1.1
  • Disposition Summary:

    Adding the bounds check to the place where the bounded type is used leads to
    inconsistent behavior for users. After discussion we decided to map bounded types
    (string/wstring/sequence) to a distinct type and that this type could do a bounds check.
    The exact type doesn’t need to be standardized because bound types can only be used
    through a typedef in IDL and never are used directly by the programmer. Because the
    standard containers don’t have the concept of bounds enforcing a bound will be very
    hard to accomplish on all places.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

std::ostream insertion underspecified

  • Key: CPP1111-13
  • Legacy Issue Number: 18433
  • Status: closed  
  • Source: gmail.com ( daniel.kruegler@gmail.com)
  • Summary:

    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.

  • Reported: CPP11 1.0 — Wed, 6 Feb 2013 05:00 GMT
  • Disposition: Resolved — CPP11 1.1
  • Disposition Summary:

    We had a detailed looked at the argument dependent lookup and what would technically
    be feasible. We also had users that wanted to define their own ostream operators and
    our spec defined methods were conflicting with that approach. Given that this feature
    was mostly focused on debugging systems, we decided to remove this section
    completely from the specification

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Missing specification of assignment operators of valuetypes

  • Key: CPP1111-12
  • Legacy Issue Number: 18418
  • Status: closed  
  • Source: gmail.com ( daniel.kruegler@gmail.com)
  • Summary:

    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.

  • Reported: CPP11 1.0b2 — Tue, 5 Feb 2013 05:00 GMT
  • Disposition: Resolved — CPP11 1.1
  • Disposition Summary:

    Accepting this issue as proposed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Meaning of (u)intN_t types unclear

  • Key: CPP1111-11
  • Legacy Issue Number: 18406
  • Status: closed  
  • Source: gmail.com ( daniel.kruegler@gmail.com)
  • Summary:

    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)

  • Reported: CPP11 1.0b2 — Fri, 1 Feb 2013 05:00 GMT
  • Disposition: Resolved — CPP11 1.1
  • Disposition Summary:

    Accepting this issue as proposed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Fixed type mapping should provide (explicit) operator bool

  • Key: CPP1111-10
  • Legacy Issue Number: 18405
  • Status: closed  
  • Source: gmail.com ( daniel.kruegler@gmail.com)
  • Summary:

    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!

  • Reported: CPP11 1.0b2 — Fri, 1 Feb 2013 05:00 GMT
  • Disposition: Resolved — CPP11 1.1
  • Disposition Summary:

    Accepting this issue as proposed. Also during the discussion it was proposed to add a
    namespace level to_string

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Invalid struct initialization example

  • Key: CPP1111-9
  • Legacy Issue Number: 18404
  • Status: closed  
  • Source: gmail.com ( daniel.kruegler@gmail.com)
  • Summary:

    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}

    ;

  • Reported: CPP11 1.0b2 — Fri, 1 Feb 2013 05:00 GMT
  • Disposition: Resolved — CPP11 1.1
  • Disposition Summary:

    Accepting this issue as proposed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Remove _narrow methods

  • Key: CPP1111-8
  • Legacy Issue Number: 18392
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    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

  • Reported: CPP11 1.0b2 — Tue, 29 Jan 2013 05:00 GMT
  • Disposition: Resolved — CPP11 1.1
  • Disposition Summary:

    Accepting this issue as proposed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Extend IDL type traits for template meta programming

  • Key: CPP1111-7
  • Legacy Issue Number: 18390
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    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

  • Reported: CPP11 1.0b2 — Wed, 23 Jan 2013 05:00 GMT
  • Disposition: Resolved — CPP11 1.1
  • Disposition Summary:

    Extending the IDL::traits<> with more types for template meta programming will be useful
    for the users that would like to program C++11 templates using the IDL defined types.
    Therefor a new set of type traits will be added to the specification.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Font issue

  • Key: CPP1111-6
  • Legacy Issue Number: 18389
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    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

  • Reported: CPP11 1.0b2 — Wed, 23 Jan 2013 05:00 GMT
  • Disposition: Resolved — CPP11 1.1
  • Disposition Summary:

    Accepting this addition as proposed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Add missing implicit widening to any

  • Key: CPP1111-5
  • Legacy Issue Number: 18388
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    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

  • Reported: CPP11 1.0b2 — Wed, 23 Jan 2013 05:00 GMT
  • Disposition: Resolved — CPP11 1.1
  • Disposition Summary:

    Accepting this addition as proposed with the remark that 6.13 should be 6.17.3 and it
    talks about the Any C++ class, not the any IDL type.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Add support for _this on local objects

  • Key: CPP1111-4
  • Legacy Issue Number: 18387
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    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

  • Reported: CPP11 1.0b2 — Wed, 23 Jan 2013 05:00 GMT
  • Disposition: Resolved — CPP11 1.1
  • Disposition Summary:

    Accepting this addition as proposed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Lack of factory reference type

  • Key: CPP1111-3
  • Legacy Issue Number: 18386
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    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

  • Reported: CPP11 1.0b2 — Wed, 23 Jan 2013 05:00 GMT
  • Disposition: Resolved — CPP11 1.1
  • Disposition Summary:

    Accepting this addition as proposed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

typo exists in section 6.21

  • Key: CPP1111-2
  • Legacy Issue Number: 18385
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    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

  • Reported: CPP11 1.0b2 — Wed, 23 Jan 2013 05:00 GMT
  • Disposition: Resolved — CPP11 1.1
  • Disposition Summary:

    The V1.0 spec doesn’t have this typo, so closing this with no change
    Disposition: Closed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

RFP requirement on DDS-PSM-Cxx compatibility is violated

  • Key: CPP1111-1
  • Legacy Issue Number: 18149
  • Status: closed  
  • Source: ADLINK Technology Ltd ( Angelo Corsaro)
  • Summary:

    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.

  • Reported: CPP11 1.0b2 — Wed, 10 Oct 2012 04:00 GMT
  • Disposition: Resolved — CPP11 1.1
  • Disposition Summary:

    The revised submission explicitly mentioned that this requirement was not met because
    this is a C+11 language mappping, not focusing on C+03 which is the focus of the
    DDS-PSM-Cxx. Also in the mean time the DDS-PSM-Cxx has adopted the same
    mapping for arrays/enums and mentions move semantics when C++11 support is
    available. Given the fact this is a C++11 language mapping this issue has been closed
    without a change.
    Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT