ISO/IEC C++ 2003 Language DDS PSM Avatar
  1. OMG Specification

ISO/IEC C++ 2003 Language DDS PSM — Open Issues

  • Acronym: DDS-PSM-Cxx
  • Issues Count: 5
  • Description: Issues not resolved
Open Closed All
Issues not resolved

Issues Descriptions

Default Constructors

  • Status: open  
  • Source: Real-Time Innovations ( Sumant Tambe)
  • Summary:

    Reference types do not have default constructors, forcing the use of nullptr to construct null references. This runs counter to modern C++ conventions; for example, consider C++11 smart pointers. Forcing explicit initialization also prevents the sensible use of compiler-generated default constructors for objects containing DDS objects as members.

    To get the behavior I want, I've to define constructor and destructor for a struct for no purpose other than to initialize a member instance handle to null, or just make it a std::unique_ptr<dds::core::InstanceHandle> and circumvent the API.

  • Reported: DDS-PSM-Cxx 1.0b2 — Mon, 25 Jan 2016 19:02 GMT
  • Updated: Tue, 13 Sep 2016 22:25 GMT

Condition classes should only be used with WaitSets

  • Legacy Issue Number: 17063
  • Status: open  
  • Source: Anonymous
  • Summary:

    The DataReader API provides methods to read samples with a condition. This condition can be either a ReadCondition or a QueryCondition, and in this case the samples returned are either filtered by the status (ReadCondition) or the content+status (QueryCondition).
    The ReadCondition is completely in overlap with the instance/status/view states and its use is really irrelevant when in combination with the DataReader. On the other end the only aspect of the QueryCondition that really matters to a DataReader are the query expression and parameters.

    By looking carefully at the API, it seems apparent that the ReadCondition and the QueryCondition really make sense only when used with a WaitSet. On the other end, their use in conjunction of a DataReader is a stretch and breaks the semantics of the "Condition". On principle a condition is used to "wait" for a particular status to be true, yet the DataReader "read" are – rightfully – always non-blocking. In addition, the API opens up for gratuitous runtime errors as I could write silly code as follows (in C++):

    auto rc = reader.create_readcondition();, rc,...);

    This although silly is allowed by the API and on a proper DDS implementation should raise an exception.

    The same could happen with a QueryCondition!

    Limit the use of Read/QueryCondition to waitsets and put in place a more robust mechanism to do status and content filtering on a data-reader read.

    An example of what could be done is provided below, where I assume that the DataStatus is the former ReaderState:

    .filter_content(Query("x < 100 AND y < 100"))

    Equally, one could write (again legal C++ below with little magic under-cover) :

    .filter_content(Query("x < 100 AND y < 100"))

    Notice that this code, not only is very declarative and thus shows very clearly the intent of the programmer, but in addition does not allow for the silly mistakes shown above. Further more, it really highlights he role of the Sample/Instance/View status as a "filter" on the status of data.

  • Reported: DDS-PSM-Cxx 1.0b2 — Thu, 26 Jan 2012 05:00 GMT
  • Updated: Fri, 18 Sep 2015 03:05 GMT

Ownership label SHARED is already defined as a macro in some SUN compilers

  • Status: open  
  • Source: PrismTech ( Erik Hendriks)
  • Summary:

    Some SUN compilers have predefined a macro called SHARED. This clashes with the definition of the enumeration label SHARED for the OwnershipKind_def struct.

    We suggest to add some conditional code to undef the SUN macro in that case.

    git diff:

    --- a/include/dds/core/policy/PolicyKind.hpp
    +++ b/include/dds/core/policy/PolicyKind.hpp
    @@ -29,6 +29,10 @@ namespace core
     namespace policy
    +/** @todo raise spec issue **/
    +#if defined (__SUNPRO_CC) && defined(SHARED)
    +#   undef SHARED
     struct OwnershipKind_def
         enum Type
  • Reported: DDS-PSM-Cxx 1.0b2 — Mon, 13 Apr 2015 15:32 GMT
  • Updated: Mon, 11 May 2015 11:02 GMT

Compilation error in dds/core/policy/PolicyKind.hpp

  • Status: open  
  • Source: PrismTech ( Erik Hendriks)
  • Summary:

    The enumeration for the TypeConsistencyEnforcementKind_def is not scoped by a struct, as all the other enumerations, but by a namespace. This should be fixed.

    git diff:

    @@ -96,7 +96,7 @@ namespace dds { namespace core { namespace policy {
         }; };
       typedef dds::core::safe_enum<LivelinessKind_def> LivelinessKind;
    -  namespace TypeConsistencyEnforcementKind_def {
    +  struct TypeConsistencyEnforcementKind_def {
         enum type {
  • Reported: DDS-PSM-Cxx 1.0b2 — Mon, 13 Apr 2015 13:46 GMT
  • Updated: Mon, 11 May 2015 11:00 GMT

EntityQos is overly general

  • Legacy Issue Number: 18445
  • Status: open  
  • Source: Real-Time Innovations ( Sumant Tambe)
  • Summary:

    EntityQos template is a rather overly general way of setting and getting policies. Member template functions generate the code depending upon the policy type. If you pass a wrong type, it eventually ends up showing a link-time error as opposed to a compile-time error. For instance, there is a link-time error in the code below because DataWriterQos has no presentation policy.

    dds::pub::qos::DataWriterQos dwqos;
    dds::core::policy::Deadline d;
    dds::core::policy::Presentation p;
    dwqos >> p; /// Linker error here. No compile-time error
    dwqos >> d; /// Fine!

    Additionally, the dot operator provides no help for syntax completion because the policy function is a member template. Consequently, the end-user might be tempted to use the -> operator, which does provide syntax completion depending upon the implementation of the delegate. As a result, for standard policies -> will be used, which is unintended.

    Proposed Resolution:

    1. Add template classes DataReaderQos, DataWriterQoS, PublisherQos, SubscriberQos, DomainParticipantQos in the dds namespace.

    2. Support non-template member functions for setting and getting respective policies. For instance. dwqos.deadline() and dwqos.deadline(d) should be supported.

    3. Define operator << and operator >> outside the QoS class and overload for the respective policies.

    4. The templated verions of policy getters/setters can still be supported. However, I seriously doubt their usefulness. If we decide to keep them, at least I would like to turn the linker error into compiler error using a meta-programming technique described here:

  • Reported: DDS-PSM-Cxx 1.0b2 — Tue, 12 Feb 2013 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT