IDL4 to C++ Language Mapping Avatar
  1. OMG Specification

IDL4 to C++ Language Mapping — Open Issues

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

Issues Descriptions

Add Example Transformation

  • Key: IDL4CPP-20
  • Status: open  
  • Source: Dassault Systemes ( Daniel Brookshier)
  • Summary:

    Not sure where (not necessarily in the noted paragraph) should include a reference to an electronic mapping file as an example. Could also include test sample IDL and corresponding C++ output. This should probably be informational and could also be in an Annex. The key reason is to show the actual transformation as well as a test/verification of the mappings. Perhaps also include versions of tools/compiler used in which the transformations were validated. In addition unit tests could be referenced or included as informative content to the spec.

  • Reported: IDL4-CPP 1.0a1 — Thu, 28 Sep 2023 20:50 GMT
  • Updated: Tue, 10 Oct 2023 13:30 GMT

@value annotation does not fully specify its behavior

  • Key: IDL4CPP-9
  • Status: open  
  • Source: Real-Time Innovations ( Fernando Garcia-Aranda)
  • Summary:

    The @value annotation does not fully specify the behavior. That includes:

    • The behavior for unannotated values.
    • The behavior for repeated values. Is it possible like in C++?

    DDS-XTYPES does specify the behavior of @value and such description should be added to IDL:

    7.3.1.2.1.5 Enumerated Literal Values
    Prior to this specification, it was impossible to indicate that objects of enumerated types could be stored using an integer size other than 32 bits. This specification uses the @bit_bound annotation defined in Sub Clause 8.3.4.1 of [IDL] for this purpose.

    It is important to note that the value member of the annotation may take any value from 1 to 32, inclusive, when this annotation is applied to an enumerated type. Furthermore, prior to this specification, it was impossible to provide an explicit value for an enumerated literal. The value was always inferred based on the definition order of the literals. That behavior is still supported. However, additionally, this specification allows enumerated literals to be given explicit custom values, just as they can be in the C and C++ programming
    languages. This can be done by means of the @value annotation defined in Sub Clause 8.3.1.5 of [IDL], which may be applied to individual literals.
    It is permitted for some literals in an enumerated type to bear the @value annotation while others do not. In such cases, as in C and C++ enumerations, implicit values are assigned in a progression starting from the most-recently specified value (or an implicit value of zero for the first literal, if there is no previous specified value) and adding one with each successive literal.

  • Reported: IDL4-CPP 1.0a1 — Tue, 20 Jun 2023 17:54 GMT
  • Updated: Tue, 26 Sep 2023 21:36 GMT

Use of @range is inconsistent with IDL4 grammar

  • Key: IDL4CPP-8
  • Status: open  
  • Source: Real-Time Innovations ( Fernando Garcia-Aranda)
  • Summary:

    According to IDL4, annotations like range need to specify the arguments that are set. However, in the example we include for the mapping of @range we don't specify min and max in the arguments.

    We need to address that as follows:

    struct StructureOfRangedValues {
        @range(min=-10, max=10) long x;
    };
    
  • Reported: IDL4-CPP 1.0a1 — Tue, 20 Jun 2023 17:54 GMT
  • Updated: Tue, 26 Sep 2023 21:34 GMT

Specify how IDL maps compare their keys

  • Key: IDL4CPP-1
  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Adam Mitz)
  • Summary:

    Keys of maps can be any IDL type. How should the generated C++ code support key comparison of any type?

  • Reported: IDL4-CPP 1.0a1 — Tue, 21 Mar 2023 17:53 GMT
  • Updated: Tue, 26 Sep 2023 19:10 GMT