IDL4 to CPP Language Mapping Avatar
  1. OMG Specification

IDL4 to CPP Language Mapping — Open Issues

  • Acronym: IDL4-CPP
  • Issues Count: 13
  • Description: Issues not resolved
Open Closed All
Issues not resolved

Issues Descriptions

constexpr constructors missing

  • Status: open  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    In user code I want to use constexpr for IDL fixed values, for example

    constexr F pi

    {3.142857}

    ;

    But in order for that to work a constexpr constructor has to be available, the spec should define that

  • Reported: IDL4-CPP 1.0b1 — Wed, 4 Sep 2024 07:19 GMT
  • Updated: Wed, 4 Sep 2024 14:18 GMT

Mapping to std::shared_ptr allows to much

  • Status: open   Implementation work Blocked
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    In the context of CORBA it is not legal to just compare object references with operator==/!= which are both provided by std:;shared_ptr. The fact that the local client proxy is different doesn't mean the called CORBA servant is different, in IDL to C+11 comparing two interfaces is illegal (see 6.7.2 of IDL to C+11). This specification should make it clear that omg::types::ref_type<T> should not be comparable

  • Reported: IDL4-CPP 1.0b1 — Wed, 21 Aug 2024 07:15 GMT
  • Updated: Wed, 4 Sep 2024 14:14 GMT

Don't require operator ==/!=

  • Status: open  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The spec says for structured types "A set of comparison operators, including at least "equal to" and "not equal to."", but that is not possible when the structure contains interfaces, valuetypes, valueboxes, abstract, all special types don't provide a operator==/!= so they can't be required when a structure contains any of these. This requirement has to be removed. CORBA doesn't provide equal for these special types because a local != doesn't mean that the references are not pointing to the same servant, object identity is not done through local pointers

  • Reported: IDL4-CPP 1.0b1 — Mon, 19 Aug 2024 07:14 GMT
  • Updated: Wed, 4 Sep 2024 14:10 GMT

CORBA::CustomerMarshal typo

  • Status: open  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    CORBA::CustomerMarshal should be CORBA::CustomMarshal

  • Reported: IDL4-CPP 1.0b1 — Mon, 19 Aug 2024 07:09 GMT
  • Updated: Wed, 4 Sep 2024 14:09 GMT

CORBA or non CORBA usage results in non compatible exceptions code

  • Status: open   Implementation work Blocked
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The spec describes that with CORBA an invalid usage of union can result in a CORBA::BAD_PARAM exception, for bounded string/vector also a CORBA::BAD_PARAM, but when not using CORBA when IDL4CSP11-9 is resolved a different exception is thrown for an union (for vector it seems this still has to be added also). When a user now has appliation code that uses IDL defined data types with and without CORBA their exception code is different. In order to achieve portability of user code I think the spec should define a omg::bad_param alias type which maps to CORBA::BAD_PARAM or the selected std exception. That way user code can be written portable when the user has data types defined by IDL and wants to support use cases with and without CORBA

  • Reported: IDL4-CPP 1.0b1 — Sun, 3 Mar 2024 07:23 GMT
  • Updated: Fri, 21 Jun 2024 17:37 GMT


Use consistant initialization

  • Status: open  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    the code examples use = and {} to initialize the constants, recommend to make this consistent by always using {}

  • Reported: IDL4-CPP 1.0b1 — Fri, 12 Apr 2024 09:55 GMT
  • Updated: Fri, 21 Jun 2024 17:37 GMT

range/min/max underspecified

  • Status: open  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    A few remarks on 7.17.3:

    • formatting of code in text is not done
    • what is the impact of range when applied to a typedef of a basic type on all argument passing rules when that typedef is passed with a function, stored in an union or exception?
    • how should min/max be implemented, shouldn't also omg::types::ranged be used?
    • what should be done when min/max but also range are used as annotation?
  • Reported: IDL4-CPP 1.0b1 — Wed, 24 Jan 2024 08:58 GMT
  • Updated: Fri, 21 Jun 2024 17:37 GMT

Remove IDL to C++11 spec extensions

  • Status: open  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    I find it not very maintainable to extend in this spec silently the IDL to C++11 language mapping. In the v1.7 revision I think all is already mapped, so I propose to remove D.3 completely from this spec

  • Reported: IDL4-CPP 1.0b1 — Thu, 25 Jan 2024 12:53 GMT
  • Updated: Fri, 21 Jun 2024 17:37 GMT


Implicit default and constructor

  • Status: open  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    Spec says:

    If the union has a default case, the default constructor shall initialize the discriminator, and the selected
    member field following the initialization rules described in Clause 7.2.4.3.1. If it does not, the default
    constructor shall initialize the union to the first discriminant value specified in the IDL definition.

    But when there is an implicit default member, that should be selected, for example, the example below (

      enum DataType
      {
        dtEmpty,
        dtLong,
        dtShort,
        dtString,
        dtPoint,
        dtTrack,
        dtGlobal
      };
    
      union Data switch (DataType)
        {
          case dtLong: long longData;
          case dtShort: short shortData;
          case dtString: string stringData;
          case dtPoint: string pointData;
          case dtTrack: string trackData;
          case dtGlobal: string globalData;
          // by default (implicit), empty union
        };
    
  • Reported: IDL4-CPP 1.0b1 — Tue, 16 Jan 2024 09:36 GMT
  • Updated: Fri, 21 Jun 2024 17:37 GMT

Problem with member accessor

  • Status: open  
  • Source: Remedy IT Expertise BV ( Johnny Willemsen)
  • Summary:

    The spec gives:

    const <MemberType>& <MemberName>() const

    But for basic types/int this will result in a warning, for basic/enum it should be

    <MemberType> <MemberName>() const

  • Reported: IDL4-CPP 1.0b1 — Tue, 4 Apr 2023 07:47 GMT
  • Updated: Tue, 4 Apr 2023 19:11 GMT

Spec should specify behaviour

  • Status: open  
  • Source: Remedy IT Expertise BV ( Johnny Willemsen)
  • Summary:

    The spec says:

    A public constant accessor method with the name of the union member that returns a constant reference to
    its value:
    const <MemberType>& <MemberName>() const;
    Accessing an invalid union member may result in an undefined error.

    A language mapping should be precise and very clear to my idea, the user should know what happens if an invalid union member is accessed, this could happen in some cases, the spec should specify which exception will be thrown so that the programmer can react on this, saying it is undefined is not enough.

  • Reported: IDL4-CPP 1.0b1 — Wed, 29 Mar 2023 07:50 GMT
  • Updated: Fri, 31 Mar 2023 18:26 GMT