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

IDL to C++11 Language Mapping — All Issues

  • Acronym: CPP11
  • Issues Count: 11
  • Description: All Issues
Closed All
All Issues

Issues Descriptions

Incorrect constructor referenced in Fixed description

  • Key: CPP1117-8
  • Status: closed  
  • Source: Remedy IT Expertise BV ( Johnny Willemsen)
  • Summary:

    This chapter says:

    The Fixed(std::string&) constructor converts a string representation of a fixed-point literal, with an optional leading sign (+ or -) and an optional trailing ‘d’ or ‘D’, into a real fixed-point value.

    But there is no constructor that accepts a non-const std::string&, the text should say

    The Fixed(const std::string&) constructor converts a string representation of a
    fixed-point literal, with an optional leading sign (+ or -) and an optional trailing ‘d’ or ‘D’, into a real fixed-point value.

  • Reported: CPP11 1.6b1 — Tue, 10 Jan 2023 15:56 GMT
  • Disposition: Resolved — CPP11 1.7
  • Disposition Summary:

    Correct the spec text to match the source code

    Add the missing "const" as described in the issue.

  • Updated: Tue, 9 Jan 2024 19:49 GMT

Typo

  • Key: CPP1117-9
  • Status: closed  
  • Source: Remedy IT Expertise BV ( Johnny Willemsen)
  • Summary:

    Double "to to" in the first sentence:

    IDL bitset types are mapped to to C++ structs that meet the C++11 requirements for aggregate initialization.

    Should be

    IDL bitset types are mapped to C++ structs that meet the C++11 requirements for aggregate initialization.

  • Reported: CPP11 1.6b1 — Mon, 17 Jul 2023 08:54 GMT
  • Disposition: Resolved — CPP11 1.7
  • Disposition Summary:

    Fix typo

    As per issue description

  • Updated: Tue, 9 Jan 2024 19:49 GMT

Missing annotation mapping

  • Key: CPP1117-13
  • Status: closed   Implementation work Blocked
  • Source: Remedy IT Expertise BV ( Johnny Willemsen)
  • Summary:

    The spec should mention how the IDL4-mentioned annotations impact the mapping, I think the spec should list at least @value, @default_literal, @default, @range @min @max @bit_bound @external

    See IDL4 to CPP and the IDL4 spec itself

  • Reported: CPP11 1.6b1 — Fri, 4 Aug 2023 07:01 GMT
  • Disposition: Resolved — CPP11 1.7
  • Disposition Summary:

    Add mappings for some more IDL 4 Standardized Annotations

    New mappings for @value, @default_literal, @default, and @bit_bound – in each case drawing from uses in the beta IDL4-to-C++ mapping and/or XTypes.

  • Updated: Tue, 9 Jan 2024 19:49 GMT

Missing description related to union member modifier

  • Key: CPP1117-7
  • Status: closed  
  • Source: Remedy IT Expertise BV ( Johnny Willemsen)
  • Summary:

    In the specification an addition was made about the default argument when the union member has multiple legal discriminator values:

    Union members associated with the "default" label and those associated with multiple labels may have multiple legal discriminator values. For these members, the modifiers (those that return void) have a second parameter which has the discriminator's type. This parameter has a default argument. For members associated with multiple labels, the value of the default argument is the value of the case label that appears first in IDL. For members associated with the default label, the value of the default argument is an implementation-defined value that selects the member.

    There is nothing in the text that describes what happens when a discriminator value is passed which doesn't belong to the member, this is implicitly in the example code further down "u.obj(a, 2)", but this should be explicit in the text also, passing a not allowed discriminator should result in a BAD_PARAM exception

  • Reported: CPP11 1.6b1 — Tue, 10 Jan 2023 09:20 GMT
  • Disposition: Resolved — CPP11 1.7
  • Disposition Summary:

    Add description of error handling for 2-parameter union modifier functions

    To be consistent with the existing parts of the spec, make it clear that invalid parameters result in a BAD_PARAM exception.

  • Updated: Tue, 9 Jan 2024 19:49 GMT

Change struct VariableExt constructor

  • Key: CPP1117-11
  • Status: closed   Implementation work Blocked
  • Source: Remedy IT Expertise BV ( Johnny Willemsen)
  • Summary:

    Instead of `VariableExt(const Variable&, bool);` it should be `VariableExt(Variable, bool);` so that in the implementation we can use std::move, this is as all complex types are passed into the constructor of a struct

  • Reported: CPP11 1.6b1 — Wed, 2 Aug 2023 08:42 GMT
  • Disposition: Resolved — CPP11 1.7
  • Disposition Summary:

    In example code, function signature of constructors is non-normative

    In section 6.31.3 make it clear that the specific types of the constructor parameters (if they use pass by value or pass by const-reference) is up to the implementation.

  • Updated: Tue, 9 Jan 2024 19:49 GMT

