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-3 Make mapping of sequences more flexible CPP11 1.1 CPP11 1.4 Resolved closed
CPP1114-2 IDL2C++11 issue : CORBA dependency of the C++11 mapping CPP11 1.1 CPP11 1.4 Closed; Out Of Scope closed
CPP1113-6 IDL2C++11 issue : CORBA dependency of the C++11 mapping CPP11 1.1 CPP11 1.3 Deferred closed
CPP1113-7 Make mapping of sequences more flexible CPP11 1.1 CPP11 1.3 Deferred closed
CPP1113-1 IDL2C++11 mapping lacks support for the new IDL type map CPP11 1.1 CPP11 1.3 Resolved closed
ITCR-57 Fix unclarity in IDL Union description CPP11 1.1 CPP11 1.2 Resolved closed
ITCR-54 Update normative reference to point to CORBA 3.3 CPP11 1.1 CPP11 1.2 Resolved closed
ITCR-38 IDL2C++11 mapping lacks support for the new IDL type map CPP11 1.1 CPP11 1.2 Deferred closed
ITCR-28 Servant argument passing not precise enough CPP11 1.1 CPP11 1.2 Resolved closed
ITCR-39 Missing public specifier CPP11 1.1 CPP11 1.2 Resolved closed
ITCR-42 replace POA_B by adequate skeleton CPP11 1.1 CPP11 1.2 Resolved closed
ITCR-41 _this for skeleton, not for implementation CPP11 1.1 CPP11 1.2 Resolved closed
ITCR-44 Skeleton class as consistent template parameter for CORBA::servant_traits CPP11 1.1 CPP11 1.2 Closed; No Change closed
ITCR-43 abstract interfaces with corrected skeleton name CPP11 1.1 CPP11 1.2 Duplicate or Merged closed
ITCR-12 Clarify valuetype factory mapping CPP11 1.1 CPP11 1.2 Resolved closed
ITCR-11 Valuebox should also have swap support CPP11 1.1 CPP11 1.2 Closed; No Change closed
ITCR-8 provide unique class name as mapping of PortableServer::Servant CPP11 1.1 CPP11 1.2 Duplicate or Merged closed
ITCR-7 Constructor declarations in Servant code are wrong CPP11 1.1 CPP11 1.2 Resolved closed
ITCR-6 Destructors of strong reference types should be public CPP11 1.1 CPP11 1.2 Resolved closed
ITCR-17 Mention move constructor with abstract CPP11 1.1 CPP11 1.2 Resolved closed
ITCR-16 usage of OBV trait should be improved CPP11 1.1 CPP11 1.2 Resolved closed
ITCR-10 Add missing default initialization for valuetypes CPP11 1.1 CPP11 1.2 Resolved closed
ITCR-9 wrong return type for Foo::some_function() CPP11 1.1 CPP11 1.2 Resolved closed
ITCR-5 Question on unions default member CPP11 1.1 CPP11 1.2 Resolved closed
ITCR-15 Move constructor of ValueBase incorrect CPP11 1.1 CPP11 1.2 Resolved closed
ITCR-14 Missing move assignment operator in class ColorValue CPP11 1.1 CPP11 1.2 Resolved closed
ITCR-19 fixed member types use incorrect type CPP11 1.1 CPP11 1.2 Resolved closed
ITCR-18 Destructor should just be virtual CPP11 1.1 CPP11 1.2 Resolved closed
ITCR-2 IDL2C++11 issue : CORBA dependency of the C++11 mapping CPP11 1.1 CPP11 1.2 Deferred closed
ITCR-13 Make mapping of sequences more flexible CPP11 1.1 CPP11 1.2 Deferred closed

Issues Descriptions

Make mapping of sequences more flexible

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

    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.

  • Reported: CPP11 1.1 — Tue, 1 Jul 2014 04:00 GMT
  • Disposition: Resolved — CPP11 1.4
  • Disposition Summary:

    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.

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

