Description | Differences | Compliance Issue? |
---|---|---|
type of DomainId_t (native in spec IDL) |
|
NO (clearly the DDS spec intent is signed 32-bit int
but it's not required) |
use of namespace DDS |
|
NO (C++ mapping requires it, but it's obtainable from all vendors) |
mapping of IDL modules to namespaces |
|
NO (C++ mapping requires it, but it's obtainable from all vendors) |
use of CORBA _ptr and _var types |
|
YES (It's an IDL to C++ mapping issue) |
use of CORBA basic types |
|
YES (Not a CORBA issue but IDL to C++ mapping - see section 1.3) |
scope of generation from implied IDL |
|
UNKNOWN (I can't find any reference to it in the DDS spec) |
type registration |
|
YES (Only TAO DDS is conpliant here - see section 1.3 of IDL C++ mapping) |
type of [datatype]Seq max length |
|
YES (C++ mapping prescribes IDL sequence length as CORBA::ULong) |
resolution of DomainParticipantFactory |
|
YES (TAO DDS is non-compliant) |
passing of ConditionSeq to wait() |
|
YES (RTI DDS is compliant with IDL C++ mapping) |
passing of [datatype]Seq and
SampleInfoSeq to take() |
|
YES (RTI DDS is compliant with IDL C++ mapping) |
identifier for generated downcasting method |
|
YES (RTI DDS is non-compliant with IDL C++ mapping) |
StatusMask arg in create_* methods |
|
YES (RTI DDS compliant with DDS 1.1 & 1.2, others compliant only with DDS 1.0) |
proprietary listener methods |
|
YES (the extra methods are pure virtual, and must be recognized and implemented) |