Improve bitmask mapping

  • Key: CPP1117-10
  • Status: closed   Implementation work Blocked
  • Source: Remedy IT Expertise BV ( Johnny Willemsen)
  • Summary:

    The bitmask mapping is very basic, it doesn't give any type safety or more modern API. The spec should be improved, the <X>Bits type should be removed, only one type should be used. Also when there are multiple bitmasks with the same bitfield name they could result in a name clash. Maybe map to a enum class and add the operators ~,|,^,& for the enum class as inline operations to modify the enum class as a bitmask. At that moment the Bit type can be removed.

    When time permits I will make a proof of concept for TAOX11

  • Reported: CPP11 1.6b1 — Mon, 31 Jul 2023 06:55 GMT
  • Disposition: Deferred — CPP11 1.7
  • Disposition Summary:

    Defer breaking change to the bitmask mapping

    The existing mapping in IDL-to-C++11 is based on DDS XTypes where it has been in a formal standard for a number of years.
    There are certainly reasons to have a mapping that makes better use of the C++ type system, but this would come at a cost in terms of divergence from OMG precedent.

  • Updated: Tue, 9 Jan 2024 19:49 GMT

Add standardized annotation to override the IDL map to std::map mapping

  • Key: CPP1117-1
  • Status: closed  
  • Source: Remedy IT Expertise BV ( Johnny Willemsen)
  • Summary:

    For some use cases it would be more efficient to map a IDL map to a std::unordered_map (see https://en.cppreference.com/w/cpp/container/unordered_map), maybe standardize an annotation which can be used to override the mapping to std::map to the type as specified by the annotation?

  • Reported: CPP11 1.7 — Wed, 17 Aug 2022 08:55 GMT
  • Disposition: Deferred — CPP11 1.7
  • Disposition Summary:

    Defer

    Other languages have similar issues like using TreeMap or HashMap in Java.

    Defer resolution on this until standard annotation can be provided in the IDL 4 spec or the IDL Working Group has a common approach to use across language mappings.

  • Updated: Tue, 9 Jan 2024 19:49 GMT

Typo in example

  • Key: CPP1117-2
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    using M2 = IDL::bounded_map<std::string, T, 20;

    should be

    using M2 = IDL::bounded_map<std::string, T, 20>;

  • Reported: CPP11 1.7 — Wed, 20 Oct 2021 06:24 GMT
  • Disposition: Closed; No Change — CPP11 1.7
  • Disposition Summary:

    Typo is not in base document

    ptc/21-11-02 doesn't have this typo

  • Updated: Tue, 9 Jan 2024 19:49 GMT

6.7.8 Argument Passing Considerations should refer to "Basic Data Types" not "primitive"

  • Key: CPP1117-3
  • Status: closed  
  • Source: Leonardo S.p.A ( Simon McQueen)
  • Summary:

    The section says:

    "For all primitive types, enums, and
    reference types, an in argument A of type P, that argument is passed as P. For all other types, an in argument A of type P is
    passed as const P&. For an inout and out argument it is passed as P&. If we return a type of P, it is returned as P."

    This is the only use of "primitive types" in the spec. "Basic Data Types" should be preferred. Would suggest:

    "For all Basic Data Types [link/ref to 6.6 Mapping for Basic Data Types], enums [link/ref to 6.9 Mapping for Enums], and
    reference types [link/ref to 6.7.1 Reference Types], an in argument A of type P, that argument is passed as P. For all other types, an in argument A of type P is
    passed as const P&. For an inout and out argument it is passed as P&. If we return a type of P, it is returned as P."

  • Reported: CPP11 1.7 — Fri, 10 Dec 2021 15:02 GMT
  • Disposition: Resolved — CPP11 1.7
  • Disposition Summary:

    Update text in Arg Passing to refer to Basic Data Types

    Update as specified in parent issue

  • Updated: Tue, 9 Jan 2024 19:49 GMT

bit_bound

  • Key: CPP1117-14
  • Status: closed  
  • Source: Remedy IT Expertise BV ( Johnny Willemsen)
  • Summary:

    The spec defines the type trait bit_bound as `std::integral_constant<uint32_t, b>`, but as bit_bound is maximal of 64, this could be `std::integral_constant<uint8_t, b>`

  • Reported: CPP11 1.6b1 — Mon, 7 Aug 2023 07:29 GMT
  • Disposition: Resolved — CPP11 1.7
  • Disposition Summary:

    Update type used for bit_bound in bit mask traits

    The integral_constant template from the C++ standard library should be instantiated with uint8_t instead of uint32_t

  • Updated: Tue, 9 Jan 2024 19:49 GMT

Add bit_bound/underlying_type for enum traits

  • Key: CPP1117-12
  • Status: closed  
  • Source: Remedy IT Expertise BV ( Johnny Willemsen)
  • Summary:

    The bit_bound annotation can be applied to the enum, so the bit_bound and underlying_type traits should also be added to the enum

  • Reported: CPP11 1.6b1 — Sat, 5 Aug 2023 14:47 GMT
  • Disposition: Duplicate or Merged — CPP11 1.7
  • Disposition Summary:

    Add type traits for enums

    Including this in the resolution to CPP1117-13.

  • Updated: Tue, 9 Jan 2024 19:49 GMT