IDL2C++11 issue : CORBA dependency of the C++11 mapping

  • Key: CPP1114-2
  • Legacy Issue Number: 18533
  • Status: closed  
  • Source: THALES ( Nawel Hamouche)
  • 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
  • Reported: CPP11 1.1 — Thu, 7 Mar 2013 05:00 GMT
  • Disposition: Closed; Out Of Scope — CPP11 1.4
  • Disposition Summary:

    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.

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

IDL2C++11 issue : CORBA dependency of the C++11 mapping

  • Key: CPP1113-6
  • Legacy Issue Number: 18533
  • Status: closed  
  • Source: THALES ( Nawel Hamouche)
  • 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
  • Reported: CPP11 1.1 — Thu, 7 Mar 2013 05:00 GMT
  • Disposition: Deferred — CPP11 1.3
  • Disposition Summary:

    Deferred

    Deferred to future RTF

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

Make mapping of sequences more flexible

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

    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.

  • Reported: CPP11 1.1 — Tue, 1 Jul 2014 04:00 GMT
  • Disposition: Deferred — CPP11 1.3
  • Disposition Summary:

    Deferred

    Deferred

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

IDL2C++11 mapping lacks support for the new IDL type map

  • Key: CPP1113-1
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The DDS-XTypes specification extends the IDL type system which will be integrated into the IDL4 specification. The IDL2C++11 mapping should be extended with a new section describing the support for the IDL map type.

  • Reported: CPP11 1.1 — Tue, 26 Aug 2014 11:43 GMT
  • Disposition: Resolved — CPP11 1.3
  • Disposition Summary:

    Import the mapping of IDL Map from XTypes 1.2

    XTypes 1.2 (beta) ptc/17-03-06 section 7.5.1.3.4 maps the IDL Map type to "Modern C++", that mapping can be used by this spec directly

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

Fix unclarity in IDL Union description

  • Key: ITCR-57
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    In section 4 of paragraph 6.14.2 it says " If a modifier for a union member with multiple legal discriminant values is used to set the value of the discriminant, the union implementation will take the first discriminant specified in IDL.". It is not the "first discriminant" but the "first discriminant value". This is triggered by the resolution of ITCR-5

  • Reported: CPP11 1.1 — Tue, 13 Jan 2015 15:50 GMT
  • Disposition: Resolved — CPP11 1.2
  • Disposition Summary:

    Clarify discriminant

    The text should be clear to refer to "discriminant value"

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

Update normative reference to point to CORBA 3.3

  • Key: ITCR-54
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The IDL to C++11 language mapping refers to CORBA v3.2, in the meantime CORBA v3.3 is there, so update the normative reference in section 3 to point to CORBA 3.3

  • Reported: CPP11 1.1 — Tue, 13 Jan 2015 08:08 GMT
  • Disposition: Resolved — CPP11 1.2
  • Disposition Summary:

    Update reference

    Update the reference to CORBA 3.3, there are no changes in CORBA 3.3 that impact IDL2C++11 but it is good to refer to the latest version of the CORBA specification

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

IDL2C++11 mapping lacks support for the new IDL type map

  • Key: ITCR-38
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The DDS-XTypes specification extends the IDL type system which will be integrated into the IDL4 specification. The IDL2C++11 mapping should be extended with a new section describing the support for the IDL map type.

  • Reported: CPP11 1.1 — Tue, 26 Aug 2014 11:43 GMT
  • Disposition: Deferred — CPP11 1.2
  • Disposition Summary:

    Defer to future RTF

    We propose to defer this to the next RTF because we haven't been able to prototype this in order to validate some ideas we had. Especially the needed IDL::traits<> has to be tested and tried

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

Servant argument passing not precise enough

  • Key: ITCR-28
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    Section 6.26.4 describes the argument passing for Servant, but this should use CORBA::servant_traits<PortableServer::Servant>::ref_type instead of CORBA::servant_traits<T>::ref_type

  • Reported: CPP11 1.1 — Thu, 21 Aug 2014 11:06 GMT
  • Disposition: Resolved — CPP11 1.2
  • Disposition Summary:

    Servant argument passing not precise enough

    The servant argument passing should be corrected as proposed by the issue

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

Missing public specifier

  • Key: ITCR-39
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The last code example of section 6.26.6 lacks the public specifier for the class MyA. Instead of "class MyA : virtual" it should be "class MyA : public virtual"

  • Reported: CPP11 1.1 — Wed, 10 Dec 2014 12:05 GMT
  • Disposition: Resolved — CPP11 1.2
  • Disposition Summary:

    Add missing public specifier

    The issue is correct, the code example should use "public virtual" instead of just "virtual"

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

replace POA_B by adequate skeleton

  • Key: ITCR-42
  • Legacy Issue Number: 19678
  • Status: closed  
  • Source: langensoft.com ( T. Langen)
  • Summary:

    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

    { ... }

    ;

  • Reported: CPP11 1.1 — Wed, 10 Dec 2014 05:00 GMT
  • Disposition: Resolved — CPP11 1.2
  • Disposition Summary:

    Remove usage of B_Skel and remove mentioning of PortableServer::ServantBase

    The report is correct, POA_B is a left over of the old IDL to C++ language mapping. At the same time we want to remove the mandatory inheritance of PortableServer::ServantBase, that is something for the vendor to decide, not important for the user.

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

_this for skeleton, not for implementation

  • Key: ITCR-41
  • Legacy Issue Number: 19672
  • Status: closed  
  • Source: langensoft.com ( T. Langen)
  • Summary:

    _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(); ... }
  • Reported: CPP11 1.1 — Mon, 8 Dec 2014 05:00 GMT
  • Disposition: Resolved — CPP11 1.2
  • Disposition Summary:

    Correct code example for _this

    The code example defines the _this in the wrong class, it should be done in the skeleton class, not in the user implementation class. Because the example inheritance of the skeleton classes is up to the vendor also the inheritance of CORBA::servant_traits<A>::base_type should be removed and replaced with three dots. As last is the override something that should be removed.

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

Skeleton class as consistent template parameter for CORBA::servant_traits

  • Key: ITCR-44
  • Legacy Issue Number: 19697
  • Status: closed  
  • Source: langensoft.com ( T. Langen)
  • Summary:

    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.

  • Reported: CPP11 1.1 — Sat, 27 Dec 2014 05:00 GMT
  • Disposition: Closed; No Change — CPP11 1.2
  • Disposition Summary:

    Keep referring to A instead of A_skel

    One of the basic rules we defined for IDL2Cpp11 is that we don't want the user to remember all kind of rules to translate between the IDL name and some Cpp11 type. At the moment a IDL type is translated to multiple C++ types we are using the IDL traits. The concept of a skeleton exists in IDL2Cpp11 but the exact class of the skeleton is accessed by the user using the CORBA::servant_traits. The proposed change will complicate the life for the user without any benefit.

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

abstract interfaces with corrected skeleton name

  • Key: ITCR-43
  • Legacy Issue Number: 19686
  • Status: closed  
  • Source: langensoft.com ( T. Langen)
  • Summary:

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

  • Reported: CPP11 1.1 — Mon, 15 Dec 2014 05:00 GMT
  • Disposition: Duplicate or Merged — CPP11 1.2
  • Disposition Summary:

    Duplicated issue

    This issue ITCR-43 looks to be a duplicate of ITCR-42

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

Clarify valuetype factory mapping

  • Key: ITCR-12
  • Legacy Issue Number: 19498
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    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

  • Reported: CPP11 1.1 — Wed, 20 Aug 2014 04:05 GMT
  • Disposition: Resolved — CPP11 1.2
  • Disposition Summary:

    Clarify valuetype factory mapping

    The current valuetype factory mapping ties the implementor of the specification to too much details, we should just mention the classes with their signatures and the traits.

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

Valuebox should also have swap support

  • Key: ITCR-11
  • Legacy Issue Number: 19260
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    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.

  • Reported: CPP11 1.1 — Wed, 26 Feb 2014 05:00 GMT
  • Disposition: Closed; No Change — CPP11 1.2
  • Disposition Summary:

    Valueboxes should have swap support

    The issue proposed the support of swap for valueboxes but valueboxes are valuetypes which are reference types which already have swap support, also the boxed type has swap support. It doesn't add any value to define swap support for valueboxes because that can't be used at all, it is the valuetype reference and the boxed type that can be swapped and they have already swap support

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

provide unique class name as mapping of PortableServer::Servant

  • Key: ITCR-8
  • Legacy Issue Number: 19035
  • Status: closed  
  • Source: langensoft.com ( T. Langen)
  • Summary:

    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.

  • Reported: CPP11 1.1 — Mon, 28 Oct 2013 04:00 GMT
  • Disposition: Duplicate or Merged — CPP11 1.2
  • Disposition Summary:

    Provide correct mapping for Servant

    Both Servant and ServantBase are used in 6.26.2, this should be Servant, but that has already been resolved as part of ITCR-7

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

Constructor declarations in Servant code are wrong

  • Key: ITCR-7
  • Legacy Issue Number: 18850
  • Status: closed  
  • Source: Remedy IT ( Marcel Smit)
  • Summary:

    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'

  • Reported: CPP11 1.1 — Fri, 2 Aug 2013 04:00 GMT
  • Disposition: Resolved — CPP11 1.2
  • Disposition Summary:

    Correct constructor declarations of Servant

    ServantBase is a left over of the old IDL to C++ specification, in IDL to C++11 we only should use Servant

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

Destructors of strong reference types should be public

  • Key: ITCR-6
  • Legacy Issue Number: 18849
  • Status: closed  
  • Source: Remedy IT ( Marcel Smit)
  • Summary:

    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.

  • Reported: CPP11 1.1 — Fri, 2 Aug 2013 04:00 GMT
  • Disposition: Resolved — CPP11 1.2
  • Disposition Summary:

    Destructor of reference types should be public

    Reference types just have a regular destructor, not protected, else they can't be put on the stack.

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

Mention move constructor with abstract

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

    for 6.19.1 to the bullet list should be added

    a protected move constructor

  • Reported: CPP11 1.1 — Fri, 15 Aug 2014 04:00 GMT
  • Disposition: Resolved — CPP11 1.2
  • Disposition Summary:

    Correct constructors of AbstractBase

    As proposed by the submitter the move constructor should be mentioned, but also the copy/move assignment operators should be mentioned. The val argument name should be removed because it doesn't add any value

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

usage of OBV trait should be improved

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

    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.

  • Reported: CPP11 1.1 — Wed, 13 Aug 2014 04:00 GMT
  • Disposition: Resolved — CPP11 1.2
  • Disposition Summary:

    Correct usage of OBV trait

    The concept of a OBV class is coming from the IDL to C++ language mapping, IDL to C++11 should use the concept of the obv_type trait

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

Add missing default initialization for valuetypes

  • Key: ITCR-10
  • Legacy Issue Number: 19207
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    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.

  • Reported: CPP11 1.1 — Fri, 7 Feb 2014 05:00 GMT
  • Disposition: Resolved — CPP11 1.2
  • Disposition Summary:

    Add missing behavior of the default constructor

    As suggested by the submitter the behavior of the default constructor for the OBV classes should be mentioned

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

wrong return type for Foo::some_function()

  • Key: ITCR-9
  • Legacy Issue Number: 19036
  • Status: closed  
  • Source: langensoft.com ( T. Langen)
  • Summary:

    The return type should be

    IDL::traits<Test::Hello>::ref_type

    instead of

    CORBA::servant_traits<Test::Hello>::ref_type

  • Reported: CPP11 1.1 — Mon, 28 Oct 2013 04:00 GMT
  • Disposition: Resolved — CPP11 1.2
  • Disposition Summary:

    Correct return type of example method

    In the example code as part of section 6.23.3 the incorrect return type is given. The correction as suggested by the submitter is the correct one

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

Question on unions default member

  • Key: ITCR-5
  • Legacy Issue Number: 18832
  • Status: closed  
  • Source: THALES ( Nawel Hamouche)
  • 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?

  • Reported: CPP11 1.1 — Thu, 25 Jul 2013 04:00 GMT
  • Disposition: Resolved — CPP11 1.2
  • Disposition Summary:

    Improve description of union

    After some prototyping and looking at the normal C+11 unions we propose to initialize the union in all other cases to the first discriminant in IDL, this is matching C+11 unions

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

Move constructor of ValueBase incorrect

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

    The listed move constructor of ValueBase is incorrect, it should be

    ValueBase(ValueBase&&);

  • Reported: CPP11 1.1 — Wed, 13 Aug 2014 04:00 GMT
  • Disposition: Resolved — CPP11 1.2
  • Disposition Summary:

    Correct move constructor of ValueBase

    Proposal is to accept the changed as made by submitter

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

Missing move assignment operator in class ColorValue

  • Key: ITCR-14
  • Legacy Issue Number: 19575
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The class ColorValue as example is missing the move assignment operator which should be:

    ColorValue(& operator= (ColorValue(&&)

  • Reported: CPP11 1.1 — Wed, 13 Aug 2014 04:00 GMT
  • Disposition: Resolved — CPP11 1.2
  • Disposition Summary:

    Correct provided signature for valuebox types

    Triggered by this issue we addressed the incorrectly provided signature for valuebox types. Also the argument name "val" got removed because it doesn't add any value and we don't want to propose a specific name (which could clash when the user for example defines a valuebox of type val)

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

fixed member types use incorrect type

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

    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

  • Reported: CPP11 1.1 — Mon, 18 Aug 2014 04:00 GMT
  • Disposition: Resolved — CPP11 1.2
  • Disposition Summary:

    Replace uint32_t with uint16_t as proposed

    Proposal is to replace uint32_t with uint16_t as proposed, the digits and scale are both uint16_t

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

Destructor should just be virtual

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

    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

  • Reported: CPP11 1.1 — Fri, 15 Aug 2014 04:00 GMT
  • Disposition: Resolved — CPP11 1.2
  • Disposition Summary:

    Make destructor just virtual

    Proposal is to make the destructor of abstract base "protected virtual" as proposed by the submitter

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

IDL2C++11 issue : CORBA dependency of the C++11 mapping

  • Key: ITCR-2
  • Legacy Issue Number: 18533
  • Status: closed  
  • Source: THALES ( Nawel Hamouche)
  • 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
  • Reported: CPP11 1.1 — Thu, 7 Mar 2013 05:00 GMT
  • Disposition: Deferred — CPP11 1.2
  • Disposition Summary:

    Defer to future RTF

    The IDLC+11 language mapping explicitly refers to CORBA v3.2 because there is no clean IDL specification yet. There should first be a clean IDL4 specification that is completely middleware agnostic and which gives generic guidelines for language mappings how to target specific middleware technologies like CORBA. After that someone has to implement this and see if there are no unforeseen issues, when that all has been done we can update the IDL2C+11 specification accordingly

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

Make mapping of sequences more flexible

  • Key: ITCR-13
  • Legacy Issue Number: 19499
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    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.

  • Reported: CPP11 1.1 — Tue, 1 Jul 2014 04:00 GMT
  • Disposition: Deferred — CPP11 1.2
  • Disposition Summary:

    Defer to future RTF

    Deferring to RTF because we haven't been able to prototype this in order to validate that there are no unforeseen problems.

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