Proposal is to add a @cpp_mapping as IDL4toC++ has, to enable users to select a mapping of IDL struct to a C++ struct (that mapping itself has to be added here also)
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
CORBA::CustomerMarshal, should be CORBA::CustomMarshal,
CORBA::CustomerMarshal should be CORBA::CustomMarshal
In order to get a type system which is CORBA independent we propose to change the exception which can be thrown by the union from CORBA::BAD_PARAM to std::invalid_argument. The impact for users is minimal as they can except std exceptions from the other std types they already use through this language mapping.
The specification lacks a description how to map the @external annotation
The IDL to C++11 spec lacks a mapping for the min/max/range annotations
The spec says "In case the union has an implicit default member it is initialized to that case", but it doesn't specify what is an implicit default member, maybe add "i.e., if the union does not have a default case and not all permissive discriminator values are listed"
The default annotation is not just for struct members, also for exception/union members but it can also be applied to a type, so also for example attributes of an interface/component/connector can have a default, all code generation related to that should also use the default whenever one is needed (for example starter code generation)
All IDL/C++ that is used in the text should be have a different font like done in the other parts of the spec, that is for example int8_t/uint8_t/Base::Base/
There shouldn't be a semi colon after the namespace closure, this is done in more places in the spec, search for "namespace", closing should be "}" and not "};", see chapters 6.3/6.5/6.23.1/6.26.2/6.27.2/6.28/6.29
For the following places the declared destructors should be using override and not virtual as they override the base class destructor. This should happen to:
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.
Correct the spec text to match the source code
Add the missing "const" as described in the issue.
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.
Fix typo
As per issue description
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
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.
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
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.
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
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.
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
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.
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>`
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
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
Add type traits for enums
Including this in the resolution to CPP1117-13.
For the optional mapping example a `void age(IDL::optional<float>&&)` is lacking, like described for some types in chapter 6.14
For the example code, for the setter, the std::optional should be passed as const&, see https://stackoverflow.com/questions/69277649/does-passing-an-stdoptionalt-by-reference-actually-save-copying
Within the text of chapter 6.31/6.32 (IDL4) all C++/IDL should use a different font to make it clear it is code, just as in the other chapters.
For anyone using the class mapping of a structure the spec should also provide a class mapping for a bitset, that way they have a consistent API. Also why is a inherited bitset not mapped to C++ inheritance, by removing the inheritance the inheritance relation can't be used in C++ also
The spec has the following sentence:
The _d discriminator modifier can only be used to set the discriminant to a value within the same union member.
This is not really clear and should be improved, maybe
The _d discriminator modifier can only be used to set the discriminant to a value that has the same union member as currently selected.
The spec has the following sentence:
The _d discriminator modifier can only be used to set the discriminant to a value within the same union member.
This is not really clear and should be improved, maybe
The _d discriminator modifier can only be used to set the discriminant to a value that has the same union member as currently selected.
The specification should specify the mapping of @optional, maybe maybe to IDL::optional which could be an using of std::optional with C+17, only for C11/C+14 at that moment the API of IDL::optional should be specified
Map optional struct members
Unlike other standardized annotations that are impact the middleware platform, the IDL @optional annotation impacts the language mapping.
The @extensibilty(FINAL) or @final annotation is one of the new annotations in IDL4.2, see 8.3.16 of IDL4.2. Should the generated class for a struct/union which is annotated with @final be generated as a C++11 final class or not? So
struct Foo final {}
or
struct Foo {}
Extensibility annotations do not impact the language mapping
The concept of type extensibility is defined in IDL4.2 as "specifying how
the element is allowed to evolve." The language mappings determine how each IDL source file is mapped. In terms of this "evolution," the mapping is just capturing a single point in time. Neither of the IDL4-specific mappings (C# or Java) map extensibility to a programming language feature.
For template programming it could be helpful to have a IDL::traits<>::bit_bound trait of type std::integral_constant which returns the bit_bound set in IDL for a bitmask
Add traits member specification to Bit Masks section
Specify the bit_bound member of IDL::traits for Bit Masks
The example code has
OBV_Example (int16_t, int32_t, std::string, IDL::traits<Example>::ref_type;
But this is not correct, it should be
OBV_Example (int16_t, int32_t, std::string, IDL::traits<Example>::ref_type);
Fix invalid example code
A closing parenthesis was missing from the example code.
For creating a client side reference the specification uses currently CORBA::make_reference but this logic is not really CORBA specific and in a LwCCM system which only uses local interfaces the usage of CORBA is polluting user code. One of the key concepts of IDL to C++11 is that the user doesn't need to remember any special naming rules so we don't want to tie a factory function to some implementation name. The IDL to C++11 specification already uses the IDL::traits<> concept which is specialized based on the IDL type. We propose to extend the IDL::traits<> for interfaces/valuetypes for a make_reference factory method so that user code given an interface A can create an object reference using IDL::traits<A>::make_reference.
In the specification we propose the following changes:
6.7.1, replace CORBA::make_reference with IDL::traits<>::make_reference
6.18.7.1 replace CORBA::make_reference <StringValue> with IDL::traits<StringValue>::make_reference
6.18.10.2 replace CORBA::make_reference<> with IDL::traits<>::make_reference
6.25 replace CORBA::make_reference<> with IDL::traits<>::make_reference and CORBA::make_reference <MyLocalIF> (); with IDL::traits<MyLocalIF>::make_reference ();
The CORBA::make_reference() can be easily kept by an implementation for backwards compatibility but this proposal enables the user to write code that is more CORBA independent
Move make_reference into the traits class
The CORBA::make_reference function template as currently specified is a top-level member of the CORBA namespace. Some uses of IDL (and this mapping) are non-CORBA, for example lightweight CCM/UCM or DDS. This change moves make_reference into the traits which lives in the IDL top-level namespace.
Page footers look like:
C++11 Language Mapping, v1.4 iii
This issue is a duplicate of issue 5
Apols for not checking before raising.
The spec says the following:
The constructor which “accepts values for each struct member in the order they are specified in IDL” also accepts, as its first parameter, an object of the mapped base type (passed by const reference)
As user of a IDL inherited struct I would expect I can pass the members of the base type after the members of the inherited struct, not an instance of the base type. So, when there is a 2DPoint with members X and Y and a 3DPoint derived from that with member Z, I would expect to call a constructor with Z, X, Y .
Also the spec should require that a the inheriting constructor concept should be supported (see https://arne-mertz.de/2015/08/new-c-features-inherited-and-delegating-constructors/), so we can initialize a 3DPoint with only X and Y where Z receives its default value.
The remark of "passed by const reference" which is now part of the spec should be removed, that is an implementation decision, it could be that pass by value is more performant (see for example https://abseil.io/tips/117)
An example would be really helpful in this case, provide an example IDL construct with the example C++11 code expected.
Update struct inheritance mapping
The section "Structures with Single Inheritance" needs a minor update and an example
In the footer it says "C++11 Language Mapping, v1.4", but it should be "C++11 Language Mapping, v1.5"
No RTF change needed
Footer is correct in formal/21-05-01 (IDL-to-C++11 1.5).
The IDL to C++11 tries to prevent the user from remembering all kind of special naming rules. The spec now uses "<Bitmask>Bits" but that is something we want to prevent, we propose to use a IDL::traits<>::bits which can be used as a generic way to use this special "<Bitmask>Bits" type in code. It could happen that there is also a user type "<Bitmask>Bits" in IDL, how is this now handled? When IDL::traits<>::bits is used the naming of the implied type is an implementation decision
Also a C++11 strong enum should be used instead of an old enum to prevent the enumerator values to pollute the containing namespace, the current approach doesn't work when there are 2 bitmasks with the same set of enumerators, the code below doesn't compile
enum MyBitMaskBits : std::uint8_t
{ flag0 = 1, flag1 = 2, flag4 = 16, f6 = 64};;
Update bitmask IDL traits
Update IDL traits for bitmask types.
We propose to replace std::uint8_t in the example code with uint8_t, for all integer types the spec doesn't list the std namespace
Duplicates issue 8
Duplicate of issue 8
Why is bitset inheritance not mapped to struct inheritance, that would simplify the code for BitSet2 in this example.
No change needed
Using struct inheritance would mean that the last member of the base couldn't share the same byte with the first member of the derived. Essentially this is a difference between what C++ inheritance of structs means when structs have bitfields and the semantics defined by IDL.
The destructor should change from
virtual ~V_factory();
to
~V_factory() override;
The virtual is redundant, that is already in the base
Update the code in 6.18.10.2
Modern C++ usage is to prefer the override keyword to virtual.
We propose to replace std::uint8_t in the example code with uint8_t, for all integer types the spec doesn't list the std namespace
No change needed
The identifier uint8_t is defined by the ISO C++ standard as a member of namespace std, so this spec uses the namespace as well.
In the example code the destructor should change from
virtual ~ColorValue();
to
~ColorValue() override;
Update the code in 6.18.7.2
Modern C++ usage is to prefer the override keyword to virtual.
For the switch of unions, the C++ mapping uses the name _d.
It would be desirable to permit names that reflect the users' application domain.
Example:
enum environment_t { air, water, land };
union env_info_t switch (@switchname("environment") environment_t) {
case air:
air_info_t air_info;
case water:
[...]
};
The @switchname annotation would cause a getter/setter of the given name to be generated in addition to the _d() accessors.
In the above example:
void environment(environment_t); // alias for _d(environment_t) environment_t environment() const; // alias for _d()
Depends on an IDL spec change
Defer until the IDL 4.3 RTF resolves IDL43-42.
IDL4.2 defines in section 8.3 a set of standardized annotations where it looks some of them impact the IDL to C++11 language mapping like @optional, @final, @range, @default and maybe others. There should be a new paragraph in the IDL to C++11 language mapping which describes how these standardized annotations map to C++11, like @optional to std::optional, @final to final, etc
Defer work on this issue
IDL 4.2 has 24 Standardized Annotations which vary widely in terms of their applicability to a language mapping. Since other RTF issues request specific annotations that are more urgent, defer this broad issue to the next RTF.
In the TIE chapter replace ServantBase with Servant, ServantBase is from the old IDL to C++ spec, in C++11 this should be Servant, see CPP1115-2
Replace ServantBase with Servant
The term ServantBase appears in section 6.26.8, this is a holdover from the original IDL-to-C++ mapping. The term Servant should now replace it.
C++11 introduced the "using" keyword (see https://en.cppreference.com/w/cpp/language/type_alias) as alternative way to specify a type alias. In terms of C++11 support usage it would be a good thing to update all example C++11 code within the specification to use "using" instead of "typedef"
Use the C++11 type alias feature in examples
C++11 has type aliasing with the "using" keyword, which is typically preferred to using the "typedef" syntax inherited from C.
The IDL to C++11 language mapping got extended to allow setting the union value and discriminator in one operation, see https://issues.omg.org/issues/CPP1114-14. This could be done in this language mapping also, but keep the discriminator, that keeps it backwards compatible
The IDL to C++11 language mapping section 6.31 should be extended for struct inheritance as it is now part of IDL4 (Building Block Extended Data-Types)
Support for struct inheritance
Add mapping for IDL4 struct inheritance
Add support for int8 which is a new type, the other (u)int(8/16/32/64) are just aliases so don't need to be in the language mapping
Add int8/uint8 mapping
Add a new subsection in 6.31 for IDL int8/uint8
The V_factory should have deleted assignment/copy so add
private:
V_factory (const V_factory&) = delete;
V_factory (V_factory&&) = delete;
V_factory& operator =(const V_factory&) = delete;
V_factory& operator =(V_factory&&) = delete;
In the text change
Each generated factory class has a protected virtual destructor, a protected default constructor.
to
Each generated factory class has a protected virtual destructor, a protected default constructor, deleted copy/move constructors, and deleted copy/move assignment operators
Add deleted special member functions to type-specific value factories
Use the "= delete" feature of C++11.
ValueBase has only a protected copy/move copy constructor to allow a derived class to make a copy, the assignment operators are deleted, because of this also for a valuebox the assignment operators should be deleted, so the 3rd bullet should be updated from
Protected copy and move assignment operators
to
Private deleted copy and move assignment operators
And in the code example
ColorValue& operator=(const ColorValue&);
ColorValue& operator=(ColorValue&&);
to
ColorValue& operator=(const ColorValue&) = delete;
ColorValue& operator=(ColorValue&&) = delete;
Duplicates issues CPP1115-5
This appears to be a duplicate
The valuebox created should be using final, so add to the bullets of 6.18.7.2 a first bullet saying "Must be final" and change in the code
class ColorValue : public ValueBase
to
class ColorValue : public ValueBase final
Use the C++ final specifier on value box classes
Make use of the "final" capability of C++11
ValueBase has only a protected copy/move copy constructor to allow a derived class to make a copy, the assignment operators are deleted, because of this also for a valuebox the assignment operators should be deleted, so the 3rd bullet should be updated from
Protected copy and move assignment operators
to
Private deleted copy and move assignment operators
And in the code example
ColorValue& operator=(const ColorValue&);
ColorValue& operator=(ColorValue&&);
to
ColorValue& operator=(const ColorValue&) = delete;
ColorValue& operator=(ColorValue&&) = delete;
Value box classes shouldn't be assignable
Update to work with ValueBase
ValueFactoryBase should have deleted assignment/copy operators so add to the code part
private:
ValueFactoryBase (ValueFactoryBase&&) = delete;
ValueFactoryBase (const ValueFactoryBase&) = delete;
ValueFactoryBase& operator =(const ValueFactoryBase&) = delete;
ValueFactoryBase& operator =(ValueFactoryBase&&) = delete;
Add deleted special member functions to ValueFactoryBase
Use the C++11 "= delete" feature for ValueFactoryBase.
Any C++11 operation in the spec which uses override shouldn't have virtual, that is redundant and shouldn't be done, so for example
virtual void val2 (int32_t) override;
Should be
void val2 (int32_t) override;
Easiest is to search for override and check that any operation that has override doesn't have virtual
Remove uses of the C++ virtual keyword that aren't needed
Member functions declared with "override" should not also have "virtual"
The operation _default_POA currently declared as
IDL::traits<PortableServer::POA>::ref_type _default_POA()
Should be
IDL::traits<PortableServer::POA>::ref_type _default_POA() override
Also the formatting of the constructor of the TIE template should be changed, hard to read. Initializing the members could use std::move so change
: tied_object_(t), poa_(poa)
to
: tied_object_(std::move(t)), poa_(std::move(poa))
Updated code for Delegation-Based Interface Implementation
Update code to reflect C++ best practices
The IDL to C++11 language mapping section 6.31 should be extended for bitset/bitfield/bitmask from IDL4 (Building Block Extended Data-Types)
Bitset and Bitmask mapping
Bitsets and bitmasks are "top-level" IDL4 extended data types that can each be mapped to C++11.
The current IDL to C++11 language mapping only describes an inheritance based interface implementation in chapter 6.26.6. The IDL to C++ language mapping also described a delegation based implementation. We propose to add a delegation based implementation to the IDL to C++11 specification.
I will attach a proposal new chapter 6.26.7, only the formatting of IDL and C++ types has to be done in the final document, especially types in the text itself need to be formatted. In the first paragraph there is a number 126, that has to be updated.
Mapping for implementing interfaces via delegation
This issue adds the mapping for implementing interfaces via delegation, a feature of the IDL-to-C++ mapping that has been lacking in this spec.
The C++11 mapping of an IDL union seems to follow that of the classic C++ mapping, where the discriminator does not only have a getter-operation, but also a setter operation. This operation has been added for situations where more than one case label applies to to the same union branch, and the setter operation for that union branch implicitly sets the discriminant value to the first case label that was specified. If you want to pick another value, you should do so by invoking the setter function for the discriminant.
However, this setter operation is confusing to many users, and some seem to think you need to use it every time you passed a value into a branch different than the current branch. On top of that. it seems cumbersome to have to make two separate method invocations to request a single modification that is intended to set branch value and corresponding discriminator value atomically.
Much better would be to take the route that has been adopted in the Java language mapping for the union: if there is more than one case label that applies to a union branch, you add an overloaded setter method for that branch that does not only allow you to pass the value for that branch, but also the value for the discriminator. This overloaded setter function will than validate whether the discriminant value you pass actually applies to the branch that you are trying to set.
Unions: Provide a way to set both the discriminator and value at the same time
Enhance the mapping of IDL union to allow setting the discriminator at the same time a new union element value is provided. This change maintains compatibility for applications written to the current spec version.
Compared to V1.2 in 6.7.6 four bullets before IDL::traits<A>::narrow(ap) got removed
Make part of 6.7.6 a bulleted list
This was somehow lost between v1.2 and v1.3.
The OBV_Example constructor has multiple arguments and shouldn't be explicit. Also a closing ) is lacking from the example code. The operations for val2 should also use "override"
Update OBV_Example class in 6.18.4
Updates as suggested, making the C++ example code consistent with the prose of 6.18.2 and common conventions.
The operation "virtual int16_6& val1() = 0;" is not aligned correctly in the code example
Fix C++ code in 6.18.4
Fixing a minor typo/formatting bug in this section.
Section 6.11 on page 11, 2nd paragraph:
Implementations of the bounded wide string are under no oblication to perform a bounds check [...]
obligation
Table 6.10 on page 14, bottom row, right column
dimensions std::integral_constant type of value_type uint32_t indicating the
number of dimensaions of the array
[...] dimensions of the array
Section 6.18.7.2 page 30 top, continuation of code from p.29
protected: ColorValue(); xplicit ColorValue(Color);
explicit ColorValue(Color);
Section 6.19.1 on page 34, code for class AbstractBase
class AbstractBase { public: virtual IDL::traits<Object>::ref_type _to_object(); virtual IDL::traits<ValueBase>::ref_type _to_value(); protected: AbstractBase(); bstractBase(const AbstractBase&);
AbstractBase(const AbstractBase&);
Section 6.22.2 on page 40 top (code continued from p.39)
int16_t fixed_scale() const; Visibility member_visibility(uin32_t index) const;
Type of index argument should be uint32_t.
Fix typos
The submitted issue (CPP1114-7) lists a few other typos, but those are already fixed in formal/18-01-06.
For struct/exception/valuetype the spec describes that a constructor accepting values for all members has to generated as explicit constructor, but it only has to be explicit when there is one (1) member, when there are >1 member the constructor doesn't need to be explicit. This has to be updated in the text and examples
Reporter of the Issue has asked for it to be withdrawn
Closing this one by request of Reporter.
In the submission document, Table 21 "IDL Built-in Annotations" does not list where the annotation @hashid can be applied.
Also, the @id annotation is can be applied to both Structure members and union members (except union discriminator), so it should be moved to the second row on the table.
Issue was added to the wrong RTF
This issue is not in IDL-to-C++11.
In 6.12 we define:
An unbounded sequence is mapped to a C++ std::vector.
For example a sequence of octets is now not optimal, in order for implementations to optimize sequences but users not to harm we propose to change this definition to
An unbounded sequence is mapped to a type delivering C++ std::vector semantics.
Flexible mapping for sequence and map types
Allow implementations more flexibility: in certain cases when the spec currently requires use of a C++ standard library type, the implementation should be able to use a substitute type that's interface-compatible.
A big effort have been done to remove CORBA dependency from the IDL2C++11 mapping, but it still specifies a CORBA semantic to the IDL
interfaces and user exceptions. In 6.6.4, it is said "Conceptually, the Object class in the CORBA module is the base interface type for all objects;" this assertion breaks all that efforts. I think the semantic of IDL interfaces should be abstracted by defining a middleware-independent Object type as the super type of all IDL interfaces, it could be IDL::Object. Likewise, CORBA::UserException and CORBA::SystemException could be abstracted by defining IDL::UserExeption and IDL::SystemException.
Looking to the IDL3.5 specification, it is true that this specification is still tied to CORBA, but special care has been done to separate between the syntactical construct and its semantic. For instance, it is said 'See the CORBA 3.2 specfication Section 10.2 “Semantics of Abstract Interfaces” for CORBA implementation semantics associated with abstract interfaces.'. It means that there could be other semantics than CORBA.
I would suggest the following changes in the IDL2CPP11 specification :
IDL v4 is a standalone specification
This specification has no normative reference for IDL v4.
I have implementation experience applying portions of this spec to a non-CORBA middleware (which happens to be a DDS implementation). Those sections of this spec that apply (6.3, 6.4, 6.5, 6.6, 6.8-16, 6.30-31) do not use the CORBA module/namespace.
There are two main motivations:
(1) Performance: IDL types may be large and not all IDL types may have C++11 mapping with efficient move constructors. For example, an IDL structure containing an array does not have an efficient move-ctor. Current mapping for an IDL struct type (section 6.13.1) requires an explicit constructor accepting values for each member by value in the order they are specified in IDL. Although this method is sufficient in most cases, it is not optimal. Particularly, the types that don't support efficient move-ctor.
(2) Usability: Often C+11 standard library containers could be constructed using several alternatives. For instance, a string member in a struct may be constructed using any of its 9 constructors or a vector may be constructed using any of its 7 constructors. Currently, the IDL2C+11 specification allows construction of members of a structure using only two kinds of constructors: copy-ctor and move-ctor. (due to the pass-by-value rule mentioned above)
Resolution: The IDL2C++11 mapping of structures could be enhanced to construct large objects in-place. Provide a way to construct the member objects of a struct in-place using a perfect-forwarding constructor. The intent is to support all the ways of constructing all the member objects from the constructor of the parent object. Moreover, a perfect-forwarding constructor may eliminate the need for a move, which may lead to some performance improvements.
The solution relies on an idiom known as piecewise_construct idiom. It relies on a perfect-forwarding constructor that takes as many tuples as there are members in a struct. Each tuple encapsulates the parameters to construct one member. Tuples are needed because member ctor could take several parameters and the user may be interested in using them. For instance, using an allocator for std::vector. The user of the struct calls std::forward_as_tuple for each member object to group the parameters in a tuple. The special constructor simply forwards the tuples to the respective member.
The C++ standard library uses this idiom for std::map and std::unordered_map to construct complex objects in-place using the emplace operations. However, more general uses have been identified: http://cpptruths.blogspot.com/2012/06/perfect-forwarding-of-parameter-groups.html
Existing alternatives for struct construction appear to be sufficient
Since the issue has been unresolved for a number of RTFs I'm proposing we close it now.
The proposed enhancement could be provided by implementations as an extension to the spec-mandated behavior.
I don't argue that there is some benefit from this approach, but there is also implementation complexity: when generating a struct constructor, the tool will need to know, for each struct member, which constructor parameters that member can take. Those parameters can vary based on versions of the C++ standard library (for types like std::string, vector, array, map).
Reduce the indent of public, should start on the first line, makes it all more readable
Update source code formatting
Remove extra indenting that can force line wrapping and make embedded source code hard to read.
There are tabs between bool and the method names, they should be removed
Update code in 6.26.2
Minor formatting change as suggested.
The C++11 IDL language mapping for IDL struct datatypes was changed to a Java-style getter & setter interface. This should be reverted for the following reasons:
1. The original struct mapping (just use data members) performs better at compile and runtime. The new mapping compiles slower by changing each data member to 4! different accessor functions, and at runtime is slower due to the need for the function call. (Modern compilers cannot optimize this call away without global optimization, which is not generally available in C++ implementations, or else the accessor functions must all be defined inline for the compiler to optimize away the function call.)
2. Java style getter and setter interfaces are not considered good C++ style by the experts. https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#c131-avoid-trivial-getters-and-setters
3. The change breaks massive amount of user code for no benefit.
Structure mapping shouldn't change within a minor revision of IDL-to-C++11
Keep in mind that IDL-to-C++ and IDL-to-C++11 are independent specifications. In cases where IDL-to-C++11 takes a different approach to mapping the same IDL features, this isn't a "change" from the spec's point of view.
However, I'm sympathetic to the notion that it could be a "change" from an implementer/user's point of view as a single IDL translation tool that previously used just IDL-to-C++ could, in a new version, use IDL-to-C++11 (either exclusively or as an option). Since I help maintain some IDL translation tools that do this, I've had to deal with this myself.
One thing to note is that nothing in IDL-to-C++11 prevents the implementation from providing public data members in mapped structs. Unfortunately the names of those data members would be non-standard. Also, as described in the comments on the parent issue, direct data member usage makes upcoming IDLv4 features like @min/@max harder to support.
The fixed type was changed from the old C++ mapping, removing the non-template Fixed class and mandating that Fixed be implemented as a template. These changes disrupted the careful design of Fixed support for C++ in several ways:
1. There is now no information or guidance about what type is used when declaring a fixed constant in IDL.
2. The original specification was careful to not mandate whether the C++ mapping used a template definition to enforce constant digits and scale values for fixed point data defined in IDL, yet specifically states that the user should only use the typedefs generated by the IDL compiler Thus the current specification unnecessarily limits implementation choice for fixed point support for no useful implementation purpose.
3. Removal of the non-template Fixed class makes it harder for the implementation to meet the "double precision (62 digit)" arithmetic guarantee.
The C++ mapping for Fixed should be restored use the language of the old C++ 1.3 language mapping.
Updates to the mapping of the IDL Fixed data type
Change the mapping of the IDL fixed type data to allow some more implementation flexibility and familiarity from the IDL-to-C++ mapping.
In the submission document, Table 21 "IDL Built-in Annotations" does not list where the annotation @hashid can be applied.
Also, the @id annotation is can be applied to both Structure members and union members (except union discriminator), so it should be moved to the second row on the table.
This Issue was not resolved in this Task Force and was automatically deferred to the next Task Force
A big effort have been done to remove CORBA dependency from the IDL2C++11 mapping, but it still specifies a CORBA semantic to the IDL
interfaces and user exceptions. In 6.6.4, it is said "Conceptually, the Object class in the CORBA module is the base interface type for all objects;" this assertion breaks all that efforts. I think the semantic of IDL interfaces should be abstracted by defining a middleware-independent Object type as the super type of all IDL interfaces, it could be IDL::Object. Likewise, CORBA::UserException and CORBA::SystemException could be abstracted by defining IDL::UserExeption and IDL::SystemException.
Looking to the IDL3.5 specification, it is true that this specification is still tied to CORBA, but special care has been done to separate between the syntactical construct and its semantic. For instance, it is said 'See the CORBA 3.2 specfication Section 10.2 “Semantics of Abstract Interfaces” for CORBA implementation semantics associated with abstract interfaces.'. It means that there could be other semantics than CORBA.
I would suggest the following changes in the IDL2CPP11 specification :
Deferred
Deferred to future RTF
In 6.12 we define:
An unbounded sequence is mapped to a C++ std::vector.
For example a sequence of octets is now not optimal, in order for implementations to optimize sequences but users not to harm we propose to change this definition to
An unbounded sequence is mapped to a type delivering C++ std::vector semantics.
Deferred
Deferred
There are two main motivations:
(1) Performance: IDL types may be large and not all IDL types may have C++11 mapping with efficient move constructors. For example, an IDL structure containing an array does not have an efficient move-ctor. Current mapping for an IDL struct type (section 6.13.1) requires an explicit constructor accepting values for each member by value in the order they are specified in IDL. Although this method is sufficient in most cases, it is not optimal. Particularly, the types that don't support efficient move-ctor.
(2) Usability: Often C+11 standard library containers could be constructed using several alternatives. For instance, a string member in a struct may be constructed using any of its 9 constructors or a vector may be constructed using any of its 7 constructors. Currently, the IDL2C+11 specification allows construction of members of a structure using only two kinds of constructors: copy-ctor and move-ctor. (due to the pass-by-value rule mentioned above)
Resolution: The IDL2C++11 mapping of structures could be enhanced to construct large objects in-place. Provide a way to construct the member objects of a struct in-place using a perfect-forwarding constructor. The intent is to support all the ways of constructing all the member objects from the constructor of the parent object. Moreover, a perfect-forwarding constructor may eliminate the need for a move, which may lead to some performance improvements.
The solution relies on an idiom known as piecewise_construct idiom. It relies on a perfect-forwarding constructor that takes as many tuples as there are members in a struct. Each tuple encapsulates the parameters to construct one member. Tuples are needed because member ctor could take several parameters and the user may be interested in using them. For instance, using an allocator for std::vector. The user of the struct calls std::forward_as_tuple for each member object to group the parameters in a tuple. The special constructor simply forwards the tuples to the respective member.
The C++ standard library uses this idiom for std::map and std::unordered_map to construct complex objects in-place using the emplace operations. However, more general uses have been identified: http://cpptruths.blogspot.com/2012/06/perfect-forwarding-of-parameter-groups.html
Deferred
Without specific spec wording from someone who has implemented it, I don't think we can standardize this feature.
The mapping for constants should use uniform initialization in section 6.8 instead of using the assignment. The code
const std::string name = "testing";
static constexpr float pi = 3.14159;
Should be
const std::string name
;
static constexpr float pi
;
IDL constants should use C++ direct list initializaiton
When IDL constants are mapped to C++, they become namespace or class scoped const (or constexpr) objects. Use direct list initialization to give these objects values.
The DDS-XTypes specification extends the IDL type system which will be integrated into the IDL4 specification. The IDL2C++11 mapping should be extended with a new section describing the support for the IDL map type.
Import the mapping of IDL Map from XTypes 1.2
XTypes 1.2 (beta) ptc/17-03-06 section 7.5.1.3.4 maps the IDL Map type to "Modern C++", that mapping can be used by this spec directly
The code example as part of 6.18.7.2 has:
ColorValue& operator=(const Color&);
but this should be
ColorValue& operator=(const ColorValue&);
Fix argument type of copy assignment operator in 6.18.7.2
Looks to be a typo in the original spec. The class name is ColorValue which should be used here
In section 6.7.1 in the 4th paragraph the CORBA::make_reference<> is mentioned, but it ends using "using perfect forwarding". Where this is probably the best way to implement this, it shouldn't be mandated by the specification. Propose to remove "using perfect forwarding" from the text of this paragraph
Relax requirement for perfect forwarding in 6.7.1
The C++ idea of "perfect forwarding" doesn't need to be specified here. An implementation may decide to use it.
Because of the mapping of Exception to something derived from std::exception where is a possible conflict when the user has an exception member with the member name "what" because std::exception provides an operation what(). We propose to change the start of section 6.20 to the text below instead of the first two bullets currently in the specification
An OMG IDL exception is mapped to a C++ class that derives from the standard UserException class. Each OMG IDL exception member maps to a set of corresponding member methods as described in “Mapping for Structured Types” on page 14. When the IDL exception member identifier is "what", the string “cxx” is prepended to the identifier to resolve a conflict with the std::exception what() operation.
The copy constructor, move constructor, copy assignment operator, move assignment operator, and destructor automatically copy, move, or free the storage associated with the exception. For convenience, the mapping also defines an explicit constructor with one parameter for each exception member in the order they are specified in IDL—this constructor initializes the exception members to the given values. The default constructor initializes all members to their default values as described in “Mapping for Structured Types” on page 14.
Possible name conflict involving "what" and exceptions.
See Johnny's comment on issue #4
In 6.14.1 (mapping for struct type) the second sentence is
Additionally to the methods as described in “Mapping for Structured Types” on page 14 an explicit constructor accepting values for struct each member in the order they are specified in IDL.
This should be
Additionally to the methods as described in “Mapping for Structured Types” on page 14 an explicit constructor accepting values for each struct member in the order they are specified in IDL.
The order of "struct" and "each" should be swapped
Edit section 6.14.1 for clarity
Updated prose description of mapped struct, C++ remains unchanged.
For SystemException class on page 36 mentions
const int32_t& minor() const;
void minor(const int32_t&);
But this is a basic type which we pass by value. Also minor should be an uint32_t, the code should list
uint32_t minor() const;
void minor(uint32_t);
Also the CompletionStatus is returned by value, no need for a const, so change
const CompletionStatus completed() const;
to
CompletionStatus completed() const;
As last the constructor
explicit SystemException(int32_t minor, CompletionStatus status);
Should be
SystemException(uint32_t minor, CompletionStatus status);
SystemException updates
Proposed resolution is included in Issue #2 description
The specification mentions that besides a namespace level swap a specialization of std::swap<> has to be provided, but that shouldn't, see http://en.cppreference.com/w/cpp/concept/Swappable. Only a namespace level swap should be enough. This impacts the text of section 6.7.1, the example and text of 6.14.1, example of 6.14.2
Remove std::swap requirement
Overload swap() in the appropriate namespace, do not do anything with std::swap.
In section 4 of paragraph 6.14.2 it says " If a modifier for a union member with multiple legal discriminant values is used to set the value of the discriminant, the union implementation will take the first discriminant specified in IDL.". It is not the "first discriminant" but the "first discriminant value". This is triggered by the resolution of ITCR-5
Clarify discriminant
The text should be clear to refer to "discriminant value"
The IDL to C++11 language mapping refers to CORBA v3.2, in the meantime CORBA v3.3 is there, so update the normative reference in section 3 to point to CORBA 3.3
Update reference
Update the reference to CORBA 3.3, there are no changes in CORBA 3.3 that impact IDL2C++11 but it is good to refer to the latest version of the CORBA specification
The DDS-XTypes specification extends the IDL type system which will be integrated into the IDL4 specification. The IDL2C++11 mapping should be extended with a new section describing the support for the IDL map type.
Defer to future RTF
We propose to defer this to the next RTF because we haven't been able to prototype this in order to validate some ideas we had. Especially the needed IDL::traits<> has to be tested and tried
Section 6.26.4 describes the argument passing for Servant, but this should use CORBA::servant_traits<PortableServer::Servant>::ref_type instead of CORBA::servant_traits<T>::ref_type
Servant argument passing not precise enough
The servant argument passing should be corrected as proposed by the issue
The last code example of section 6.26.6 lacks the public specifier for the class MyA. Instead of "class MyA : virtual" it should be "class MyA : public virtual"
Add missing public specifier
The issue is correct, the code example should use "public virtual" instead of just "virtual"
drop POA_B for skeleton class deriveved from abstract class and replace it adequately:
// C++
class A
class B_skel : public virtual ... /* maybe PortableServer::Servant */,
protected virtual A
;
Remove usage of B_Skel and remove mentioning of PortableServer::ServantBase
The report is correct, POA_B is a left over of the old IDL to C++ language mapping. At the same time we want to remove the mandatory inheritance of PortableServer::ServantBase, that is something for the vendor to decide, not important for the user.
_this() method example should be given for the skeleton (eg. A_skel), not for implementation (A_impl):
// C++
class A_skel
: public virtual PortableServer::Servant
Correct code example for _this
The code example defines the _this in the wrong class, it should be done in the skeleton class, not in the user implementation class. Because the example inheritance of the skeleton classes is up to the vendor also the inheritance of CORBA::servant_traits<A>::base_type should be removed and replaced with three dots. As last is the override something that should be removed.
Instead of the IDL interface class, the skeleton class should be used as template parameter for CORBA::servant_traits<>.
Rationale:
1. The servant which the traits describe is realized by an instance of a class derived from the skeleton class which in turn (directly or indireclty) inherits PortableServer::Servant but not necessarily the interface class.
PortableServant::Server < ... < CORBA::servant_traits<A_skel>::base_type < A_impl
instead of
PortableServant::Server < ... < CORBA::servant_traits<A>::base_type < A_impl
(A, A_skel and A_impl are arbitrary names denoting the interface, the skeleton and the implementation class, resp.).
2. In chapter 6.26.4 "Servant argument passing", we have CORBA::servant_traits<PortableServer::Servant>; this takes (the very basic) servant class as template parameter.
CORBA::servant_traits<PortableServer::Servant>::ref_type < CORBA::servant_traits<A_skel>::ref_type
instead of
CORBA::servant_traits<PortableServer::Servant>::ref_type < CORBA::servant_traits<A>::ref_type
3. In chapter 6.26.3 "Servant references" CORBA::make_reference<...> takes the implementation class as argument to create a CORBA::servant_traits<...>::ref_type. This would be more consistent with CORBA::make_reference<...> taking an interface class as parameter to create IDL::traits<...>::ref_type.
CORBA::make_reference<A_impl> -> CORBA::servant_traits<A_skel>::ref_type
like
CORBA::make_reference<A> -> IDL::traits<A>::ref_type
instead of
CORBA::make_reference<A_impl> -> CORBA::servant_traits<A>::ref_type
4. CORBA::servant_traits<...>::base_type is used as base class for implementation classes in §§ 6.26.6 and 6.26.7. Having CORBA::servant_traits<A_impl>::base_type instead of CORBA::servant_traits<A>::base_type is more consistent with the use of IDL::traits<LocalIF>::base_type denoting CORBA::LocalObject or something derived from CORBA::LocalObject.
CORBA::servant_traits<A_skel>::base_type < A_impl
like
IDL::traits<LocalIF>::base_type < MyLocalIf
instead of
CORBA::servant_traits<A>::base_type < A_impl
This affects all uses of servant_traits in §§ 6.26.3, 6.26.5, 6.26.6, 6.26.7.
The disadvantage to be considered is that the naming of the skeleton class is not standardized, so implementation classes to be provided by a programmer using an IDL to C++11 framework package cannot longer inherit a well-specified base class like CORBA::servant_traits<A>::base_type. Instead something like CORBA::servant_traits<skeleton<A>>:base_type would be required where skeleton<...> is a framework-specific template.
Keep referring to A instead of A_skel
One of the basic rules we defined for IDL2Cpp11 is that we don't want the user to remember all kind of rules to translate between the IDL name and some Cpp11 type. At the moment a IDL type is translated to multiple C++ types we are using the IDL traits. The concept of a skeleton exists in IDL2Cpp11 but the exact class of the skeleton is accessed by the user using the CORBA::servant_traits. The proposed change will complicate the life for the user without any benefit.
§ 6.26.6, to the end, about abstract interfaces:
I guess the C++ snippet should be like
// C++
class A
class B_skel : public virtual ... /* maybe PortableServer::Servant */,
protected virtual A
;
dropping the old POA_B thing.
There is an error in 6.25.6 related to the skeleton classes. The skeleton classes should derive from each other, not from the traits, so it should be as below, also C_skel is lacking.
// C++
class A_skel : public virtual PortableServer::ServantBase {};
class B_skel : public virtual A_skel {};
class C_skel : public virtual A_skel {};
class D_skel : public virtual B_skel, public virtual C_skel {};
The other code bits in this section also have to be checked and see if they are ok.
Correct skeleton inheritance
The traits shouldn't be used in this example, those are for user code.
There are two main motivations:
(1) Performance: IDL types may be large and not all IDL types may have C++11 mapping with efficient move constructors. For example, an IDL structure containing an array does not have an efficient move-ctor. Current mapping for an IDL struct type (section 6.13.1) requires an explicit constructor accepting values for each member by value in the order they are specified in IDL. Although this method is sufficient in most cases, it is not optimal. Particularly, the types that don't support efficient move-ctor.
(2) Usability: Often C+11 standard library containers could be constructed using several alternatives. For instance, a string member in a struct may be constructed using any of its 9 constructors or a vector may be constructed using any of its 7 constructors. Currently, the IDL2C+11 specification allows construction of members of a structure using only two kinds of constructors: copy-ctor and move-ctor. (due to the pass-by-value rule mentioned above)
Resolution: The IDL2C++11 mapping of structures could be enhanced to construct large objects in-place. Provide a way to construct the member objects of a struct in-place using a perfect-forwarding constructor. The intent is to support all the ways of constructing all the member objects from the constructor of the parent object. Moreover, a perfect-forwarding constructor may eliminate the need for a move, which may lead to some performance improvements.
The solution relies on an idiom known as piecewise_construct idiom. It relies on a perfect-forwarding constructor that takes as many tuples as there are members in a struct. Each tuple encapsulates the parameters to construct one member. Tuples are needed because member ctor could take several parameters and the user may be interested in using them. For instance, using an allocator for std::vector. The user of the struct calls std::forward_as_tuple for each member object to group the parameters in a tuple. The special constructor simply forwards the tuples to the respective member.
The C++ standard library uses this idiom for std::map and std::unordered_map to construct complex objects in-place using the emplace operations. However, more general uses have been identified: http://cpptruths.blogspot.com/2012/06/perfect-forwarding-of-parameter-groups.html
Defer to future RTF
The issues proposes an extension to the construction of structured types. A vendor could already add this as performance improvement without being it as part of the specification. Before adding this to the specification this addition first have to be shown in a concrete product to make sure it can be implemented and is usable for users. This hasn’t been done by any vendor yet which made us decide to defer this issue to a future RTF.
The valuetype factory mapping is too focused on the implementation, it should just refer to IDL<T>::factory_type as base class for the user provided factory implementation and shouldn't refer to ValueFactoryBase, that is an internal detail.
Ref devportal 3617
Clarify valuetype factory mapping
The current valuetype factory mapping ties the implementor of the specification to too much details, we should just mention the classes with their signatures and the traits.
For valueboxes the spec should also describe swap support, they are complete so they can support swap. To be added:
A namespace level swap and a specialization of std::swap<> must be provided to exchange the values of two valueboxes in an efficient matter.
Valueboxes should have swap support
The issue proposed the support of swap for valueboxes but valueboxes are valuetypes which are reference types which already have swap support, also the boxed type has swap support. It doesn't add any value to define swap support for valueboxes because that can't be used at all, it is the valuetype reference and the boxed type that can be swapped and they have already swap support
Both Servant and ServantBase for the same purpose are used in the declaration of the mapping of PortableServer::Servant.
Throughout this chapter Servant should be used unambiguously.
Provide correct mapping for Servant
Both Servant and ServantBase are used in 6.26.2, this should be Servant, but that has already been resolved as part of ITCR-7
The code on page 42 has a class named 'Servant' but the constructors in this piece of code are declared as 'ServantBase'. Also the =-operators are referring to 'ServantBase' instead of 'Servant'.
The text that follows this piece of code also talks about 'ServantBase' (in bold) instead of 'Servant'
Correct constructor declarations of Servant
ServantBase is a left over of the old IDL to C++ specification, in IDL to C++11 we only should use Servant
The spec dictates that the destructor of a strong reference type should be protected. Implementing this will lead to compile errors. Seems that this is a left over from the beta 1 spec.
Destructor of reference types should be public
Reference types just have a regular destructor, not protected, else they can't be put on the stack.
for 6.19.1 to the bullet list should be added
a protected move constructor
Correct constructors of AbstractBase
As proposed by the submitter the move constructor should be mentioned, but also the copy/move assignment operators should be mentioned. The val argument name should be removed because it doesn't add any value
The specicification currently lists:
The application developer then overrides the pure virtual functions corresponding to valuetype operations in a concrete class derived directly or indirectly from the OBV
trait.
It is not precise enough to juset say OBV traits, it should say
The application developer then overrides the pure virtual functions corresponding to valuetype operations in a concrete class derived directly or indirectly from the IDL::traits<>::obv_type
trait.
Correct usage of OBV trait
The concept of a OBV class is coming from the IDL to C++ language mapping, IDL to C++11 should use the concept of the obv_type trait
In 6.18.2 Constructors, Assignment Operators, and Destructors the default constructor of the OBV classes is mentioned. This lacks a description that it should initialize members, proposal is to add to 6.18.2, OBV part, after the first sentence add:
The default constructor initializes object
reference members to appropriately-typed nil object references, basic datatypes to their default value as listed in
Table 6.2, and enums to their first value. All other members are initialized using their default constructors.
Add missing behavior of the default constructor
As suggested by the submitter the behavior of the default constructor for the OBV classes should be mentioned
The return type should be
IDL::traits<Test::Hello>::ref_type
instead of
CORBA::servant_traits<Test::Hello>::ref_type
Correct return type of example method
In the example code as part of section 6.23.3 the incorrect return type is given. The correction as suggested by the submitter is the correct one
In the section 6.14.2 on union mapping, it says :
"If there is a default case specified, the union is initialized to this default case. In case the union has an implicit default member it is initialized to that case. In all other cases it is initialized as empty."
I don't get the meaning of "empty" and it doesn't seem to be defined. For example, if we have a union with a boolean discriminator which defines the two cases true and false, what happens if we read one of the fields or if we call _d (with or without parameter)? Should they all throw BAD_PARAM?
Improve description of union
After some prototyping and looking at the normal C+11 unions we propose to initialize the union in all other cases to the first discriminant in IDL, this is matching C+11 unions
The code snippet for the _this method should be using the A_skel class which is derived from PortableServer::ServantBase, not the impl class
Code fragment should use skel class
After carefully reviewing the specification and comparing it with our implementation we came to the conclusion that this issue is not correct. The specification is correct and nothing has to be changed in this chapter.
The listed move constructor of ValueBase is incorrect, it should be
ValueBase(ValueBase&&);
Correct move constructor of ValueBase
Proposal is to accept the changed as made by submitter
The class ColorValue as example is missing the move assignment operator which should be:
ColorValue(& operator= (ColorValue(&&)
Correct provided signature for valuebox types
Triggered by this issue we addressed the incorrectly provided signature for valuebox types. Also the argument name "val" got removed because it doesn't add any value and we don't want to propose a specific name (which could clash when the user for example defines a valuebox of type val)
In table 6.11 digits/scale are described, they should use uint16_t instead of uint32_t, see the above template, there also uint16_t is used
Replace uint32_t with uint16_t as proposed
Proposal is to replace uint32_t with uint16_t as proposed, the digits and scale are both uint16_t
for 6.19.1 to the bullet list mentions
a protected pure virtual destructor
This should be
a protected virtual destructor
it is not pure, see the example later on
Make destructor just virtual
Proposal is to make the destructor of abstract base "protected virtual" as proposed by the submitter
A big effort have been done to remove CORBA dependency from the IDL2C++11 mapping, but it still specifies a CORBA semantic to the IDL
interfaces and user exceptions. In 6.6.4, it is said "Conceptually, the Object class in the CORBA module is the base interface type for all objects;" this assertion breaks all that efforts. I think the semantic of IDL interfaces should be abstracted by defining a middleware-independent Object type as the super type of all IDL interfaces, it could be IDL::Object. Likewise, CORBA::UserException and CORBA::SystemException could be abstracted by defining IDL::UserExeption and IDL::SystemException.
Looking to the IDL3.5 specification, it is true that this specification is still tied to CORBA, but special care has been done to separate between the syntactical construct and its semantic. For instance, it is said 'See the CORBA 3.2 specfication Section 10.2 “Semantics of Abstract Interfaces” for CORBA implementation semantics associated with abstract interfaces.'. It means that there could be other semantics than CORBA.
I would suggest the following changes in the IDL2CPP11 specification :
Defer to future RTF
The IDLC+11 language mapping explicitly refers to CORBA v3.2 because there is no clean IDL specification yet. There should first be a clean IDL4 specification that is completely middleware agnostic and which gives generic guidelines for language mappings how to target specific middleware technologies like CORBA. After that someone has to implement this and see if there are no unforeseen issues, when that all has been done we can update the IDL2C+11 specification accordingly
In 6.12 we define:
An unbounded sequence is mapped to a C++ std::vector.
For example a sequence of octets is now not optimal, in order for implementations to optimize sequences but users not to harm we propose to change this definition to
An unbounded sequence is mapped to a type delivering C++ std::vector semantics.
Defer to future RTF
Deferring to RTF because we haven't been able to prototype this in order to validate that there are no unforeseen problems.
The question is about 99-07-41.pdf, as far as I know the latest C++ mapping specification. "1.41.5 Any Class" prescribes "Boolean operator>>=(const Any&, const char*&);" for unbounded strings, and "1.16.3 Extraction from any" says that unbounded strings are extracted by value. This seems to be contradictory: I seem to remember that const char* cannot be delete'd, though I don't find it in ISO/IEC 14882:1998(E). But, regardless of anything imposed by C++, the current mapping precludes a safe technique like (safe as in exception-proof): >> String_var theString; if(!(theAny>>=theString.out()))
{ ... }<< I therefore propose that the mapping be changed to "Boolean operator>>=(const Any&, char*&);". This seems to work all right on my implementation (RayORB), for gcc 3.2 (MS VC++ 6.0 doesn't seem to care one way or the other, but I suppose that is wrong, although I'm not entirely sure).
Summary: If I want to use the DII to send out multiple simultaneous requests, I don"t see a practical way to associate any client specific context that is C++ compliant to those requests.
Summary: For an IDL valuetype derived from other valuetypes or that supports
interface types, several C++ inheritance scenarios are possible:
...
Consider this example:
// IDL
interface I {};
abstract valuetype A supports I {};
valuetype B : A {};
Is a POA skeleton generated for A? Is one generated for B?
Summary: What happens when you pass a maximum argument that is less than the length
argument to the "T* data" constructor of an unbounded sequence? Should the
length argument be treated as equal to the max argument, or should an
implementation-defined error (such as an assert) be allowed?
What happens if you pass a null pointer for the buffer argument to the "T*
data" constructor of a sequence? Should the constructor create the sequence
as if it was created with the default constructor, or should an
implementation-defined error (such as an assert) be allowed? Should a null
pointer argument be allowed if the maximum and length arguments are zero?
No Data Available
Summary: What happens if I do:
Fixed f = "999999.999";
Fixed f2;
f2 = f.round(3, 1); // ???
f2 = f.truncate(3, 1); // ???
Should these throw DATA_CONVERSION? I think so – if we agree on this,
the spec should state it.
No Data Available
Summary: The Fixed mapping requires throwing DATA_CONVERSION if a value has more
than 31 integral digits:
Fixed f = 1E32; // DATA_CONVERSION
This raises the question of how to deal with Fixed types in environments
without C++ exceptions. Presumably, we need to add a CORBA::Environment
parameter everywhere. Unfortunately, that isn"t possible with the overloaded
operators that are currently defined.
Summary: The C++ mapping for the Portability Specification does not provide
reference counting for servants. This proposal adds reference
counting to the C++ mapping to ease memory management of
implementations. It borrows from the C++ language mapping from the
Objects by Value specification which does have reference counting for
values. Specifying the reference counting calls is important so that
both the Adapter implementation and multi-threaded application code
can cooperate to ensure that implementations are only deleted when no
longer used by any thread. Without specifying these calls, deadlocks
are extremely easy to introduce into the system.
No Data Available
Summary: 1. The C++ spec requires that all POA servant classes derive from
PortableServer::ServantBase as a virtual base class. For C++
environments without RTTI, it is then impossible for the programmer to
narrow a servant received from the POA via reference_to_servant() or
id_to_servant() back to the programmer"s specific servant class.
Proposal: Add a _narrow() operation to each POA servant class in the
same fashion that _narrow() operations are defined for exception
classes:
// IDL
interface A { };
// C++
class POA_A : public virtual PortableServer::ServantBase
;
The _narrow() operation will return a valid pointer if the servant isa
POA_A, otherwise it returns 0.
:ServantBase as a virtual base class. For C++
Summary: The question has arisen how the new Unicode escapes that were
introduced in the Java to IDL mapping should be mapped to C++.
There"s nothing about this in the C++ mapping chapter.
No Data Available
Summary: The C++ mapping for CORBA::Object does not specify the mappings for
hash, is_equivalent, is_a and non_existent methods. I am assuming
these map to _hash, _is_equivalent, _is_a and _non_existent. Is this
correct ?
duplicate of issue # 800, closed
Summary: Sec 3.13.2 para 25 describes freebuf. It doesn"t specify if storage associated with each element is released, i.e deep-free. Sun prefers that freebuf deep-free...
Close no change. This issue is already addressed in the CORBA 2.3 specification.
Summary: Is it legal to split IDL module declarations and to re-open a module similarly to what is done with C++ namespaces?
obsolete, cloe issue
This new language mapping has CORBA in several places. Part of it are really dependent on CORBA, but not all places. In order to make it more generable usable the spec has to be updated to reduce the dependency on CORBA by
As proposed by the issue we are removing the CORBA::foo_traits<> and use the generic new IDL::traits<>. This makes the client code independent on CORBA. We do keep the CORBA::make_reference to create a CORBA reference, CORBA::servant_traits<> for CORBA servant, and CORBA::Any
I recently got a query from a customer. Basically, they have a CORBA system
that interfaces to some legacy library. Lots of structures are being passed
back and forth, many of which contain strings; these need to be passed
as char * or as std::string, depending on where they go.
So, the customer defined conversion functions that correctly copied a
std::string or char * into and out of a string member (using string_dup()
or whatever, as appropriate). The problem is that they have to use
an undefined type name as the type of the parameter. For example:
void copy(const std::string & from, CORBA::string_mgr & to);
Of course, "string_mgr" is a mapping-internal type name and therefore the
code is non-portable.
I don't see an easy work-around that would be within the current mapping.
I could use a function that accepts a reference to a struct instead of
the string inside the struct, but that then means that I need a different
function for each structure type. Or I can write macros that are specific
to each ORB to handle it (but that is truly ugly and breaks if the vendor
decides to tinker with the internals of their mapping).
One way around it all would be to require a typedef to be generated for
string members. For example:
// IDL
struct Foo
;
// C++
namespace CORBA {
// ...
class string_mgr
; // Mapping-internal class
typedef string_mgr string_member; // New standard name
};
struct Foo
{ CORBA::string_mgr s; // Mapping-internal type name };
This would allow me to portably pass a string member to a function because
the mapping would guarantee the existence of a type named "string_member"
(or whatever name we can settle on).
void copy(const std::string & from, CORBA::string_member & to);
(Depending on the mapping implementation, there may be similar issues for
other types, such as references or arrays. If there are such mappings,
we'd need typedefs for those too.)
Basically, wherever a type name that is internal to the mapping can appear,
we end up with this kind of problem – I can't pass a value of that type
because I don't know the type name. I'd like to fix that, if possible.
rejected
In the first para of section 1.3.1, we still have a sentence about
the deprecated Ref names for object references. Those have been deprecated
for a long time now.
Proposal:
Remove the sentence beginning with "For historical reasons, the
type ARef..."
see below
In CORBA C++ 2.4 and before, the exception specification of generated
POA skeleton member functions is CORBA::SystemException plus the mapped C++
class for exceptions specified in the raise expression of the corresponding
IDL operation [see CORBA C++ 2.4 paragraph 23.27].
As a result, a servant programmer needs to convert any exception other than
those in the exception specification to one in the exception specification
– else the C++ runtime will call std::unexpected() if an unexpected
exception is thrown.
This makes exception handling on the server-side quite painful:
for example if a servant programmer calls operator new(), s/he's supposed
to catch std::bad_alloc and convert it to CORBA::NO_MEMORY. Similarly,
if s/he uses any of the ISO C++ libraries, s/he's supposed to convert the
std::exception objects raised by the library into CORBA::SystemExceptions,
or user-defined IDL exceptions.
Given that C++ compilers provide more and more features of ISO C++,
in particular the standard libraries, this is a real world issue!
Proposal
========
Add std::exception in the exception specification of generated
POA-skeleton member functions. The POA (or POA skeleton) implementation
is responsible to perform the following conversions:
std::bad_alloc to CORBA::NO_MEMORY
other std::exception to CORBA::UNKNOWN (see 3.17.1.1 in CORBA 2.3 core)
Source-code backward-compatibility
----------------------------------
I propose to make exception specifications in generated skeletons a bit
less restrictive than they were in CORBA C++ 2.4 (and before).
C++ servants written with the CORBA C++ 2.4 (and before) mapping do not
require any change – their exception specifications will be more
restrictive than required by the new mapping, which is perfectly correct.
Interoperability
----------------
It does not affect interoperability: only CORBA exceptions go on the
wire. An ORB-mediated operation can only raise a CORBA::SystemException
or a user-defined IDL exception.
Alternative Mapping for C++ Dialects
------------------------------------
Unfortunately, not all C++ compilers comply (or almost comply) with
ISO C+. With such a "C+ compiler", the ORB/POA implementation will
behave as in CORBA C++ 2.4 (i.e. no std::exception is the exception
specification). Or maybe we can allow the ORB/POA to add an
implementation-dependent class in the generated exception
specifications?
Portable user-written servants will simply include
CORBA::SystemException (or something more restrictive) in their
exception specifications.
see below
Details: This section (entitled 1.16.10 The Any Class) refers the reader to the full definition of the Any class. However, it provides the page number and section heading of itself – it is self referential.
Suggested Correction: The reference should refer to the section on page 1-150 (entitled 1.41.5 The Any Class)
see below
About two or three years ago, we decided to deprecate the read-only
nature of in params on the server side, and out params and return values
on the client side.
The second-last para of 1.13.2 still contains a remnant that we forgot
to clean up back then:
As with other out and return values, out and return sequences must
not be assigned to by the caller without first copying them.
I would suggest to modify this sentence to read:
For a sequence passed to an operation as an in parameter, the
operation must not assign to the sequence if its release flag
is false and the sequence has variable-length elements.
For a sequence passed to a client as an out parameter or return
value, the client must not assign to the sequence if its
release flag is false and the sequence has variable-length elements.
This captures more correctly the intent and the semantics of the release
flag (because assigning to a sequence with the release flag set to true
is perfectly OK).
see below
the spec talks about backward compatibility with the C mapping in a number
of places:
Binary compatibility with the C mapping has never existed and never will.
Proposal: Remove all mention of the C mapping from the above places.
Remove all mention of the C mapping from the above places.
formal/99-07-41 in section 1.36.3 includes the following code:
---------------- cut here ----------------
class ServantBase_var {
public:
~ServantBase_var ()
{ if (_ptr != 0) _ptr->_remove_ref (); } catch (...)
{
}
}
---------------- cut here ----------------
Event better would be to add some throw spec to _remove_ref()
and _add_ref(). The spec is, as far as I can tell, silent in this
respect, thus those operations can throw anything. This is
unfortunate because it makes it harder to write exception-safe code,
both for application developers and ORB implementors alike.
see below
The third bullet of 1.17.9 states that a POA skeleton class is generated
for valuetypes that support interfaces, but is silent about whether a
_tie template is also generated.
Proposal:
Add the following to the end of the third bullet in 1.17.9:
"No tie skeleton class is generated for the valuetype because the tie
for the inherited class can be used instead."
duplicate of issue 3328 close issue
The definition for Exception in the current spec is:
// C++
class Exception
;
Why aren't _rep_id() and _name() pure virtual?
rejected
The current requirement that the default implementations of _add_ref
and _remove_ref in ServantBase do nothing creates several problems:
1. The text in the C++ mapping that states that _remove_ref
must be called on a servant means nothing unless the ref
counting mix-in was used by the servant author.
2. The intended semantics of _var types as "smart pointers"
is upheld only if the servant author goes to the extra
step of using the ref counting mix-in.
3. In many places the C++ mapping explicitly or implicitly
states that _var types will recover memory for the application
developer:
1.3.1:
Client code frequently will use the object reference
variable type (A_var) because a variable will
automatically release its object reference when it is
deallocated or when assigned a new object reference.
1.3.6:
When a _var is passed as an out parameter, any
previous value it refers to must be implicitly
released.
In addition, there are many places in the C++ mapping where
the specification of _var types for arrays, structs, strings,
sequences, type Any, type codes, value types, value boxes,
value factories, etc. guarantees that the memory will be
reclaimed when the _var goes out of scope. This makes it
easy for users to believe that all _var types will release
storage for the objects that point to.
Benefits of Proposed Resolution:
Users can depend on ORB's to manage servant memory by default
rather than by exception.
Specification text that promises or implies automatic memory
reclamation need not change.
Existing user code will still compile.
Resolution:
Revised Text:
Replace the text in section 1.36.1 beginning with the sentence:
Servant instances may implement reference counting to prevent
themselves from being destroyed while the application is
still using them.
and section 1.36.2 in its entirety with:
Servant instances may implement reference counting to prevent
themselves from being destroyed while the application is still
using them. Servant reference counting is performed using the
_add_ref and _remove_ref functions declared in ServantBase. The
default implementations of _add_ref and _remove_ref supplied by
ServantBase provide true reference counting. An instance of a
servant class derived from ServantBase initially has a reference
count of one. Invoking _add_ref on the servant instance
increases its reference count by one. Invoking _remove_ref on
the servant instance decreases its reference count by one; if the
resulting reference count equals zero, _remove_ref invokes delete
on its this pointer in order to destroy the servant. For ORBs
that operate in multi-threaded environments, the implementations
of _add_ref and _remove_ref that the ServantBase class provides
shall be thread-safe.
ServantBase supports copy construction and the default assignment
operation. Copy construction always sets the reference count of
the new servant instance to one. The default assignment
implementation merely returns *this and does not affect the
reference count.
For servants that require that servants are not reference
counted, these functions are virtual and thus may be overridden
by derived servant classes. A default mix-in class is also
provided to remove the reference counting in the PortableServer
namespace; please see Section 1.36.2, "Servant No Reference
Counting Mix-In," on page 1-??? for more details. Details
concerning POA and application responsibilities with respect to
reference counting can be found in Section 1.36.4, "Servant
Memory Management Considerations," on page 1-???.
Note that for applications that depended on the the
RefCountServantBase provided in previous revisions of this
specification ORBs must provide a default implementation of this
mix-in class in the PortableServer namespace that essentially
does nothing:
// C++
namespace PortableServer
{
class RefCountServantBase : public virtual ServantBase
;
}
1.36.2 Servant No Reference Counting Mix-In
The PortableServer namespace also provides a standard servant
mix-in class to remove the reference counting:
// C++
namespace PortableServer
{
class NoRefCountServantBase : public virtual ServantBase
{
public:
~NoRefCountServantBase();
virtual void _add_ref() {}
virtual void _remove_ref() {}
protected:
NoRefCountServantBase() {}
NoRefCountServantBase(const NoRefCountServantBase&) {}
NoRefCountServantBase& operator=(const NoRefCountServantBase&);
private:
// ...other implementation details...
};
}
The NoRefCountServantBase mix-in class overrides the inherited
_add_ref and _remove_ref functions it inherits from ServantBase,
in order to override and remove the default reference counting in
ServantBase.
see below
CORBA::Fixed should have a to_string() member function to allow an
explicit conversion to a string. Otherwise the only way to get a string
version of the information in a fixed is via a string stream, which can
be awkward.
namespace CORBA {
class Fixed
;
}
The caller of Fixed::to_string() must deallocate the return value by
calling CORBA::string_free or assigning it to a String_var.
No Data Available
Why is it that String_var contains the following?
operator char *();
The mapping never passes strings as a char *. The only parameter
passing signatures are const char * for in params, char * & for inout params,
and String_out for out params.
It seems that this operator is redundant?
The only reason I can think of for it having been added are sloppy signatures
(such as old implementations of strcpy or some such, which sometimes used
char * instead of const char *). However, wouldn't it be better to remove
operator char *() from String_var and force a cast for such broken function
signatures?
Remove operator char*() from class String_var.
Page 1-153, section 1.41.2:
String_var has:
operator char*();
operator const char*() const;
What is missing here is:
operator char*&();
Without that, a String_var cannot be passed as an inout param.
Add operator char*&() to class String_var.
Currently there is Any extraction with widening to Object, and
AbstractBase.
It seems useful to also have one that widens to ValueBase.
duplicate of issue 3092...closed
page 1-23 says:
The T* constructor creates a T_var that, when destroyed, will delete
the storage pointed to by the T* parameter. The parameter to this
constructor should never be a null pointer. Compliant implementations
are not required to detect null pointers passed to this constructor.
So, I can't explicitly initialize with null:
T_var tv = 0;
This seems strange, seeing that the default constructor does initialize
with null.
Also, the spec doesn't say anything about assignment. Is the following legal?
T_var tv = ...;
tv = 0;
I don't understand the restriction. What's the motivation for
disallowing this? Especially for String_var, the prohibition against null
null seems rather draconian. For example, I may be using a temporary local
String_var for exception safety and then, at some point, decide to
assign null to it to force an early deallocation of the string instead
of having to create a separate scope to achieve this.
At any rate, we should clarify so that, whatever the eventual decision is,
the text for the assignment operator agrees with the text for the constructor.
see below
Question: do I need to deallocate the string returned by Exception::_name()
and Exception::_rep_id() or not? The spec doesn't say...
Given that these are PIDL, and that the return value is const char *
(rather than non-const char *), I'd say that I shouldn't have to deallocate
the return value. But I think we should clarify this in the spec.
Also, the Exception class in section 1.41.7 doesn't show the _name and
_rep_id members, so we need to add them there.
Further, Exception doesn't show up in section 1.23 (Mapping of Pseudo
Objects). I suspect that we need to add Exception there as well and
mention the exception to the memory management rules? Another interesting
thing is that, if Exception is a pseudo object, then UserException and
everything derived from it is also a pseudo object. But, user exceptions
can't be pseudo objects. But, if they are not pseudo-objects, we can't
really make special-purpose memory managment rules. Sigh... 
see below
Section 1.17.9 states that valuetypes that support a non-abstract
interface have a POA skeleton class generated for them. Is a tie
template class also supposed to be generated?
see below
The CORBA 2.3.1 specification does not cover the case of code generation
for the OBV_ class constructor for a valuetype that inherits from
another concrete valuetype:
// IDL
valuetype A
;
valuetype B : A
{ octet o2; };
The generated OBV constructor for class B needs to take both o1 and o2
arguments, so it should look like this:
// C++
class OBV_B
;
Proposal:
Change the second paragraph of 1.17.2 to read:
"For the same reasons, a C++ OBV_ class defines a protected default
constructor, a protected constructor that takes an initializer for each
valuetype data member, and a protected default constructor. The
parameters of the constructor that takes an initializer for each member
appear in the same order as the data members appear, top to bottom, in
the IDL valuetype definition, regardless of whether they are public or
private. If the valuetype inherits from a concrete valuetype, then
parameters for the data members of the inherited valuetype appear
first. All parameters for the member initializer constructor follow the
C++ mapping parameter passing rules for in arguments of their respective
types."
see below
Section 1.17.10.3 states that type specific valuetype factories are
generated with a public destructor. This conflicts with the reference
counting requirement for factories, since it makes it easier for
application code to delete a factory that still has outstanding
references.
Proposal:
Change the text in 1.17.10.3 to make destructors for type specific
valuetype factories protected rather than public.
No Data Available
2. Valuetypes should have _var typedef inside the class to aid template
programming just like objects, structs and unions.
see below
The last C++ RTF made changes that identify specific inheritence
strategies must be used for generating code for interfaces that inherit
from abstract interfaces. The text in 1.40.3 was not updated to reflect
this, and still suggests that other strategies are possible, when they
are no longer allowed.
see below
The CORBA 2.3 C++ mapping for valueboxes (1.17.7.2) does not specify the
behavior of the constructors, assignment operator and _value modifier
method with respect to the object reference argument. These methods
clearly need to call _duplicate on their argument, since the valuebox
must manage its own memory.
Proposal:
Add the following paragraph just before the example in 1.17.7.2:
Value box classes for object reference maintain a private managed copy
of the object reference. The constructor, assignment operator and
_value modifier method for these classes call _duplicate on the object
reference argument, and the destructor calls CORBA::release on the boxed
reference.
see below
The CORBA 2.3 C++ mapping makes no mention of _out types for
valuetypes. Clearly this is needed and should be mentioned.
see below
Section 1.17.10.2, the definition of operator= for ValueFactoryBase_var
has "ValueFactoryBaseBase_var".
fixed editorially...issue closed
Many ORBs provide ostream insertion for exceptions as an extension to C++
mapping. Typically, applications are required to use them (there is not really
a usable alternative) to write code in the following style:
try
{ // do some operations }catch (CORBA::Exception & ex)
{ cerr << "some operation failed: " << ex << endl; }This breaks portability as not all ORBs provide the functionality in the same
way. Therefore ostream insertion should be part of the standard.
closed issue, duplicate of 266
the spec currently is extremely vague about how _var types for fixed-length
underlying types are supposed to work. The only words are:
The T_var types are also produced for fixed-length structured
types for reasons of consistency. These types have the same
semantics as T_var types for variable-length types. This allows
applications to be coded in terms of T_var types regardless of
whether the underlying types are fixed- or variable-length.
This has long been a source of confusion to me. In particular, it doesn't
answer questions such as
duplicate of issdue 1521...close issue
Summary: For string sequences, new string elements, that are created when the
sequence length is increased, should be initialized to the empty string.
I therefore raise this herewith as an official issue.
I also don"t think it makes sense to vote on issue 2234 before we
decided on the issue above. As I already pointed out, I raised issue
2234 in the believe that the spec already says that new string sequence
elements are initialized as empty string. But this assumption was wrong.
closed and fixed
Summary: The first bullet point at the bottom of page 20-61 is incorrect. It
states that Boolean, Char, and Octet can be extracted using >>=. However,
on page 20-66, the mapping requires a compile-time error for attempts
to extract these types with >>=.
Proposal:
Delete Boolean, Char, and Octet from teh list of types at
the bottom of page 20-61.
No Data Available
Summary: The following MIGHT be considered an issue for CosLifeCycle and/or
CosReference.
The inheritance of CosReference::Relationship and
CosCompoundLifeCycle::Relationship by CosLifeCycleReference::Relationship
creates a "Diamond of Death" inheritance structure, in which
CosRelationships::Relationship is inherited by two distinct paths:
CosRelationships::Relationship
/ \
/ \
CosReference::Relationship CosCompoundLifeCycle::Relationship
\ /
\ /
CosLifeCycleReference::Relationship
No Data Available
Summary: We currently have the _ptr_type and _var_type definitions for interface
classes. These are useful for template functions that need to deal with
the proxy type as well as the _ptr and/or _var references.
In a similar vein, we could add a typedef to the tie template for the
tied object class:
template<class T>
class POA_A_tie : public POA_A
;
No Data Available
Summary: It would be nice to have a trait in the Tie classes of the class that the requests are being forwarded to. Something like this:
template <class T>
class POA_Foo_tie : public POA_Foo
;
No Data Available
Summary: Here is a list of all the POA-related operations that deal with the Servant
type, and how I believe they need to act with respect to reference
counting. Because there aren"t that many operations in this list, I believe
that by spelling them out in detail rather than trying to capture their
behavior in general rules accomplishes two things:
1) We make it crystal clear to POA implementors and application developers
how each operation handles reference counting for the Servants it deals
with, and how the POA interacts with those servants.
2) We make it clear to future maintainers of the C++ mapping for the
PortableServer module that any new operations that deal with servants must
have their servant reference counting semantics explicitly specified.
Again, because there are so few operations to cover, explicitly specifying
rules for each one is simple and precise.
No Data Available
Summary: page 20-74 of orbos/98-01-11 shows the tables for the parameter passing
rules. There are six notes on page 20-76 that are meant to be referenced
by the tables. However, those references are no longer correct.
For example, the array parameter passing rules in table 19-2 (should be
table 20-2) have the index 2, but note 2 actually refers to the rules
for passing references.
Notes 3 to 6 are no longer referenced by the table, but should be.
No Data Available
Summary: There is a problem with the C++ mapping which requires excessive memory copying in order to be exception safe while constructing a return value.
This issue was fixed by Portability Submission
The fixed mapping uses operator"" and _fixed as user defined literal. This doesn't work with a C++ template, only with a class, so the usage of user defined literals should be removed
The usage of operator”” and _fixed will be removed from the specification
Everywhere where a specialization of std::swap is mentioned also mention the need for a namespace level swap
Accepting this issue as proposed
1. Should a session component have a way to save and restore its private state?
Problem: The current component specification provides no way for the component programmer to explicitly save and restore its private state for session components.
closed issue, no change
This section indicates that the Language Mappings are to be provided as errata. I have searched high and low in the OMG web site to find these mappings and have not found a single bit of info on them. I need these mappings to accurately design and implement the extended CCM features.
close no change
In the first versions of the CCM specification terms such as
ComponentBAse, ComponentHome, ... have been used. More recently these
terms have been changed to CCMObject, CCMHome... Shouldn't all the
interfaces of the ccm module be changed this way in order to be
homogeneous in their naming?
Why is there CCMContext (with CCM prefix) and SessionContext without
CCM prefix ?
Thus SessionComponent, EnterpriseComponent, SessionContext, ... would
become CCMSessionObject, CCMEnterpriseObject, CCMSessionContext ...
close, no change
2. Document OMG ptc/99-10-04 p.615-87. In the last paragraph of the
illustrative example, it is said that: "The implementations of
operations for navigation, executor activation, object reference
creation and management, and other mechanical functions are either
generated or supplied by the container."
Don't you think this is dangerous in a multi vendor context? Let say
a component implementation rely on the container to provide these
operations. What will happend if this component is deployed in a
container which considers that component implementations include
the generated code providing these operations? (Same feeling as in
remark 2.)
close issue, no change
Problem: Can home finders be federated?
No, HomeFinder cannot be federated. Clients can use the Naming Service instead, which is federated.
Problem: The current specification does not provide an interface for registering homes that can be used outside of the container. Should it?
close, no change
Two small typos in sectin 6.25.3:
aks CORBA::weak_servant_reference<>
to
aka CORBA::weak_servant_reference<>
Than
Foo some_function()
to
Foo::some_function()
Change text as proposed
As done for the interfaces already, we propose to remove _downcase/_narrow for abstract/valuetype and only support IDL::traits<>::narrow. In the spec this has to be updated in text and code.
Accepting this issue as proposed
Currently the std::array doesn't have an efficient move constructor, passing an array by value to the constructor of a valuetype/struct isn't efficient. Instead of adding an exception to the spec we propose to relax the spec so that it just mentions that the constructor must be there, but not that arguments have to be passed by value, that is up to the implementor to decide
We remove the restriction that the arguments have to be passed by value to the
constructor of a structured type. This is a way implementations can deliver optimizations
if needed. This change will not impact any user code in terms of portability
The mapping defines the mapping of IDL struct/union to a final class. The work "final" should be removed from the IDL to C++11 language mapping because it will prevent the implementation of the DDSXTypes Type Extensibility.
Accepting this issue as proposed
The following typo error exists in section 6.21:
Following text in spec
... TypeCode reference constants, <type> refer to the local name of the type ...
should be
... TypeCode reference constants, <type> refers to the local name of the type ...
Refs #2877
The V1.0 spec doesn’t have this typo, so closing this with no change
Disposition: Closed
The current mapping for struct violates the RFP requirements that mandated compatibility with the DDS-PSM-Cxx. Areas of incompatibilities include the use of the C++11 array type and the use of move operators.
The revised submission explicitly mentioned that this requirement was not met because
this is a C+11 language mappping, not focusing on C+03 which is the focus of the
DDS-PSM-Cxx. Also in the mean time the DDS-PSM-Cxx has adopted the same
mapping for arrays/enums and mentions move semantics when C++11 support is
available. Given the fact this is a C++11 language mapping this issue has been closed
without a change.
Disposition: Closed, no change
The specification defines IDL::traits<A>::factory_type as C++ trait for getting the base C++ class for the factory. It does lack a trait for passing a reference for a certain factory around.
To be added:
For a valuetype A, a strong reference to its valuetype factory is known as IDL::traits<A>::factory_ref_type. The weak object reference to its valuetype factory is known as IDL::traits<A>::weak_factory_ref_type.
Refs #2727
Accepting this addition as proposed
Addressee: IDL to C++11 1.1 RTF <idl2cpp11-rtf@omg.org>
Nature: Enhancement
Summary: Early detection of bound violation on bounded types
In the IDL to C++11 Mapping v1.0 (formal/13-02-04), the sections
6.9, 6.10, and 6.11 describe the mapping for string, wstring, and
sequence types, respectively. These sections also address the bounded
variant of those types:
" Implementations must (at run time) detect attempts to pass a
[string|wstring|sequence] value that exceeds the bound as a parameter
across an interface. It must raise a BAD_PARAM system exception to
signal the error. "
In practice, the point at which such a value is passed into an interface
method may be far away from the assignment causing a bound violation,
which makes the error source hard to find.
I propose doing a bound check not only at interface methods but also
at the setter functions for struct, union, and valuetype members.
The section quoted above could thus be extended as follows:
" Implementations must (at run time) detect attempts to pass a
[string|wstring|sequence] value that exceeds the bound as a parameter
across an interface, or passed to a setter method of a struct, union,
or valuetype. It must raise a BAD_PARAM system exception to
signal the error. "
Furthermore, the mapping standard does not define the bound check
behavior for arrays and sequences of bounded types.
IMHO the mapping standard should make explicit that the bound check
shall be performed on each bounded-type element of an array or sequence.
Example:
// IDL
typedef string<12> string12_t;
typedef string12_t string_arr_t[2][3];
typedef sequence<string12_t, 4> string_seq_t;
struct struct_t
The sarr() and sseq() setter methods generated for struct_t should
iterate over their input parameter and perform the bound check on
each element. Similar checks should happen in the explicit constructor
which accepts values for each struct member.
Adding the bounds check to the place where the bounded type is used leads to
inconsistent behavior for users. After discussion we decided to map bounded types
(string/wstring/sequence) to a distinct type and that this type could do a bounds check.
The exact type doesn’t need to be standardized because bound types can only be used
through a typedef in IDL and never are used directly by the programmer. Because the
standard containers don’t have the concept of bounds enforcing a bound will be very
hard to accomplish on all places.
The wording in 6.29 says
"For each IDL type (T) of type: [..] an ostream inserter with the following signature will be provided:
// C++
std::ostream& operator<<(std::ostream &, T);
For all other types an ostream inserter with the following signature will be provided:
// C++
std::ostream& operator<<(std::ostream &, const T&);"
1) This wording is not clear in which namespace the operator<< overload shall be provided. It could be within the global namespace or within the namespace of type T.
The prototype implementation that I have seen provides these operators in the global namespace which makes them behave irregular:
The reason is that overloaded operators such as these IO inserters are found by argument-dependent name-lookup. The lookup will consider all declarations that are found at the point of usage and will look in the associated namespaces of the operands to find them. Consider the following example:
#include <iostream>
#include <vector>
#include <iterator>
namespace n {
struct A {};
}
std::ostream& operator<<(std::ostream& os, n::A)
}
int main()
{ std::vector<n::A> v; std::copy(v.begin(), v.end(), std::ostream_iterator<n::A>(std::cout)); }This works and lets the ostream operator<< of A::n behave normally.
This example was intended to demonstrate that the provided operator<< overloads should be provided in the same namespace as the declared mapped types from the IDL (that is within the IDL module). The wording in 6.29 should be clarified in that regard.
2) The second part of above wording,
"For all other types an ostream inserter with the following signature will be provided:
// C++
std::ostream& operator<<(std::ostream &, const T&);"
can be read to be applicable for the arithmetic IDL types (bool, short, wchar_t, char, double, uint32_t, ...) or typedefs thereof, but that surely cannot be intended, because that would result in a compiler ambiguity when user code would include such a mapping header and would attempt to print such an arithmetic type on any std::ostream, e.g.
#include <iostream>
#include "some_idl.h"
int main()
{ std::cout << 12; // Error, ambiguity }The wording in 6.29 should make clear that no operator<< overloads shall be provided for the basic data types or for typedefs thereof.
We had a detailed looked at the argument dependent lookup and what would technically
be feasible. We also had users that wanted to define their own ostream operators and
our spec defined methods were conflicting with that approach. Given that this feature
was mostly focused on debugging systems, we decided to remove this section
completely from the specification
The description for Any lacks the support for implicit widening as it was available with the C++ mapping. Proposal is to add implicit widening to section 6.16.3. The following text is proposed to be added:
Any object reference, valuetype reference, or abstract references has to extractable as its base reference type from an Any.
Also in the last sentence of 6.13, any as bold should be Any with a capital A
Refs #2873
Accepting this addition as proposed with the remark that 6.13 should be 6.17.3 and it
talks about the Any C++ class, not the any IDL type.
With the new IDL2C+11 mapping we can't create object references with new, we have to use the CORBA::make_reference<> factory method. In a servant we can use _this to get a reference to itself, but that is not available for local objects. With the old C+ binding people could just use the C++ this to get a _ptr to a local object, but that is not possible with the C++11 binding in general.
Proposal is to add to 6.24:
In order to get an object reference referring to an already created local object the _this() method must be used.
In the code part add as method
class LocalIF
{ protected: IDL::traits<LocalIF>::ref_type _this (); };
Refs #2804
Accepting this addition as proposed
Section 6.17.2 is titled "Constructors, Assignment Operators, and Destructors" but does not say anything about assignment operators albeit the title promises to do so.
The following examples seems to indicate that both assignment operators are supposed to be deleted. This should be spelled out.
It also seems as if the maiing for interfaces as of 6.6 is intended to create class types with deleted copy/move assignment operators. This should also be made more clear.
Accepting this issue as proposed
Section 6.5 (Table 6.1) loosely describes that the OMG IDL integer types are mapped to "a basic C++11 type" denoted by
int16_t int32_t int64_t uint16_t uint32_t uint64_t uint8_t
It doesn't really say, what these typedefs are supposed to be. Furthermore 6.5 (Table 6.2) describes the names
int16_t int32_t int64_t uint16_t uint32_t uint64_t uint8_t
as "keywords from the C++11 specification (ISO/IEC 14882:011)".
Surely there are no such keywords in C+11 (nor in C11 or C99) and never had been. What C+11 inherits from the C99 library specification are the typedefs
std::int16_t std::int32_t std::int64_t std::uint16_t std::uint32_t
std::uint64_t std::uint8_t
from header <cstdint>, but those are not keywords and they are library components that belong to namespace std. I think that the specification of the basic integer type mapping (6.5) intends to refer to these typedefs from <cstdint>, but this should be made clear in 6.5.
Also, section 6.30 should not declare them as C+11 keywords, even though these names need to be protected by a cxx prefix as described by 6.2. Presumably a better name is needed (e.g. "protected C+11 names" or some such)
Accepting this issue as proposed
Given the specification of the class template Fixed provides
operator int64_t () const;
operator long double() const;
and
bool operator!() const;
This allows to test some Fixed instantiation within a boolean context as in a useful way as follows:
typedef IDL::Fixed<5,2> F;
F f = ...;
if (!f)
will cause an ambiguity error between the two conversion functions to int64_t and long double. User code is required to write the obfuscated form
if (!!f)
{ ... }to realize the same thing. This is unfortunate and there is a simple means to solve this problem: The specification should add
explicit operator bool() const;
to the class template synopsis with the same semantics as negating operator!
Accepting this issue as proposed. Also during the discussion it was proposed to add a
namespace level to_string
The example in the middle of the page starts with:
// C++
S s =
;
or
// C++
S s = S
;
Accepting this issue as proposed
CORBA::Exception should not use std::string type for name and repo_id for 2 reasons:
1. C++ standard conformance; member types like std::string are discouraged because their constructors may throw exceptions where std::exception and derivatives are expected not to throw exceptions themselves
2. (minor) performance; using std::string these member values are unnecessarily copied while they immutable constant strings only ever read, never mutated
Changing the members to const char* values makes CORBA::Exception and the CORBA::SystemException classes optimal and c++ standard conformant.
This will not be the case for CORBA::UserException derivatives as these may have IDL defined attributes having IDL defined types which may definitely throw exceptions. However the ORB should be expected to handle situations where creating user exceptions unexpectedly throws another exception.
Refs #2958
Update exception as proposed. During the discussion also it was proposed to define
what() as noexcept which also has been done
Given interface T the specification defines IDL::traits<T>::narrow as a way to narrow to T. As convenience it also defined T::_narrow. The issue is that T::_narrow is implicitly linked to IDL::traits<T>::narrow and can cause confusion and possible misuse when other traits are added for more specific traits. We propose to remove T::_narrow from the specification completely, users must just use IDL::traits<T>::narrow
Accepting this issue as proposed
The specification defines IDL::traits<> as type trait, but uses it only for reference types.
We propose to extend IDL::traits<> as generic type trait for IDL2C++11. This type trait delivers traits with information coming from IDL.
For example object reference traits it can also deliver local and abstract as traits, which are booleans that indicate whether the IDL type was local or abstract.
For sequence we can add traits indicating the type of the element and in case of bounded sequences the bound.
The proposal is to add a new paragraph which describes the IDL type traits that are all available as part of IDL::traits<> for a specific IDL type.
Ref #2802
Extending the IDL::traits<> with more types for template meta programming will be useful
for the users that would like to program C++11 templates using the IDL defined types.
Therefor a new set of type traits will be added to the specification.
The specification uses in some examples like in 6.13.1 the construct "(void)" for a method with no arguments. This is old style, it should use "()"
Accepting this issue as proposed
2.1 refers to ISO/IEC 14822:2011 (which should be 14882:2011)
6.30 instead refers to ISO/IEC 14882:011 (again should be 14882:2011)
the table in 6.30 contains typos (alinas, alineof, constrexpr), names
that aren't keywords (int32_t, ...) and misses some keywords
(noexcept, char16_t, char32_t).
Accepting this issue as proposed
The specification uses IDL::traits<T> for everything related to interface T, but for a local interface we just use T as base class. Proposal is to use IDL::traits<T>::base_type as base type trait for the local object implementation. This makes everything related to interfaces available through IDL::traits<T>
Accepting this issue as proposed
In section 6.25.6, in the line:
This guarantees that the POA skeleton class inherits only one version of each operation, and also allows optional
inheritance of implementations. In this example, the implementation of interface B reuses the implementation of interface
A:
The font of A should also be IDL type just as B
Accepting this addition as proposed
I have a number of issues with the Software Package Descriptor section of
the CCM specification (Component Spec - Volume I, orbos/99-07-01.) I have
not found answers to issues raised below in either the components-ftf
archive, or the issues list.
ISSUE - The softpkg descriptor example uses an "id" attribute, which isn't
defined in the softpkg.dtd.
>From page 10-305, 10.2.1 A softpkg Descriptor Example, CORBA Components -
orbos/99-07-01:
<idl id="IDL:M1/Bank:1.0" ><link href="ftp://x/y/Bank.idl"/></idl>
According to the softpkg.dtd, (page B-435, B.1 softpkg.dtd, CORBA Components
<!ELEMENT idl
( link
| fileinarchive |
| repository ) > |
The same definition can also found in section 10.2.2.14, The idl Element (,
page 10-311, CORBA Components - orbos/99-07-01.) There are no attributes
defined for the idl element.
see below
In chapter 69.9.1.2 Deployment Scenario on page 329 of ptc/99-10-04.pdf the
operation get_implementation() is refered as if it belongs to the
ComponentInstallation interface (called only "Installation"), but the
specification of that interface lacks it.
Duplicate, close
Dealing with the following IDL3 definition, a problem arises when
generating the IDL2 definitions (complete IDL2 mapping is enclosed at
the end of this mail).
module example {
valuetype AnEvent : Components::EventBase
;
component Producer
{ publishes AnEvent output; };
component Consumer
{ consumes AnEvent input; };
};
According to the chapter 5 of the CCM specification, the publishes
definition of the Producer component is mapped to the following
definition (excerpt).
interface Producer : Components::CCMObject
{ Components::Cookie subscribe_output(in ::example::ProducerEventConsumers::AnEventConsumer consumer) raises (Components::ExceededConnectionLimit); };
In the mean time, the consumes definition of the Consumer component is
mapped to the following definition.
interface Consumer : Components::CCMObject {
::example::ConsumerEventConsumers::AnEventConsumer
get_consumer_input();
};
We can see that two versions of the "AnEventConsumer" interface have
been defined in two distincts modules. Thus the following Java
lines are not correct:
example.Producer p = ...;
example.Consumer c = ...;
p.subscribe_output(c.get_consumer_input());
The Java compiler will refuse to compile the last one, producing an
error like "BadTypeCoerce". However, in the IDL3 definitions, both
components have been defined in order to be used together. (sic!)
Thus, we think that the mapping for a Consumer should not be based on
the component definitions, but on the event definition itself. It
would then avoid multiple (incompatible) definitions of the consumers.
This mapping could be defined in two distinct ways.
see below
Looking a the <Assembly> interface, a question arises. When providing
the assembly descriptor location, a logic description of the
application to deploy is provided. But, how are set the pysical hosts
to be used for the deployemnt of the logic configuration? No hooks is
provided to the deployment tool (as there are no interfaces for the
tool) in order to provide these information, and no operation is
available on the assembly interface to do so. Is there an extension of
the <Assembly> interface in order to contain this information?
Otherwise, how could the application be deployed?
Thinking about what should be provided, it is necessary to assign a
logical name contained in the assembly descriptor to a physical host
name. Maybe an extension to the assembly descriptor filled at
deployment time is the solution? The second possible choice crossing
my mind is an IDL structure (in fact sequence of structure) that could
be provided to the assembly object.
rejected
What about <i>valuetype factories</i>?
<p>In the context of a component dealing with events, the aspect of
<i>valuetype</i> factories has not been really mentionned in the spec,
especially in the deploiement process.
If I am right, dealing with <i>valuetypes</i> in a program means to
instantiate and to register a factory for this <i>valuetype</i> to the
ORB. In the context of the CCM, a component and its home is installed
into a generic container which may not know the <i>valuetype</i>.
Thus, the <i>valuetype factory</i> may have to be installed at
deployment time. </p>
<p> According
to the similarity in the <i>home</i> and <i>valuetype factory</i>
concepts, it may be a good solution to add an entry in the CORBA
Component Descriptor OSD file to define the <i>valuetype factory</i>
(which would have to be included in the component package) required by
the component as well as to define a standard name scheme for their
entry points. Here is an draft example of what it could look
like. Relationships / dependencies between components and <i>valuetype
factories</i> also have to be introduced.</p>
<!--
<softpkg>
...
<implementation id="...">
... all the environment stuff ...
<descriptor type="Event Factory">
<fileinarchive>...</fileinarchive>
</descriptor>
<code type="DLL">
<fileinarchive name="bank.dll" />
<entrypoint>createEventFactory</entrypoint>
</code>
</implementation>
...
</softpkg>
-->
<p><tt><softpkg>
<br> ...
<br> <implementation id="...">
<br> ... all the environment stuff ...
<br> <descriptor type="Event Factory">
<br> <fileinarchive>...</fileinarchive>
<br> </descriptor>
<br> <code type="DLL">
<br> <fileinarchive name="bank.dll" />
<br> <entrypoint>createEventFactory</entrypoint>
<br> </code>
<br> </implementation>
<br> ...
<br></softpkg></tt></p>
<p>The second solution could be to include the code for <i>valuetype
factory</i> creation in the <i>home</i> implementation, which mean
less specification: "The home has to install any valuetype factory
required by the component." would be enough. However, this second
approach may not be as much portable as the first one (as long as a
<i>home</i> may be portable between containers, which IMHO should be
possible).</p>
see below
he following sub-issues need to be addressed to make sure that CCM/EJB
bridge implementations are interoperable. In particular, these sub-issues
have in common that the current definition of the bridge relies on the
Java-to-IDL mapping, which in certain cases does not match the requirements
of the EJB-to-CCM mapping.
Sub-issue: METHOD NAMES IN STANDARD INTERFACES
The names for some methods defined on standard interfaces, for example
<home-name>Implicit.find_by_primary_key or <home-name>Implicit.create,
differ from the names that their EJB counterparts get mapped to under
Java-to-IDL (in the example these would be
<home-name>.findByPrimaryKey and create__keytype, respectively). When
this happens, the translation from one form of the name to the other
can happen at either the client or the server side of the bridge. FOR
INTEROPERABILITY, it is necessary to eliminate this ambiguity. Choices
for doing this include requiring the client stub to always do the
translation or requiring the server skeleton to take into account both
name forms.
The actual problem we are getting hit by here is overloaded names. Methods
like remove and create in EJBHome and user-defined EJB homes can only be
mapped to remove_XXX and create_XXX under Java-to-IDL, yet the
definitions of the corresponding methods in <home-name>Implicit are remove
and create, respectively. I can understand that these implicit home names
were defined as such because <home-name>Implicit is a standard interface
(although the fact that its name is prefixed by <home-name> is a bit
troubling) and, if for no other reason, because the XXX in create_XXX
cannot be known in general. So, if we stick to the standard names, there is
a mismatch. Notice however that I said that the mapping is done under
Java-to-IDL. Perhaps I should not say that but the CCM spec is not clear
about this and in fact it states that the create methods in an EJB home are
mapped to factory names under Java-to-IDL. So we may actually be talking
about two different issues: (1) use different mapping rules for create with
no primary key, in which case we need to ammend the spec to this effect;
(2) perform a translation, in which case we have an interoperability issue.
Sub-issue: HANDLING STANDARD EXCEPTIONS
Standard exceptions thrown by EJB methods, such as
DuplicateKeyException, have a mapping specification to IDL (under the
current Java-to-IDL specification) that does not match the exceptions
that they map to under the CCM spec (in the example this would be
DuplicateKeyValue). This requires that the bridge perform a run-time
translation of exceptions from the Java-to-IDL mapping to the CCM
mapping at either the client stub or the server skeleton. FOR
INTEROPERABILITY, it is further necessary that the location of the
translation be fixed. Early prototype implementation suggests that it
is more advantageous for the client stub to perform the translation
since otherwise the server skeleton would need to know what kind of
client it is talking to: a CCM client or an EJB client. A larger issue
that this falls under is the reconciliation of the Java-to-IDL mapping
with the EJB-to-CCM mapping. If and when the larger issue is resolved,
this issue would largely disappear.
This also falls under the Java-to-IDL mismatch. Our choices seem to be: (1)
define the standard exceptions, e.g. Components::DuplicateKeyValue, as if
they had been mapped from Java under Java-to-IDL, (2) map the exceptions
from Java under rules different from those on Java-to-IDL; (3) perform a
translation. Choice (1) may be too intrusive but it could be rationalized
with a "integration with EJB" argument. Choices (2) and (3) are similar to
the above.
Sub-issue: PASSING A PRIMARY KEY PARAMETER
A number of methods defined by standard interfaces, such as remove
defined by EJBHome, include in their signature a primary key value and
define its type to be java.lang.Object, which under RMI-IIOP is mapped
to CORBA::Any. Since the primary key is actually an object passed by
value and thus mapped to an IDL value type, a run-time translation
must be performed from the value type to Any and viceversa whenever a
method that includes a primary key is called. FOR INTEROPERABILITY, it
is necessary that the location of this translation be fixed. Choices
for doing this include requiring the client stub to always do the
translation or requiring the server skeleton to take into account both
a value or an Any that could possibly be coming from any given
client. In additon, if a primary key is returned it may be more
advantageous for the client to perform this translation, since the
server skeleton may not know what form the client is expecting.
Here again the problem is that, under Java-to-IDL, java.lang.Object gets
mapped to ::java::lang::Object (not CORBA::Any actually, as per the actual
Java-to-IDL I am looking at) for methods like EJBHome.remove, whereas the
key is expected to be passed as a value type. So the choices seem to be:
(1) use rules other than those in Java-to-IDL for the mapping or (2)
perform a translation.
see below
What exactly is meant in chapter 69.7.2.3 by component archive file? It is
not defined anywhere. Is it a software package descriptor or a software
package? At least it is not a CORBA component descriptor as shown in the
example in chapter 69.7.1. The text there is like:
<componentfile id="A">
<fileinarchive name="ca.ccd"/>
...
Is the sufix ccd right?
see below
Document orbos/99-08-13, line 9 and further, contradicts with
orbos/99-07-01,
Chapter 4.4. The production rules for typePrefix and typeId contain a
";",
where file orbos/99-08-13 omits them.
Document orbos/99-08-13, lines 1-6, contradicts with orbos/99-07-01,
Chapter 4.2. The production rules for import contain a ";",
where file orbos/99-08-13 omits them.
see below
The mapping between EEJB metadata and the IR is missing in the
current specification .Resolution: Define the mapping
see above, rejected
Moving existing interfaces from the CORBA module to a new IR module breaks
backward compatibility. Hence they should be moved back to the CORBA module. The
elements that are newly added can go into a new module, and interfaces
corresponding to the existing ones with the same names can be placed in the new
module, with these interfaces deriving from the existing corresponding
interfaces in the CORBA module, thus allowing all CORBA3 IR interfaces to be
accessed from a single module.
This also fixes a related problem regarding separation of the TypeCode stuff,
specifically TypeCode factory. It is broken in the current spec because certain
types used by the typecode factory were inadvertently moved to the IR module.
see below
In section 69.4.5.45, the "rights" element is mentioned, but the "rights
combinator" elemnt is not. Given a set of "rights" it is not possible to
determine how to cobine them without the "rights combinator" as specified in
CORBAsec. Suggest we add a "rights cobminator" element, consistent with the
definition of rights combinator in CORBAsec.
see below
ISSUE - What is the purpose of the "name" element as used in the
"dependency" element?
See section 10.2.2.7, The dependency Element (, page 10-308, 10.2.1 A
softpkg Descriptor Example, CORBA Components - orbos/99-07-01.) Section
10.2.2.20, The name Element, describes the name element as an optional
element of the "author" element, and is meant to identify the author. So
does the name element identify the author of the dependency, or is it used
to identify the dependency itself?
see below
When a component type is implemented, it inherits a specialized
interface for callback functions, for example SessionComponent. In
this context, why should home implementations be unspecialized? Using
a specific home type, deployment could be improved when performed in a
multi-actor context. As the cooperation between containers and homes
is unspecified, using multi-actors components seems unreachable. One
particular aspect is how the container <Context> interface si provided
to the component instance. Using a well defined specialized home
interface would solve this problem easily. Thus, avoiding the use of
wrappers for example which are another solution, but far more complex.
Such an interface should be defined for each component type category.
As an example the following interface could be a basis for session
component homes. (there must be other operations to add here, but I
have not foudn them yet.)
interface SessionCCMHome : CCMHome
{ // or CCMHomeKeyless void set_session_context ( in SessionContext sc ) ; };
rejected
7. Where is HomeExecutorBase interface defined? I only saw it used in
the packaging and deployment model. If it is a standard interface
which is returned (how could it be non standard), shouldn't it be
defined somewhere? (Same remark for ExecutorSegmentBase
interfaces. It may be defined in the last Components.idl, but I did
not find one more recent than orbos/99-08-13.)
See the resolution for issue 4574.
6. In example p.615-86, shouldn't myToonImpl extends ToonSessionImpl
(presented in the previous pages) instead of ToonImpl (which is not
defined)? The same classname is used in pages 96-98, but it seems
correct in this case.
see below
5. Even if it is only an example, p.615-85 ToonTownImpl implements
ExecutorSegmentBase, shouldn't it be HomeExecutorBase?
see below
4. Why does not CCMHome include the operation create_component() ? I
understand that a component created by a home with keys should not
offer this interface, however according to the exemple in the spec
Container operation install_home() returns a CCMHome, thus how
could a component be created in this context? Does it imply that
you know if the home is keyless or not, thus narrowing it before
use? Don't you find strange to have the remove operation but not a
default create in the CCMHome interface?
rejected
3. Why isn't the operation <string get_implementation(in string iuuid)>
defined in the interface ComponentInstallation while being used in
ptc/99-10-04 p.69-329 item 9? (Where Installation should be
replaced by ComponentInstallation don't you think?) Moreover, this
operation is required for an Assembly to find the location of a
component implementation in order to load it in a container.
see below
1) Some concepts from the CORBA metamodel (component, facet, receptacle,
event publishing/emission/consumption) are also in P/D metamodel but the
definitions from the CORBA metamodel are not directly reused.
Recommendation: Analyze where reuse is appropriate and adjust the P/D
metamodel accordingly.
2) The P/D metamodel has the notion of files (e.g. configuration property
files and some other files) where some metadata are stored. The hand-coded
DTDs treat these files as types in their own right, i.e. they conceptualize
them as files, and some of the other types point to the file types. This
is approach is mimicked in the metamodel. However, it might not make sense
in the metamodel because, in a repository context, you are referencing
other information in the repository and not necessarily a file. The way
the metamodel is now, when something references one of these files you lose
the metadata trail. The file metaclass itself does not have structural
features pointing to metaclasses that define the contents of the file. You
have to go elsewhere (i.e. to the property file Package) to get that
metadata and there is no reference to the property file Package.
Recommendation: It might make more sense for references to the file
metaclass to instead reference the top level element of the property file
Package so that you can "follow the metadata trail." If someone wants to
break out the properties metadata in a file, then the generated DTD should
allow that, i.e. the part that needs to go into a properties file should be
able to be self-contained without external references.
rejected, See issue 4575.
ISSUE - The description of the "implementation" element explains the
"variation" attribute, but the attribute is not part of the definition.
>From page 10-32, CORBA Components - orbos/99-07-01: "The variation attribute
is used to indicate a variation from a normal implementation." But the
definition of the implementation attribute list only lists the "id"
attribute. The variation attribute is not part of the definition as given in
softpkg.dtd either (, page B-419, B.1 softpkg.dtd, CORBA Components -
orbos/99-08-05.)
see below
In ptc/99-10-04, the production 104
<readonly_attr_declarator >::=
<simple_declarator> [ <raises_expr> ]
| <simple_declarator>
{ "," <simple_declarator> }* is ambiguous, since a sole <simple_declarator> could either denote the first alternative (with no <raises_expr>), or the second alternative (with the simple-declarator-list omitted). Even though this does not constitute a serious problem, it is also easy to fix: <readonly_attr_declarator >::= <simple_declarator> <raises_expr> | <simple_declarator> { "," <simple_declarator> } * |
see below
The draft component specification (ptc/99-10-04) explains that CIDL is
a superset of IDL. This is a derivation from the specification
voted-on in the PTC (orbos/99-07-01), which specified that CIDL is a
superset of PSDL.
Also, declaring CIDL not to be a superset of PSDL means that the
<catalog_use_dcl>, <abstract_storage_home_binding> etc become
meaningless, as they refer to entities from PSDL.
Proposed Resolution: Declare CIDL to be a superset of PSDL.
See issue 3065.
Question: Is it legal to send the same codeset context more than once
on the same connection?
The spec says:
Codeset negotiation is not performed on a per-request basis,
but only when a client initially connects to a server.
These words suggest that the codeset must be sent on the first request,
but don't say whether it's OK to send it more than once.
I would like to have clarification, and also a loose interpretation. Here
is why:
A multithreaded client starts talking to a new object from
multiple threads more or less simultaneously. If the codeset
info must be sent only on the first request and is illegal on
subsequent requests, we end up with rather complex locking
logic in the connection management layer of the ORB. In effect,
each request is no longer a stand-alone and context-free thing;
instead, how to send a specific request now depends on what
other threads may have done in the past.
That's not very nice (even though it can be implemented) because
it needlessly complicates things.
So, I would like to change things such that it is legal to send the
codeset context even if it was sent previously on the same connection.
When that happens, the server should simply and silently ignore all
but the first context (even if the subsequent contexts have different
codeset information from earlier ones). That way, requests remain
context-free. [ Yet again, we see a sterling demonstration that attaching
semantics to the duration of a connection was a very bad idea, especially
in a model that is connectionless ]
Further, it seems pointless to send codeset info at all unless the client
actually uses an operation that involves a wchar or wstring parameter.
So, I think it would make sense to relax things such that the codeset
need not be sent until the first request is made that requires sending it.
see above
Summary: It does not appear that reply service contexts are maintained when retrieving
polled requests from a Router. Although the Router interfaces properly
propogate the service contexts to the the untyped reply handler representing the
PersistentRequest, there is no way for the client to retrieve these contexts
from the PersistentRequest::get_reply. This may make it impossible for the
client to interpret the reply data (e.g. if the reply contained CodeSet
contexts).
see above
Summary: I propose that public interface of _var types, the similar "smart pointer" types used in struct fields, and "smart pointer" types returned from sequence index operators be extended. (see file)
Fixed by Portability submission
Summary: It"s currently not possible for a C++ client or server to receive a parameter value of type Any, store that value in filesystem or a database and later reconstruct Any value from persistent represe
Fixed by portability submission
Summary: Cannot use DII to invoke an operation that expects or returns a complex user-defined type. Any needs to provide member functions for composing Any"s containing arbitrary user-defined values
Fixed by Portability submission
Summary: There hsould be a way to access an unknown type inside an Any by "iterating" over the Any to examine the type in terms of the primitive types that make it up.
Fixed by Portability submission
Summary: Here is an extremely simple extension to the any type to allow decomposition of values to their constituent parts: <EXAMPLE issue251>
Fixed by Portability submission
Summary: If all I want to do is rethrow an exception in my C++ client code, there is no convenient and compliant way. It would be useful to add extra members to allow this.
Fixed by Portability submission
Summary: Sec 16.12 Pg 16-27 CORBA2.o Why are we returning a Long * from operator[] rather than an LongArray_slice&?
Fixed by Portability submission
Summary: [Sec 16.8.1 Pg 16-14 CORBA2.0 p31, Section 3.10.1 para 14: If I have T_var referring to T. How can I take ownership?How to stop it from being deallocated when T_var goes out of scope?
Fixed by Portability submission
Summary: Standard requires that a conforming implementation must free the inaccessable storage associated with a parameter passed as a managed type(T_var). How to achieve it for out parameters??
Fixed by Portability submission
Summary: Since RTTI is not ubiquitous, the _narrow operations for Exceptions should be defined, even when RTTI available. They are trivial to implement using RTTI.
Fixed by Portability submission
Summary: Implementation dependent: Implementation of parameter passing using T_var types
Fixed by Portability submission
I set out reading ptc/2000-04-05 to answer a question: how could a
client interceptor for the OTS implement the proper behavior for the DII
get_response or get_next_response operations that require the
WrongTransaction to be raised if the current thread is not properly
associated with the same transaction as the request.
I wasn't able to answer this question authoritatively, because there is
nothing in the Portable Interceptors Chapter that indicates the proper
time sequencing of when the client side request interceptor operations
are invoked in relation to the use of the DII (or the AMI_ messaging
interfaces either.)
By inference, it appears to me that the only way to allow an OTS client
request interceptor to exhibit the proper semantics is for the ORB to
not make calls to receive_
when the response is
received from the protocol stack, but instead to make them when
get_response or get_next_response is called by the application.
This paragraph in 21.3.7.2:
"Asynchronous requests are simply two separate requests. The first
request receives no reply. The second receives a normal reply. So the
normal (no exceptions) flow is: first request - send_request followed by
receive_other; second request - send_request followed by receive_reply."
is also not particularly useful, since it doesn't give any indication
how the interceptor can distinguish the "first request" from the "second
request".
So, to sum up, the PI chapter needs explicit information showing the
time sequencing of when the request interceptor operations are invoked
in relationship to a static call, a DII call, and AMI_ calls.
see above
When using the pollable sets, pollers are registered with
PollableSet::add_pollable() and retrieved using
PollableSet::get_ready_pollable(). As pollers are valuetypes they are passed by
copy, thus portable applications must assume that get_ready_pollable() returns
a different poller instance than the one passed to add_pollable(). Thus, with
non-TII, currently there is no portable way to find out how requests
(represented by the pollers returned from sendp) and replies (represented by
the pollers returned from get_ready_pollable ) correlate.
Consider the following IDL:
module Stock
{
interface Quoter
};
and a client that does a 1000 invocations in the style
poller = quoter->sendp_get_quote(portfolio[i].stock_name);
poll_set->add_pollable(poller);
Now, the client could retrieve the 1000 replies in the order:
while(poll_set->number_left() > 0)
;
But how can the client find out which returned quote belongs to which
stock_name?
Possible resolutions:
---------------------
(a) Reconsider the introduction of a correlation id on pollers which can be
used to compare if two pollers are referring to the same request/reply.
(b) Based on the fact that pollable set is locality-constrained and that
valuetypes support sharing semantics (see CORBA 2.3, 5.2.4.2 Sharing
Semantics), it could be required that PollableSet::get_ready_pollable() returns
a pointer to the same valuetype instance as the one passed as argument of
PollableSet::add_pollable().
(c) Close without action, i.e. has to be solved at the application level, e.g.
in our example the application would have to solve this by changing get_quote to
long get_quote(in string stock_name, out string stock_name);
Discussion:
-----------
(c) contradicts with the CORBA Messaging Philosophy that AMI is a mere
client-side issue and that in principle any existing target can be called
asynchronously.
(b) means that we would have two different polling-related correlation
mechanisms:
(a) means that a generic correlation mechanism is defined that covers both:
intra- and inter-process correlation. This was variant (a) of issue 2803 in the
latest vote. It failed with 5 NO : 4 YES : 3 ABSTAIN.
I could work out two straw men for (a) and (b) for the next vote, or much
better, we could try to discuss this before the next vote and just work out a
straw man for the variant that has better acceptance.
close no change
There is currently no way to register a value factory from an ORB
initializer.
see above.
looking at the POA IDL, I get the impression that it was written at a time
where the use of multiple ORBs in a process wasn't anticipated. With
the advent of messaging, OTS, QoS policies, etc, it is more and more common
for one application to use several ORBs simultaneously.
When writing code, it becomes an endless pain dealing with multiple ORBs.
That's because I have to endlessly pass the ORB around in my program, just
so I can do things like call object_to_string() or string_to_object(), etc.
I think it would be really useful to have an ORB() accessor on the POA
interface:
interface POA
{ CORBA::ORB ORB(); // ... };
The accessor would return the ORB for this POA. Doing this would eliminate
most of the cases in my code where I have to pass the ORB around. For
example, in a servant, I can call _default_POA(), and then call ORB() to
get at the ORB.
Adding the operation would cause any compatibility problems, I believe.
Opinions?
see above
This problem comes from the fact that RoutingPolicy is actually a range: min and max. Basically, Messaging defines this range of Routing QoS:
ROUTE_NONE(0) ---> ROUTE_FORWARD(1) ---> ROUTE_STORE_AND_FORWARD(2)
You can set your min and max to any of the values, with the caveat that min must be <= max. The issue that concerns us is when the min is ROUTE_NONE(0) and the max is either ROUTE_FORWARD(1) or ROUTE_STORE_AND_FORWARD(2).
If you look at the Messaging spec (orbos/98-05-06) in section 5.3.5.3, it says:
"If, for example, the min is ROUTE_NONE and the max is ROUTE_FORWARD, the Routing protocol will normally be used but a direct connection may be used if available."
Of course, we've left in "usually" just to make sure we could screw up OTS for you 
Reading the text in section 3.3 makes me believe that an issue should really be raised in the Messaging-RTF to clarify this. Here's what I BELIEVE the results would be for all of the combinations.
min maxresultconfidence ----------- ---------- -------------------- ROUTE_NONEROUTE_NONEDirect Call100% ROUTE_NONEROUTE_FORWARDTII if possible50% direct if not ROUTE_NONEROUTE_STORE_AND_FORWARDTII if possible50% direct if not ROUTE_FORWARDROUTE_FORWARDTII Only100% ROUTE_FORWARDROUTE_STORE_AND_FORWARDTII Only100% ROUTE_STORE_AND_FORWARDROUTE_STORE_AND_FORWARDTII Only100%
Obviously, the problem is with cases #2 and #3.
How should an ORB determine which to use: what priority is given to each of the RoutingType values?
close no change
Minor codes specifications are missing in all the places where the
specifications states that a system exception is to be raised. The minor
codes need to be specifiedto complete the specification of exceptional
beahivior.
see above
I am in the process of implementing Portable Interceptors within a C++
ORB,
and I would like to raise an issue for resolution regarding the semantics
of the
"register_initial_reference()" function, particularly with respect to the
memory
management of the object being registered.
The interface for this function is as follows:
void register_initial_reference (
ObjectId id,
Object_ptr obj
);
Within the Portable Interceptors specification, there is really no
information about
how the memory for the object should be managed. For example, does the
caller of
"register_initial_reference()" pass ownership of the object to the ORB, or
not?
Also, does the caller of "resolve_initial_references()" gain ownership of
the object
which is returned, or not?
Here is my proposed resolution:
The fact that the "obj" parameter is a CORBA::Object implies that it is a
reference-counted
object. Therefore, it would make sense that when
"register_initial_reference()" is called, the
ORB performs a "_duplicate()" on the object to increment its reference
count (the ORB would
then hold its own reference count). The caller of
"register_initial_reference()" can decide
whether to call "release()" or retain its own reference count.
Later, when "resolve_initial_references()" is called, the ORB would call
"_duplicate()" on the
object prior to returning it to the caller, thereby giving the caller its
own reference count.
The caller would then need to call "release()" when it is finished with
the object.
When the ORB is deleted, it must clean up the lookup table of registered
objects. To do this,
it simply calls "release()" on each one, and if no one else holds a
reference count, then
the object is simply deleted.
I would like the hear other people's thoughts on this, particularly those
who have done or are
working on a C++ implementation of PI.
see above
(All document refs to ptc/00-04-05)
Sec. 4.3.7.1 (Object::get_policy) talks about "the Policy as specified in
the IOR". Policies get translated to IOR components, but AFAIK there's no
general way that a component can be unscrambled to give a Policy. This
suggests that we need another interception point, effectively the inverse of
the existing IORInterceptor (sec. 21.5), that allows an IOR component to be
converted into a Policy on the client side.
I suggest something like:
local interface ReceiveIORInterceptor : Interceptor
{ void establish_policies (in ReceiveIORInfo info); };
local interface ReceiveIORInfo
{ CORBA::Policy set_policy (in CORBA::Policy policy); IOP::TaggedComponent get_ior_component (); IOP::TaggedComponent get_ior_component_from_profile ( in IOP::ProfileId profile_id); };
and an extra operation add_receive_ior_interceptor in ORBInitInfo.
ReceiveIORInterceptor::establish_policies provides the opportunity for an
interceptor to turn IOR components back into Policies, using the
interceptor's Policy Factories directly or indirectly via
ORB::create_policy.
The ORB will call this method on all registered ReceiveIORInterceptor
objects during or before the first call of Object::get_policy (we needn't be
more specific - this would allow eager calls on unmarshalling or lazy calls
within Object::get_policy).
see above
Portable interceptor implementations need access to the ORB. The presumed
place to put the ORB would be on ORBInitInfo since at least one
implementation needs the ORB at initialization time. Is that sufficient?
Or is it also needed in RequestInfo and IORInfo? My guess is that having
ORB only on ORBInitInfo is sufficient. All interceptors begin here. If
the ORB is needed at other points, the implementations can assure that it
is available where it's needed.
Since ORB is PIDL and we don't want to pollute the interceptor interfaces
with PIDL, we have to create IDL access to the ORB, but that's another
issue.
This issue is a restatement of issue 3403. Merge with issue 3403 and close this issue
Portable interceptor implementations need access to the ORB. In order to
accomplish this, the ORB must be defined in IDL There are four
possibilities that have been opined:
1. Define the ORB as "native ORB;"
This puts the ORB into the IDL namespace. However, the ORB is still
described in PIDL. This doesn't really help us to remove PIDL, some folks
feel this is a misuse of native, but it would be sufficient for the
requirements of PI.
2. Define an IDL wrapper for the ORB, call it proxyORB for now.
proxyORB would contain exactly the same items that the PIDL ORB does, only
defined in pure IDL. Advantages: this is a migration step toward getting
rid of ORB PIDL if we encourage folks to use proxyORB rather than ORB.
Disadvantages: dual maintenance; lots of work - too much for this FTF?; I
don't think we know all the ramifications; where do you get a proxyORB?
from the ORB?
3. Make the leap and redefine ORB in IDL now.
This option is similar to option 2, but the IDL is not a wrapper, it's the
real ORB. Advantages: no dual maintenance; we get rid of ORB PIDL right
now. Disadvantages: BIG step - too big for this FTF?; lots of work; I
don't think we know all the ramifications.
4. Make the ORB a primitive type like TypeCode.
This seems to be generally undesired. It requires all compilers to change.
Unless someone really likes this approach, I don't think we should even
consider it.
Resolve this issue simultaneously with 3772 and close it as soon as 3772 is resolved and closed
How are the routing policies e.g.ImmediateSuspend, LimitedPing, UnlimitedPing,
etc. created. It is not clear that these can be created using the standard
create_policy operation since these policies are valuetypes that support the
CORBA::Policy interface.
Also what are the Policy Type tag values for these policies?
close no change
object_to_string and string_to_object are missing on ORBInitInfo.
Resolve in conjunction with 3772 and close this issue when 3772 is resolved
it appears to be impossible to portably attach OTS policies
to POAs with the machinery that is currently in place. We need a fix for
that, otherwise OTS ends up getting hamstrung...
close no change
The text in section 9.2.3 / page 9-71 describing the
arguments attribute to ORBInitInfo could use some
more precise wording. It reads:
"This attribute contains the arguments passed to ORB_init.
They may or may not contain the ORB's arguments."
I take this to mean that any ORB_init arguments that
applied to the ORB instance being created may not be
present. All other strings passed to ORB_init will be
present so initialisation strings can be passed to
the interceptors through ORB_init.
With the current text it is possible to think that
you may not get any of the arguments to ORB_init.
see above
Section 15.4.5, page 15-39:
LocateRequest messages may be sent from a client to a server to
determine the following regarding a specified object reference:
In the absence of a definition for how to judge a reference "valid", this
is a meaningless statement.
close with revision
ORBs should be required to reject IORs that do not contain any profile that the ORB can use
accomodated by proposed change from Issue 3234.
Part 2: Should an ORB be allowed to drop non-standard profiles (as it is allowed
to, indeed almost encouraged to do in GIOP/IIOP 1.2) even though it is not faced
with any resource contraints. Moreover, when it is faced with resource
contraints should it be required to follow a specific sequence in determining
what profiles to drop.
The proposed resolution defines two possible IOR conformance classes for every ORB interoperability
Since the index numbering of sequences is a language mapping specific issue, the origin of the selected_profile_index within the IORAddressingInfo must be specified. I assume a zero origin is meant.
Proposed Resolution:
Add the following sentence to the description of IORAddressingInfo (in section 15.4.2.1 of the 25 March CORBA 2.4 preliminary draft): "The first profile has an index of zero."
Accept proposed solution.
CORBA is inconsistent on how to deal with the lack wide character code set
information in an IOR and the codes set service context.
When a server receives a service context without a wide character code set
specified, then it is supposed to raise BAD_PARAM when it receives wide
characters data from the client.
However a client is supposed to raise INV_OBJREF if the IOR is missing
from the server's native wchar code set . In CORBA 2.3, section13.7.2.6,
"Code Set Negotiation", it says, "... a server that supports interfaces
that
use wide character data is required to specify its native wchar code set;
if
one is not specified, then the client-side ORB raises exception
INV_OBJREF."
This requires a client to know whether a server supports interfaces that
use
wide character data at the time the client receives an IOR. To determine
this when the first IOR is received is a burdensome task. The client orb
would be forced to apply an exhaustive examination, such scanning all of
the
server's IDL bindings or the contents of the IFR looking for wchar types.
Additionally the client may need to determine if some Any might flow
containing wchar data.
I propose that the client's behavior be changed to match the server's. If
any wide character data is encountered and the server's IOR was missing
the native wchar code set, (which would cause the wide character
transmission
code set to not be negotiated), the client should raise BAD_PARAM.
This will allow common marshal and demarshal code to be independent of
whether it is running as a client or server. It also allows users to not
configure
wide character code sets if they know they aren't using them.
The check should be able to be done at invoke time by the client orb
Why does it make sense at all to allow an ORB to throw an exception if it finds
a service context it does not "understand"? This is not very helpful for
interoperability. Would a sending ORB have to handle this exception and resend
the same request without context to allow to interoperate with an ORB throwing
BAD_PARAM in this case? If an unknown service context is sent with a reply, the
receiving ORB would throw BAD_PARAM at the caller (even if it got a valid
reply). The originator of the service context wouldn't even know.
To close with Issue 3561 resolution to eliminate option of throwing exception
In document ptc/00-03-02 on page 13-30 in the last bullet on that page it says: "If a system
exception is raised , it shall be BAD_PARAM with an OMG standard minor code of 1".
This cannot be right because the OMG standard minor code of 1 for BAD_PARAM is assigned to "failure
to register, unregister or lookup value factory."
I recommend that we change this minor code to a new one that is properly allocated with the
associated text that reads something like: "Service context not understood". I am still wondering
though why BAD_PARAM is the correct exception to raise. Wouldn't BAD_CONTEXT be more appropriate?
In any case we have to change the minor code, even if we cannot make up our minds about which
exception.
resolved and closed
Page 15-50 of 2.3.1:
ORBs that suport only version 1.1. or 1.2 IIOP profiles must
ignore, but preserve, any data in the profile that occurs
after the components member.
A 1.2 ORB is obliged to ignore, but preserve, any information that follows
the components member in 1_1 profile body. I think the cost of implementing
this is quite high. What follows after the components member is not in
a separate encapsulation. So, an ORB that receives an IOR that indeed has
data after the components member doesn't understand anything about that data
and therefore must treat it as a blob of bits.
However, the IOR might be little-endian and the receiving ORB might be
big-endian. When the receiving ORB wants to send the IOR back out, it
can't send it as a big-endian IOR because it can't know how to byte-swap
the data that follows the components member. That means that a big-endian
ORB is obliged to remarshal the IOR back as a little-endian IOR.
That's inconvenient, to say the least.
I don't think it makes sense to require an ORB to preserve something that
is not encapsulated, simply because the cost of doing this is high.
(The ORB has to keep a copy of the marshaled profile around because of
the trailing bit it doesn't understand.)
Close with revision
Section 15.3.4, page 15-18:
The encoding used for indirection is the same as that used for
recursive TypeCodes (i.e., a 0xffffffff indirection marker
followed by a long offset (in units of octets) from the beginning
of the long offset).
[...]
Indirections may refer to any preceding location in the GIOP
message, including previous fragments if fragmentation is used.
This includes any previously marshaled parameters.
The beginning of the section ("is the same as that used for recursive
TypeCodes") is in conflict with what appears at the end ("refer to any
preceding location in the GIOP message [...]. This includes any previously
marshaled parameters.")
This is incorrect because the indirection for type codes does not permit
indirections that span type code boundaries (page 15-27):
The indirection applies only to TypeCodes nested within
some "top-level" TypeCode. Indirected TypeCodes are not
"freestanding," but only exist inside some other encoded TypeCode.
I would suggest to rephrase the first part of what is on page 15-18
to avoid saying that the indirection is the same as for type codes
because that's simply not the case.
close with revision
a chunk can be followed by:
1. a new chunk (starting with its size tag)
(1 <= chunk_size_tag < 0x7fffff00
2. a new value (value_tag | 0 | value_ref)
(0x7fffff00 <= value_tag <= 0x7fffffff)
(valueref = 0xffffffff)
3. an end tag
(0x80000000 <= end_tag <= 0xffffffff)
A value indirection and a "top-level" end tag, both have the same tag (0xffffffff).
Consequently, the 0xffffffff tag marks the end of the current value but it is not clear whether or not a new value (indirection) has started.
An example where this situation occurs is a ring buffer that is chunked encoded.
to close with revision
When the response_flags text was added for GIOP 1.2 Request processing,
the old text for the GIOP 1.0 and 1.1 response_expected field was
removed. Thus, the current documentation no longer completely describes
the GIOP 1.0 and 1.1 protocols.
to close with revision
I have a question on how can ORB vendor support profile with ID
TAG_MULTIPLE_COMPONENTS? The spec 2.3/13.6.2 says single profile holds
enough information to drive a complete invocation. Let us say we have an
IOR with one profile and the ID is TAG_MULTIPLE_COMPONENTS. As per
13.6.2.2, the profile body in this case contains a
MultipleComponentProfile. Let us again assume that there is only one
TaggedComponent with component id of TAG_CODE_SETS and its component
data.
What we have here is a legal profile with no end point information. What
can a ORB do with such a profile? Is there any thing broken here or did
I just misinterpret the spec completely?
Close with no revision
I believe that, at some point, we decided that it is legal to send
request for different GIOP versions over the same connection. Could someone
please confirm or deny? (My memory is a bit hazy on the details.)
At any rate, careful scrutiny of the spec does not reveal any words that would
either state that separate connections must be used for different GIOP versions
or that they can share a single connection. A definite statement is required
either way.
Assuming that different GIOP versions can indeed coexist on the same
connection, we get an interesting problem: for GIOP 1.0 and 1.1, the spec
disallows a client to send a CloseConnection message; for GIOP 1.2, it
requires the client to send a CloseConnection message. This begs the question:
if different GIOP versions can coexist on the same connection, it becomes
impossible to achieve orderly connection shutdown. Sending a CloseConnection
message is illegal for GIOP 1.0 and 1.1, whereas it is required for
GIOP 1.2... So, what's the client to do if multiple GIOP versions are used
over the same connection?
To close with revision
There seems to be a problem with valuetypes contained in anys.
Consider the following:
valuetype A
;
valuetype B : A
{ private long long x; };
If an instance w/ the following structure:
A { a = {B { x = {<value>}}}}
is inserted into an any and the any is received by an event service. Given that
the event service has no type information of the B encoded inside of A, the
event service has no way of knowing how big A.a (an instance of B) is and how
many bytes it needs to read (unless it contacts an IR)
Am I missing something here?
Close this issue and place it into the GIOP wish list for future enhancements to GIOP.
Although this is a Java-specific issue, I suspect it will have to be
decided in interop, therefore I'd like this to be an interop issue. I've
cc'ed java-rtf since I'm sure they'll be interested.
System exceptions only have: minor code, completion status. Java
exceptions all have a reason string as well. This is a potentially
significant bit of info that is not getting transferred across the wire in
Java ORB implementations. Our rmi over iiop customers expect this
information.
Our suggested solution is to create another service context for a system
exception reason string. When a system exception occurs, on a Java server,
the ORB places the reason string into this service context on the reply
message. On a Java client, the ORB checks for and extracts this string and
uses it when creating the system exception instance which is propagated to
the application code. If the service context doesn't exist, the Java ORB
just does what it does today. Any other client bindings may ignore this
service context.
Java bindings do not need to change for this proposal.
To be more precise (sorta), we need three things:
1. A new service context ID
const ServiceId SystemExceptionReason = TBD;
2. The context data associated with this ID is a CDR encapsulation of a
string.
3. Some verbage somewhere describing this.
closed/resolved
Section 15.3.4.5 contains an inconsistency in the description of how end tags
for valuetypes are written. Consider the case where an unchunked value (V)
contains a chunked value (CV1). Should the end tag for CV1 contain a nesting
depth of -2 or -1?
The following sentence in the spec seems to imply that the correct value is -2:
> The end tag is a negative long whose value is the negation of the absolute
> nesting depth of the value type ending at this point in the CDR stream.
However the spec also says:
> The outermost value type will always be terminated by an end tag with a
> value of -1.
which is not true if the end tag for CV1 is written as -2, since no end tag
with a -1 value will be written.
Proposed resolution:
Delete the second above sentence from the spec.
Close with revision using alternative A above.
The valuetype encoding "grammar" in 15.3.4.7 is wrong. The rule for
<state> should be:
<state> ::= <octets> |<value_data>* [ <end_tag> ]
to allow for valuetypes with no state and therefore no value chunks.
-
to close with revised text
Looking at formal/99-10-07, 15.3.2.8 which describes marshaling of fixed
types I ran into a question. The section doesn't mention how to indicate
the scale of the written decimal.
My understanding is that the TypeCode of kind fixed, which gets written
before the value, indicates the maximum number of digits and the maximum
scale, not what is currently contained in the number. To describe the
current scale I would expect that a decimal point gets written to the
stream, just like the decimals into the half-octets as described in
15.3.2.8.
Close with no Interop Revision
It is unclear in the spec when reply messages are allowed when a fragmented
send message is sent.
It is possible to know that a system exception will occour before the last
fragment in a message is recieved, for example the request can be
demultiplexed to discover the object does not exist, or the appropriate
service contexts are not present.
It should be legal to send a reply containing anything but a NO_EXCEPTION or
USER_EXCEPTION before the last fragment is recieved.
close without revision
1. In the document OMG ptc/99-10-04 p.69-329 there is in item 5 a use
of the type ComponentHome, shouldn't it be CCMHome? If I do recall
correctly, ComponentHome was used in the first versions of the
specification proposal.
You are correct. ComponentHome should be CCMHome
It is probably not a good idea to mandate an implementation for
Enumeration, since there may be different options for implementing.
For example, it may be desirable for
performance reasons to implement a form of lazy Enumeration that does
not carry with it every element that it can contain, but requiring
this kind of implementation can be overkill for some
applications. Given this, Enumeration is defined as an abstract
valuetype and at least one concrete specialization of it is
required. In addition, FOR INTEROPERABILITY, at least one STANDARD
implementation must also be provided so that client stubs and server
skeletons know how to marshal and unmarshal Enumeration values.
resolution see above
every ORB I know of implements the various destroy() operations on
local objects (such as policies or DynAny) as a no-op and destroys the local
object on the final call to release() instead. Yet, the spec still requires
programmers to call destroy(). The problem with this is that programmers
can easily end up writing non-portable code without any visible problem.
Then, when code is moved to another ORB, it is conceivable that it will
leak objects.
This isn't very pretty. I think we should get rid of the destroy() calls
on local objects (possibly with the exception of the ORB object, although
the entire shutdown issue for that is quite a mess anyway). It doesn't
make sense to require the programmer to make a destroy() call for something
that naturally can be reference counted.
When the interfaces identified in section 11.1.5 are updated to be local interfaces, any destroy() o
Problem: The new IDL keywords use mixed case, rather than the lower case style used by current keywords. Should the new keywords be changed to comply with the existing style?
Yes, new IDL keywords should be changed to conform to existing style guide.
2. Implementation of get_component with separate ORB and component vendors
Problem: A design goal of the components specification was to permit the component container to be provided by a different vendor than the ORB vendor. When this is true, how does the implementation of get_component work?
closed issue, resolved
1) The isBasic Attribute needs to be removed from HomeDef to synchronize
with the regular CORBA IR.
resolved
Table 8-1 shows a mapping for CCMObject::get_home. It looks like it should
say CCMObject::get_ccm_home
Proposal:
Change "CCMObject::get_home" to "CCMObject::get_ccm_home" in Table 8-1.
No Data Available
Chapter 8 omits to mention how the CCMHome::get_home_def call is mapped by
the bridge at runtime to an EJB operation.
Issue:
The very similar call CCMHome::get_component_def is shown as mapped to the
EJBHome.getEJBMetaData operation, but there is no mapping shown for
CCMHome::get_home_def. It appears that get_home_def could be also be
implemented using the EJBHome.getEJBMetaData operation, and if necessary,
with the help of Java introspection.
Proposal:
Add a line in Table 8-1 to show CCMHome::get_home_def mapped at runtime to
EJBHome.getEJBMetaData.
Add a line in Table 8-1 to show CCMHome::get_home_def mapped at runtime to EJBHome.getEJBMetaData
Summary:
8.2.1.2 of the CCM specification says that EJB finder and creator methods
which return an RMI object reference are mapped to methods which return a
Components::CCMObject reference. It is unclear whether the actual base
class CCMObject is intended or whether the specific component subclass
(e.g., Widget) is intended. The specific subclass seems more sensible,
and is consistent with the equivalent IDL mappings shown in section 5.8.4.
Proposal:
Change 8.2.1.2 to make it clear that the specific subclass (e.g., Widget)
is the return type.
Change 8.2.1.2 to make it clear that the specific subclass (e.g., Widget) is the return type
When mapping EJB set/get methods to a CCM view, it is not clear whether the
resulting IDL attributes belong on the ComponentDefault interface or on the
component definition itself
Issue:
Set/get method pairs on the EJB remote interface map to IDL attributes, but
do these attributes end up in the XXXDefault interface or in the XXX
component definition? Section 8.2.1.2 of the specification seems to imply
they belong in the XXXDefault interface, but section 5.3.2 says the
component definition for a basic CCM "shall only contain zero or more
attribute declarations", which suggests that attributes of a CORBA
Component belong in the component definition. Also, the mapping in the
other direction (EJB view of a CCM), described in 8.3.1, suggests that CCM
attributes are always found in the component definition itself. It appears
that both versions will work, but this point is worth clarifying.
Proposal:
Change 8.2.1.2 to say that all EJB set/get method pairs are mapped to IDL
attributes on the component definition itself.
resolved
Section 5.12.1 of the spec can be interpreted to mean that the
CCMObject::remove call is not intended for use by CCM clients; but this is
inconsistent with the EJB/CCM mapping given in chapter 8.
Issue:
The explanation given for the CCMObject::remove call in section 5.12.1 is:
"This operation is called when a component is about to be destroyed.
The component
can perform any cleanup processing required (e.g. releasing resources)
prior to its
destruction."
This explanation can be interpreted to mean that the call is a private call
from a CCM container to one of its components; if it has this internal
purpose then it might not be
intended for use by CCM clients wanting delete the component. However,
table 8-1 shows that the CCM view of an EJB maps this call to the
EJBObject.remove()
method. This implies that the method is intended for client use as the
EJBObject.remove() is. If so, then it also makes more sense to implement
the
CCMHome::remove() method in terms of the EJBObject.remove() method, rather
than the current mapping which requires an EJB Handle.
Proposal: (a) Change the text for remove() in 5.12.1 to say: "This
operation is used to delete a component".
(b) Change the mapping in table 8-1 for CCMHome::remove to use
EJBObject.remove
Change the text for remove() in 5.12.1 to say: "This operation is used to delete a component".
I think I found a possible (very minor) optimization for the
GIOP 1.3 spec, but maybe I'm missing something in GIOP 1.2
The new <target> field on the RequestHeader_1_2 structure is
always aligned to a 4 byte boundary, the reserved[3] field ensures
that. Consequently the discriminant for the TargetAddress union
does not end on a 4 byte boundary, but will require 2 bytes of padding
following it, since all the union values in this case start on 4 byte
boundaries.
IMHO, using just 1 byte for the reserved[] field, would have
resulted in more natural alignments. Did I get something wrong here?
Is this something likely to be fixed in GIOP 1.3?
Close this issue as too much of a change for this RTF, and add it to the GIOP wish list for future p
Well, a new Java release is upon us, and with it comes a new CORBA
implementation. I'm trying Java 2 SE 1.3 CORBA clients against an ILU
2.0beta1 CosNaming server, and we find that the Java ORB cannot
reliably connect to the server. Why not? First, we must analyze the
IOR provided by the ILU service:
IOR:000000000000002849444C3A6F6D672E6F72672F436F734E616D696E672F4E616D696E67436F6E746578743A312E300000000002000000000000002F0001000000000016776174736F6E2E706172632E7865726F782E636F6D00270F0000000B4E616D6553657276696365000000000100000024000100000000000100000001000000140001001800010001000000000001010000000000
If we look at this (those who've received it un-truncated) we find that it advertises the following:
_IIOP_ParseCDR: byte order BigEndian, repository id <IDL:omg.org/CosNaming/NamingContext:1.0>, 2 profiles
_IIOP_ParseCDR: profile 1 is 47 bytes, tag 0 (INTERNET), BigEndian byte order
_IIOP_ParseCDR: profile 2 is 36 bytes, tag 1 (MULTIPLE COMPONENT), BigEndian byte order
(iiop.c:parse_IIOP_Profile): bo=BigEndian, version=1.0, hostname=watson.parc.xerox.com, port=9999, object_key=<NameService>
(iiop.c:parse_IIOP_Profile): encoded object key is <NameService>
(iiop.c:parse_IIOP_Profile): non-native cinfo is <iiop_1_0_1_NameService@tcp_watson.parc.xerox.com_9999>
(iiop.c:parse_MultiComponent_Profile): profile contains 1 component
(iiop.c:parse_MultiComponent_Profile): component 1 of type 1, 20 bytes
(iiop.c:parse_MultiComponent_Profile): native codeset for SHORT CHARACTER is 00010001, with 0 converters
(iiop.c:parse_MultiComponent_Profile): native codeset for CHARACTER is 00010100, with 0 converters
That is, there's a vanilla Internet profile (bo=BigEndian,
version=1.0, hostname=watson.parc.xerox.com, port=9999,
object_key=<NameService>), plus a Multicomponent profile, noting that
the ILU ORB's native codesets are Latin-1 and UCS-2.
OK, great. Now we get the first message from the Java ORB:
0000 47 49 4f 50 01 00 00 00 00 00 01 00 GIOP........
0000 00 00 00 02 00 00 00 01 00 00 00 0c 00 00 00 00 ................
0010 00 01 00 20 00 01 01 00 00 00 00 06 00 00 00 90 ... ............
0020 00 00 00 00 00 00 00 28 49 44 4c 3a 6f 6d 67 2e .......(IDL:omg.
0030 6f 72 67 2f 53 65 6e 64 69 6e 67 43 6f 6e 74 65 org/SendingConte
0040 78 74 2f 43 6f 64 65 42 61 73 65 3a 31 2e 30 00 xt/CodeBase:1.0.
0050 00 00 00 01 00 00 00 00 00 00 00 54 00 01 01 00 ...........T....
0060 00 00 00 0c 31 33 2e 31 2e 31 30 33 2e 36 38 00 ....13.1.103.68.
0070 0e e9 00 00 00 00 00 18 af ab ca fe 00 00 00 02 ................
0080 67 d5 93 95 00 00 00 08 00 00 00 00 00 00 00 00 g...............
0090 00 00 00 01 00 00 00 01 00 00 00 14 00 00 00 00 ................
00a0 00 01 00 20 00 00 00 00 00 01 01 00 00 00 00 00 ... ............
00b0 00 00 00 05 01 00 00 00 00 00 00 07 53 79 6e 65 ............Syne
00c0 72 67 79 00 00 00 00 06 5f 69 73 5f 61 00 00 00 rgy....._is_a...
00d0 00 00 00 00 00 00 00 28 49 44 4c 3a 6f 6d 67 2e .......(IDL:omg.
00e0 6f 72 67 2f 43 6f 73 4e 61 6d 69 6e 67 2f 4e 61 org/CosNaming/Na
00f0 6d 69 6e 67 43 6f 6e 74 65 78 74 3a 31 2e 30 00 mingContext:1.0.
Note that we are seeing a CodeSets service context, even though the
request is GIOP 1.0. The service context specifies a TCS-C of ASCII,
and a TCS-W of UCS-2.
The question is, what should the server do with it?
First of all, there seems to be no way in which the algorithm in
section 13.2.7.6 can result in the TCS-C specified in the service
context. So perhaps this bug should be detected and signalled back to
the sending ORB. How? Using CODESET_INCOMPATIBLE might make sense,
but that really doesn't flag the bug in the client-side implementation
of the codesets determination algorithm. Perhaps a straight
COMM_FAILURE would be better. Opinions?
Secondly, since this is GIOP 1.0, the client could reasonably ignore
the service context, and go ahead with using its default codeset
(Latin-1). However, to do so risks comm failure down the line, as
ASCII (the TCS-C assumed by the client) does not permit many Latin-1
characters. It seems better to flag this situation up front.
close with revision. See below
It's occoured to me that according to the spec it's allowable for
a message to be fragmented and have second and subsequent
fragments change the version fields.
Having the version change while in the middle of reading a
wstring could cause problems, the CDR encoding of version 1.1
strings is always two bytes longer than the corresponding 1.2
encoding, if the version changed while in the middle of reading
the wstring the length field would be out by two.
Secondly if request IDs are per-protocol rather than
per-connection (as aired in issue 3438) then the request ids of
the fragments could interfere.
I think an extra phrase should be added to the spec with regards
to fragmentation, similar to the one regarding byte order:
The version of fragments must match the version of the initial message that
the fragment extends.
Close without revision since the spec was already clarified to state this.
The UK believes the footnote to section 13.6.2, page 13-16, of CORBA
2.3.1 (this is clause 5.6.2 with the footnote appearing on page 13 of
DIS 19500-2) does not make sense, especially the phrase "... except
ones that make such profiles...". The meaning of this footnote needs
to be clarified with revised text.
Close without revision.
The Japanese would like to clarify the first sentence of the first
paragraph of section 15.5.2, page 15-46, of CORBA 2.3.1 (this
is clause 6.4.2 of DIS 19500-2, page 70) by adding the phrase
"if Bi-Directional GIOP is not used" to the end of the sentence.
The resulting sentence would read "Only the client (connection
originator) may send Request, LocateRequest, and CancelRequest
messages if Bi-Directional GIOP is not used."
Is there any reason not to add this phrase now that Bi-Directional
is in the OMG specification?
Agree that this was an editorial oversight in corba 2.3.
The Interop RTF added text that explicitly states that padding for a
Request body in GIOP 1.2 is not necessary if the body is empty. No
equivalent text was added for empty GIOP 1.2 Reply bodies.
Agree to add equivalent text for reply bodies.
In GIOP, the _get_domain_managers operation name is used to indicate
an invocation of the get_domain_managers pseudo operation. OTOH, it is
also used if an attribute domain_managers is accessed, as it would
appear in
interface I
{ readonly attribute long domain_managers; };
Changing the object reference operation on the wire to _domain_managers fixes the problem stated.
Chapter 8 of the spec specifies mappings between EJB operations and their
equivalents in the CCM view, but it leaves the mappings of standard EJB
exceptions unclear.
Issue:
Create methods on an EJB home interface all throw the standard
javax.ejb.CreateException; finder methods on the EJB home interface all
throw the javax.ejb.FinderException; and remove methods on both home and
remote interfaces all throw the javax.ejb.RemoveException. In a few cases
chapter 8 gives an implied mapping: for example, the FinderException on the
findByPrimaryKey method seems to map to either the
Components.UnknownKeyValue exception or to the Components.InvalidKey
exception on the equivalent find_by_primary_key CCM method. Even in these
cases the names are sometimes inappropriate. In the majority of cases,
however, there is simply no CCM equivalent to the EJB exception, and bridge
implementors are left to wonder whether they should attempt a non-standard
mapping.
Proposal:
(a) Add the new CCM standard exceptions Components.CreationFailure,
Components.NotFound, and Components.RemovalFailure
(b) Add Components.CreationFailure to the raises clause of all create
methods on implicit and explicit home interfaces
(c) Add Components.NotFound to the raises clause of
find_by_primary_key on implicit home interfaces, and to the raises clause
of all finder methods on explicit home interfaces
(d) Add Components.RemovalFailure to the raises clause on the remove
operation on implicit home interfaces, to the CCMObject.remove operation,
and to the CCMHome.remove_component operation
(e) Specify in chapter 8 that the EJB Finder exception is always
mapped to Components.CreationFailure; that the EJB CreateException is
always mapped to Components.CreationFailure; and that the EJB
RemoveException is always mapped to Components.RemovalFailure.
(f) Make explicit in chapter 8 the already implied mapping bewteen the
EJB DuplicateKeyException and the Components.DuplicateKeyValue exception
No Data Available
Summary: the current spec doesn"t list policy objects as locality constrained.
This seems rather strange. In particular, at the time I create policy objects,
there is no POA that could be responsible for them, and I have no way
to associate a policy object with a particular POA.
Of course, this raises the question of whether references to policy objects
are persistent or transient, whether I can pass them to another address
space, whether requests on them are single-threaded or not, etc, etc.
Close, no change (for 2.4).
Summary: When a GIOP "LocateRequest" message is sent to a location service and it replies with OBJECT_FORWARD, can the IOR have a type_id equal to simply CORBA::Object rather than the true type id?
Closed with revised text
Summary: Static port # should not be mandated-unworkable.It would be nice if a "standard" IIOP port # was registered with IANA
closed with no revision required
Summary: section 7.2.5 names it "non_existent", while section 12.4.1 says that the GIOP protocol version is "_nonexistent".
resolved, close issue
Summary: There is a problem with marshalling of union TypeCodes where multiple discriminant values select the same arm of the union.
closed with revised text
Summary: It would be good if the request body of a LOCATION_FORWARD reply always started on an 8 byte boundary.
closed with revision from issue 901, 902
Summary: The definition of Any in C.3 is missing the no_copy flag in the class Any::from_string.
Fixed in CORBA 2.2 editing process
Summary: Should the Any extractor signature be (Any_ptr &) instead of (Any &)?
Fixed in CORBA 2.2 editing process
Summary: The following inserter is missing in the C++ spec: void operation <<=(Any &, Any *); // non-copying
Fixed in CORBA 2.2 editing process
Summary: Some IIOP implementations set the object pointers to nil object pointers, while others set them to nil pointers.
closed, no revision required
Summary: Potential problem in determining whether CancelRequest message applies to the current message or a message that has already had a reply sent. Resolutions to this: (file)
closed with revised text
Summary: Work for transport level bridge that doesn"t need to understand full GIOP/IIOP protocol. Requirements: interoperability across network that doesn"t share commom transport protocol
accomodated by "NeedAddressingInfo" change
Summary: Is there a standard by which you can identify whether incoming IOR is for an object reference in our ORB or not? Opaque object key could have same encoding in another ORB...Confusion
closed with no revision required
Summary: Callbacks in IIOP are to be implemented by getting the server to connect back to client and act as a client itself. If this could be changed it would really help from firewall perspective.
closed with no revision required
Summary: The C++ mapping uses a Bounds exception in the PIDL for NVList (page 17-6). This is the first time that the Bounds exception is mentioned (as far as I can see). There is no exception declaration for Bounds in the PIDL. This raises the questions:
1) Does Bounds have data members or not?
2) At what scope should Bounds be defined?
Given that the Bounds exception is also used by the
Request interface, I suspect what is meant is CORBA::Bounds.
The TypeCode interface also uses a Bounds exception. It is explicitly
declared in the scope of the TypeCode interface (page 17-15):
It would be nice to only have one of these, probably CORBA::Bounds, and
to add the missing declaration.
resolved, close issue
Summary: A variable-length in parameter is read-only in the
server, and a variable-length out parameter or return value is read-only
in the client. I believe the restriction is too harsh to be useful, and the optimization
permitted by the restriction is not worth it.
Clarifying text added, fixed
Summary: The C++ mapping states that "wchar" is not required map onto a
unique C++ type. Yet in 18.17.4, the mapping fails to define the
from_wchar and to_wchar struct types and associated <<= and >>=
operators for inserting and extract wide chars into anys. This
also needs to be fixed in appendix A.6 of section 18.
No Data Available
Summary: According to C++ mapping spec in the POA document (table 2, section 16.18.1) the signature for an object reference in argument should be "objref_ptr", not the more likely "const objref_ptr". this is an conflict with the convention for all other in args except numeric, and is in contrast with the table 3, that specifies "const objref_var&".
Duplicate of issue 188 - closed
Summary: Most ORBs provide overloaded operators to inject String_var values into ostream, istream, on ifstream. Problem: C++ does not make these operators mandatory, so every time I use one of them, I am writing non-portable and proprietary code. Nail those operators down and make them mandatory in the spec
Fixed, requirements added
Summary: There is no statement about the terminating zero value. Is room allocated for it or not?For symmetrie with string_alloc() I suggest that wstring_alloc() also should allocate more room.
Fixed with issue 722
Summary: When this IDL is mapped into C++ for a non-EH target compiler, won"t this method end up having 2 environment parameters?. This is only IDL in current spec that takes environment parameter
Duplicate of issue 191 - closed
Summary: If C++ compiler doesn"t support namespaces or templates defined inside classes, POA_*_tie classes in 18.1.4 cannot be supported within specified scopes.
resolved, close issue
Summary: CORBA::Boolean can be mapped to totally non-sensical things such as structs, class, type double, type long etc. There are no guarantees about size of underlying type given to implementor
resolved, close issue
Summary: There are some serious inconsistencies in the union mapping. Spec. (page 16-18, para4 and page 16-19, para 1) The 2 paragraphs appear to be in conflict with each other.
Fixed as suggested by submitter
Summary: Section states that _this() can implicitly activate servant if IMPLICIT_ACTIVATION applies. _this() does not have a way to specify which POA is to be used for the activation
resolved, close issue
Summary: PortableServer::ObjectId_to_wstring() and string_to_ObjectId() are written (*in section 18.4) using the "wchar_t" type. Shouldn"t they use the CORBA::wchar type instead?
Fixed in CORBA 2.2 editing process
Summary: The BOA interface defined a method called set_exception(). This is not present in the IDL in section 17.17. Does the BOA support this method or not?
clarified
Summary: The Object IDL contains a release() mmethod that is not mapped in the C++ mapping. This method should be added in the mapping
clarified
Summary: There is no wstring_dup(). For symmetrie with string_dup(), I would suggest to create wstring_dup() as well
closed issue, fixed
Summary: The C++ mapping basically ignores bounded strings and maps them to char* What should happen if I assign a string that is too long to a bounded string? No statement is made
resolved, close issue
Summary: Section 16.3.4: Question on how to use _narrow with C++ bindings. Should D::_narrow work? Does answer depend on interpretation of "actual (run-time) type"?
fixed, close issue
Summary: A_var may be identical to A_ptr, so a conforming program cannot overload operations using these types solely. This may clash with statement of different behaviour between the two.
fixed
Summary: Return value of maximum() for unbounded sequences must be specified.
resolved, close issue
Summary: Sec 16.11 Pg 16-23 CORBA2.0 p. 39, Sec. 3.13 para 15 Why are you passing string buffers as char ** and object references as T_ptr*. There already is a type used for overloading assignment.
Addressed by resolution to issue 75
Summary: Sec 16.11 Pg 16-23 CORBA2.0 p.38,sec 3.13 para 13 There is no auto extend, no inset,append, delete. It doesn"t seem like a sequence. Seems more like a resizable array. Could call it so.
Beyond scope of RTF - closed
Summary: get principal() needs an Environment parameter, but object implementations using C++ EH do not have them. Spec should clarify this.
resolved, close issue
Summary: The spec does not define how anonymous types defined within constructed types should be named (as the C mapping does)
Duplicate of issue 52
Summary: "Default constructor for a bounded sequence always allocates a contents vector.."-> Bad effect for sequences such as CORBA::ReferenceDatawhich allocates 1024 octets of storage
resolved, close issue
Summary: Section 16.14.5-implies that a CORBA::Object reference extracted from Any must share memory with actual interface stored in Any.Better: results of Any::to_object require explicit release()
resolved, close issue
Summary: [Sec 16.9 Pg 16-15 CORBA2.0 p. 32, Sec. 3.11 A comment nothing can be done about at thisstage. This section is way too complex. Goal is not to be natural C++ programmers !!!!
Beyond scope of RTF - closed
Summary: Implementation dependent: Type of string & object reference members of struct, union, sequence
Withdrawn by submitter
Summary: Sec 16.11 Pg 16-22 CORBA2.0 If release is FALSE under these circumstances, old storage will not be freed before reallocation is performed. After realloc release TRUE or FALSE?
Addressed by resolution to issue 75
Summary: {sec 16.11 Pg 16-22 CORBA2.0 p.38, Sec 3.13 para 7: Must an implementation REALLY implement a sequence as a contigous chunk of memory?
Addressed by resolution to issue 75
Summary: Sec 16.11 Pg 16-23 CORBA2.0 What happens to refs returned by operator[] when a realloc occurs? Are these invalid?
clarified
Summary: Sec 16.11 Pg 16-22 CORBA2.0 p.38 Section 3.13 para11: It"s not clear how maximum()call is supposed to be used.
Duplicate of issue 185 - closed
Summary: Sec 16.8 Pg 16-22 CORBA2.0, p. 28, Section 3.10, para 2: Devastating to programmers. Simple change to IDL an IDL file will require a complete rewrite of application code
Duplicate of issue123
Summary: Implementation dependent: Implementation scheme for Interface _var & _ptr types
Duplicate of issue189
Summary: Does the Any string extractor (>>=) return a pointer that is still managed by the Any or a copy? The spec appears to be silent about this.
Clarifying text added
Summary: It would be useful if the C++ mapping for IDL arrays also generated a T_copy() function to go along with T_alloc(), T_dup(), and T_free().
Fixed as suggested by submitter
Summary: the spec doesn"t say what the type CORBA::WChar should map to. Presumably,
it should be wchar_t? If so, I think this should be stated.
It is important to nail this down because of overloading ambiguities. For
example, if CORBA::WChar * is allowed to be the same as char *, then
we cannot use the overloaded <<= operator to insert unbounded wide strings
into an Any.
Fix the mapping to specify what WChar maps to.
Summary: orbos/98-01-11 contains some stale references. For example, on page 20-18:
...
private:
// hidden assignment operators for var types to
// fulfill the fules specified in
// Section 19.3.2
};
The definition for the A_out type is the same as the one shown
in Section 19.3.6.
These should now refer to Section 20.
Close without change. Already fixed.
Summary: According to the IIOP protocol specification, it is possible to receive
an any with a TypeCode which doesn"t include names, member names and
repository ids.
However, it is not clear what the behaviour of the >>= operator is in the C++
mapping for these cases. What happens if I receive an any value from
a remote ORB which didn"t encode names, member names and repository ids ? Is
it posible to extract its value using the so-called "type-safe" operator >>= ?
closed with no change
Summary: On page 82 in 98-09-03 (Nov 6 1998), the sample code for a boxed
struct is using the type "BoxedS" where "S" should be used.
Specifically, the _value() and _boxed_XXX() functions.
Modify the sample code as indicated.
Summary: I recently encountered an issue regarding the assignment of
Object_vars (shorthand for any object reference _var) to object
reference members. While the spec explicitly forbids implicit widening
when assigning Object_vars, it does not explicitly forbid it when
assigning object reference members.
Clarify the text
Summary: In 98-09-03, SystemException has a pure virtual _raise() member
(Section 20.18). That member is not shown in Section 20.40.8.
Also, I think UserException also should have the pure virtual _raise()
member, but neither the text in Section 20.18 nor the summary in
Section 20.40.9 shows it.
Close as duplicate of 1923.
Summary: The CORBA 2.2 C++ binding has the SystemException class defined as a
concrete class, because it redefines _raise() as a non-pure virtual.
This seems to be a bad idea to me. It would be better to leave _raise()
as a pure virtual so that SystemException cannot be instantiated. This
prevents accidental programming errors in catching SystemExceptions by
value, which slices off the real exception type.
Add pure virtual _raise functions to CORBA::SystemException and CORBA::UserException.
Summary: Section 20.36.1, page 20-118 of orbos/98-07-12 says:
"Similarly, data allocated by the DIR and handed to the ORB (the NVList
parameters, the result value, and exception values) are freed by the ORB
rather
than by the DIR."
However, the signatures for the set_result() and set_exception() functions of
ServerRequest take arguments of type const Any&. How can the ORB adopt the
result and exception data from a const Any? Unless I am missing something,
either these signatures have to be changed to Any&, or the quoted sentence has
to change to remove the text "the result value, and exception values".
Change the text as suggested.
Summary: Are you looking at CORBA 2.2, document orbos/98-02-01?
Section 20.31.4 covers ORB_init and friends. The POA is an ordinary IDL
interface that just follows the ordinary C++ mapping rules, so it needs no
special mention. The C++ server side is explained in 20.33 through 20.38.
You are correct that resolve_initial_references is missing from the ORB
interface. This was because it used to be covered in another section, and
it appears to have been inadvertantly dropped by the editors at the OMG.
Juergen, this should be logged as a cxx_revision issue. However,
resolve_initial_references just follows the regular C++ mapping rules, so
there"s really no harm in it being missing.
Add the missing text.
Summary: The C++ language mapping for ValueBase is missing return
values on _add_ref and _remove_ref.
Fix the code.
Summary: The C++ mapping requires that strings are to be mapped to char *.
Unfortunately, with ANSI C++ compilers, this creates problems if
string literals are involved.
Close no change. This issue is already addressed in the CORBA 2.3 specification
Summary: The C++ mapping requires that attempt to insert a Boolean, Octet, or
Char value into an any must generate a compile-time error:
CORBA::Any a;
CORBA::Char c = "x";
a <<= c; // Compile-time error
The spec says nothing about WChar and WChar *. This implies that no such
guarantee exists. However, I don"t think it would hurt to spell this out:
CORBA::Any a;
CORBA::WChar wc = L"x";
a <<= wc; // Undefined behavior
closed, fixed
Summary:
In 20.9.2, the T_out class has a copy constructor and assignment
operator that take non-const references to a T_out argument. These
should be changed to const references instead because the T_out class
still works correctly with the change, and many compilers issue errors
or warnings about non-const references arguments bound to temporary
values.
fixed, issue closed
Summary: The latest C++ mapping (document orbos/98-05-08) defines the
Any::from_string type as
struct from_string {
from_string(char* s, ULong b, Boolean nocopy = FALSE) : val(s),
bound(b) {}
...
};
In ANSI C++, this disallows the following code:
any <<= Any::from_string("string literal");
This is because string literals in ANSI C++ are const char[], not char[].
Therefore, from_string should have an additional constructor to allow
insertion of a const char* as well.
Close as duplicate of 2453.
Summary: The mapping for Any currently requires:
Any(TypeCode_ptr tc, void *value, Boolean release = FALSE);
void replace(TypeCode_ptr tc, void *value, Boolean release = FALSE);
const void *value() const;
The meaning of the void * parameters is never defined (and cannot ever
be defined because it would have to mandate a particular binary layout).
This means these three functions have completely undefined semantics. Even
for basic types, such as CORBA::Long, I cannot assume that the void *
will point directly at the long value, because the mapping implementation
is free to make the pointer point at some other value internal to an Any.
Proposal: Remove these three functions from the mapping. If vendors want
to retain them for backward compatibility reasons, they can.
However, functions with completely undefined semantics that are
inherently non-portable have no place in a standard mapping.
Leave the original text in place. Add a sentence saying that DynAny should be used instead.
Summary: I believe the spec should be updated to explicitly require the following
to be safe: a1.replace(a1.type(), a1.value(), false);
In other words, an Any should be obliged to detect assignment to self
for the passed void *. Reason: The above is the only way I can see
to get a tk_alias type code into an any, so the receiver can tell the
difference between a date and an address.
Close issue with no change – already resolved in section 20.16.8.
Summary: The C++ mapping currently lack mappings for is_a(), is_equivalent(),
hash(), and non_existent(). These need to be added. The question is, which of these operations can validly be invoked on
a nil reference, because that affects the mapping. My thinking is that
all of these should be allowed for nil references.
closed with no change
Summary: The mapping shows the signature for the _narrow static member
functions in exceptions as
static SystemException * _narrow(Exception *);
I think we should change this to
static SystemException * _narrow(const Exception *);
Otherwise, I cannot catch an exception as const and then narrow it
without a cast.
No Data Available
Summary: In coordination with the proposed resolution to the ORB Portability RTF
Issue #752, add the following operations to PortableServer::ServantBase
in section 20.34.1:
class ServantBase
{ ... public: ... virtual InterfaceDef_ptr _get_interface() throw(SystemException); virtual Boolean _is_a(const char * logical_type_id) throw(SystemException); virtual Boolean _non_existent() throw(SystemException); ... };
and change the last paragraph of section 20.34.1 to:
The default implementation of the _default_POA() function provided by
ServantBase returns an object reference to the root POA of the default
ORB in this process the same as the return value of an invocation of
ORB::resolve_initial_references("RootPOA") on the default ORB. Classes
derived from ServantBase can override this definition to return the POA
of their choice, if desired.
and add the following text at the end of section 20.34.1:
ServantBase provides default implementations of the _get_interface(),
_is_a(), and _non_existent() standard object reference operations that
can be overridden by the object implementation if the default behavior
is not adequate. These functions are called just like normal skeleton
operations by the POA, so the programmer can use _this() and and the
PortableServer::Current interface in the function bodies.
The default implementation of the _get_interface() and _is_a() functions
provided by ServantBase uses the interface associated with the skeleton
class if it is static to determine its return value. If the skeleton is
dynamic (see 20.36) it uses the _primary_interface() function to
determine its return value.
The default implementation of the _non_existent() function simply
returns false.
:ServantBase
Summary: There is no text in the C++ language mapping that describes how to map a
fixed point constant declaration.
No Data Available
Summary: Type Fixed has constructors for LongDouble and int. This causes
a few initialization problems. For example:
Fixed<8,2> x = 6.75;
Fixed<8,2> y = 10L;
Fixed<8,2> z = 10U;
None of these will compile because of the ambiguity as to whether to use
the int or the LongDouble constructor.
I think Fixed will need additional constructors to allow initialization
from float, double, long and unsigned values.
Summary: Page 20-34 of CORBA 2.2 shows member functions of the Fixed template:
CORBA::UShort fixed_digits() const;
CORBA::Short fixed_scale() const;
There are no semantics specified for these. I assume they return the
number of the respective digits passed to the template? For example, given
Fixed<5,2> x;
assert(x.fixed_digits() == 5);
assert(x.fixed_scale() == 2);
Is this the correct interpretation? If so, the spec should say so (otherwise,
I might, for example, expect that fixed_digits returns 3 and fixed_scale
return 2).
No Data Available
Summary: Add the following operation to CORBA::Any:
class Any
{ ... void type(TypeCode_ptr); ... };
This will replace the internal typecode in the any with the specified
typecode. If the new typecode is not equivalent to the old typecode (as
defined by TypeCode::equivalent), then implementation will raise the
BAD_TYPECODE system exception.
No Data Available
Summary: There doesn"t appear to be any way to place an arbitrary exception into
an Any with the current C++ mapping. This is necessary to make the DSI
usefulThe spec needs to be extended to provide an inserter function to insert
a CORBA::Exception into an Any. I know that this has potential issue
for the inserter function to determine the correct typecode for the
exception, but I can"t think of any other way to get an exception into
the Any when all I"ve got is a CORBA::Exception * without having to
enumerate each possible exception by calling _narrow.
No Data Available
Summary: The fixed mapping says on page 20-35 of orbos/98-01-11:
One way to do this is to declare the result types with a macro
that evaluates to the approate values, based on the digits and
scale of the operands:
// Example of Fixed result type declaraction
// Fixed<_FIXED_ADD_TYPE(d1,s1,d2,s2)> -> Fixed<dr,sr>
I think the name of the macro for each rule needs to be nailed down.
No Data Available
Summary: page 20-34 of orbos/98-01-11 contains a few typos:
1)
template<CORBA::UShort d, Short s>
should be
template<CORBA::UShort d, CORBA::Short s>
2)
operator LongDouble() const;
should be
operator CORBA::LongDouble() const;
3)
template<unsigned short d1, short s1, unsigned short d2, short s2)
should use CORBA types and use a closing ">" instead of ")":
template<
CORBA::UShort d1,
CORBA::Short s1,
CORBA::UShort d2,
CORBA::Short s2
> // Note closing ">"
No Data Available
Summary: On page 20-36, near the top, the mapping says:
A T_out type for a Fixed type is defined as typedef to a
reference to the Fixed type, with the digits and scale added to
the name to disambiguate it. For example, the name of the T_out
type for the type Fixed<5,2> is Fixed_5_2_out:
// C++
typedef Fixed<5, 2>& Fixed_5_2_out;
This doesn"t appear to work for fixed types with negative scale. For example:
No Data Available
Summary: In section 5.6:
// PIDL
module CORBA {
interface ORB {
exception InvalidName {};
};
};
In section A.24:
// C++
class ORB {
public:
class InvalidName
;
};
The C++ mapping should be clarified to show that this is indeed a user
exception.
No Data Available
Summary: 3) Page 20-35: the +=, -=, *=, and /= operators are required by the
C++ language to be member functions, not global functions. They
should be moved into the Fixed class and should return a reference to
*this, not a value.
No Data Available
Summary: 2) Page 20-35: the semantics of the istream extraction and ostream
insertion functions are totally unspecified – what formats are used
to read and write Fixed types?
No Data Available
Summary: orbos/98-01-11 contains a typo on page 20-20.
The last line of Table 19-1 shows CORBA::Octet in the "C++ Out Type"
column. This should be CORBA::Octet_out instead.
No Data Available
Summary: Page 20-74, para 1:
... original specified except the first oneA caller is ...
Should be
... original specified except the first one. A caller is ...
No Data Available
Summary: 1) Page 20-34: the unary + and - operators in the Fixed class should
return by value, not by reference.
No Data Available
Summary: 1. If the C++ target environment does not support namespaces and/or
nested template class definitions, then it is impossible to implement
the Fixed template type as part of the CORBA module.
No Data Available
Summary: orbos/98-01-11 doesn"t initialize string members if they are inside
a sequence or array.
For consistency, it would be better to adopt the following:
No Data Available
Summary: At present sequence elements can only be accessed through operator[]. Public accessors be provided to allow a sequence to simultaneously be viewed as alinked list.
Duplicate of issue 75 - closed
Summary: Binding spec states that implementation af Any must not store its value as reference or pointer to value passed into insertion operator <<= Any return pointer must not be NULL pointer...
clarifying text added
Summary: Sec 16.12.2 Pg 16-27 CORBA2.0 Sun wants to add para.: Extraction operator>>= doesn"t free old storage, doesn"t pass old string to string_free, doesn"t invoke release on old object reference.
Clarifying text added
Summary: Sec 16.2.1 Pg 16-4 CORBA2.0 A_ptr and A_var need not be distinct. Since these types have distinct semantics, they need to be distinct (Section 3.5.1 para 4)
Duplicate of issue 189 - closed
Summary: C++ mapping currently specifies that the default constructor for CORBA::String_var initializes the string to NULL Pointer. This is very inconvenient, in particular for structures
Fixed as suggested by submitter
Summary: Copying + adopting performed by String_var::operator= are very error-prone.Better to have explicit functions to copy, adopt,reference.(e.g void String_var::copy(const char*);
handled by Portability submission - closed
Summary: Sec 4.10 describes mapping for TypeCode. Sun proposes the following typecode interpreter interface: (available in /archives/issues/issue261)
Fixed with issue 251
Summary: Sec 3.16.2 para 11 describes lifetime of inserted value. Any should take over the inserted value(Sun) Avoids unnecessary copy for structured types listed in table 2
requested functionality added
Summary: We sure could use any_to/from_string<nnn> classes so that the type safe any api could be used for all IDL types
Requested functionality added
Summary: ptr and var types for objrefs should be nested inside interface class, e.g A::ptr and A::var. Would make writing templates using these types easier.
resolved, close issue
Summary: Pg 16-46 table 24 CORBA2.0 Shouldn"t arrays be by & for inout? This looks like a typo.
clarified
Summary: Sec 16.11.2 Pg 16-25 CORBA2.0 How do I know how sequence was created. Must my code carry arround an extra piece of information saying how sequence was created?
clarified
Summary: Sec 3.13.describes mapping for sequence.Accessor functions should be provided for release flag.Add following member functions: void release(Boolean), Boolean release() --pure accessors
Duplicate of issue 75 - closed
Summary: As a convenience for managing this pointer, the mapping also provides another class of each variable-length type. It also provides one for fixed-length types. You should say so
clarified
Summary: It seems that the TypeCode mapping needs to be updated to reflect the TypeCode definition in Interface Repository Spec (p 64)
TypeCode interface updated
Summary: The interface between application programmer and CORBA components (BOA, stubs, skeletons etc.) should be as simple as possible (but, naturally, not more simple). I am afraid, that introduction of the new classes to C++ mapping like A_out is not the best way to simplify their life to the creators of the final applications - the application programmers. It is naturally, when creator of the CORBA implementation use very advanced and sophisticated constructions of the programming language, but let he/she left application creators their invention to study application problems, not those advanced features of the programming environment. How many application programmers understand well such construction like "reference to pointer"?
Naturally, if the new constructions would bring some new principal features to the problem, they may be accepted, but I am afraid, that the only reason of the A_out class is to ensure freeing of memory occupied by the old data of the corresponding variables. But the same service may be done by the first statement of the (generated) stub.
Close no change. This change is too intrusive and would break too much existing code.
Summary: During my study of the specification CORBA 2.2, I tried to transfer C++ codes on pages 20-12, 20-13 and 20-11 to the C++ source, add some dummy declarations and definitions of such classes as Object and tried to compile it. I obtained error message from the definition of the constructor A_out::A_out(A_var& p) : ptr_(p.ptr_) ... due to unauthorized access to protected member A_var::ptr_. This was no conceptual problem to introduce access function A_var::ptr() in similar manner like has been introduces function A_out::ptr() and correct the problem, another way is definition of some classes as friend ... . But my reliance to document containing such mistakes was lost. Please, can you pay more attention to testing and preparing of the concluding documents?
Closed without change
Summary: 1. ORB pidl on 20-130 of ptc/98-09-03 is missing the create_policy
pseudo-operation.
2. Sometimes I think the traditional style of PIDL mapping used for the Java,
C++, and draft Lisp mappings, wherein each PIDL pseudo-operation is
explicitly listed in each mapping, is risky - insofar as version
mismatches between the Core Pseudo-IDL and the pseudo-IDL used in the
mapping document can and frequently do arise.
Add the missing operation.
Summary: We would like to see an enhancement which allows access to sequence buffers once they have been constructed.
Fixed
Summary: Several problems exist with the definition of union constructors.
fixed by adding clarifying text
Summary: The inserter helper functions for string and wstring on type Any should
have const pointers as the constructor parameter, otherwise I can"t
insert string literals with an ANSI C++ compiler.
Make the suggested fixes.
Summary: The last para of section 20.1.2 says:
To avoid C++ compilation problems, every use in OMG IDL of a
C++ keyword as an identifier is mapped into the same name preceded
by the prefix "cxx". For example, an IDL interface named
"try" would be named "_cxx_try" when its name is mapped into C++.
This is ambiguous because it doesn"t make it clear what the names of types
derived from that interface shold be.
Clarify the text.
Summary: the mapping currently specifies that for char * and WChar *, the following
extraction operators must be defined on type Any:
class Any
{ Boolean operator>>=(const Any &, char * &); Boolean operator>>=(const Any &, WChar * &); // ... };
For user-defined complex types and other variable-length types, the mapping
requires:
class Any
{ Boolean operator>>=(const Any &, T * &); // ... };
This means that a conforming ORB need not compile the following:
CORBA::Any a = ...;
const char * p;
a >>= p; // No matching operator
This is a Bad Thing (TM), in my opinion. The reason is that when I extract
something by pointer, first, the Any retains ownership and, second,
I must treat the pointed-to memory as read-only.
fixed, issue closed
Summary: The C++ language mapping generates typecode names for global IDL type
definitions that start with an underscore. The C++ standard reserves
global symbols that start with an underscore for the compiler
implementation. We need to resolve this conflict.
Close with no change
Summary: the text for string_alloc et al. says:
The string_alloc function dynamically allocates a string,
or returns a null pointer if it cannot perform the allocation.
[ ... ]
The string_alloc, string_dup, and string_free functions may not
throw CORBA exceptions.
I think the second sentence is a little misleading. What is meant is that
these functions cannot throw any exceptions at, not that they won"t throw
CORBA excecptions but are allowed to throw others, such as bad_alloc.
I suggest to change the second sentence to read:
The string_alloc, string_dup, and string_free functions may not
throw exceptions.
Clarify the text.
Summary: The allocbuf function allocates a vector of T elements that can be
passed to the T
*data constructor and to the replace() member function. The length of
the vector
is given by the nelems function argument. The allocbuf function
initializes each
element using its default constructor, except for strings and wide
strings, which are
initialized to null pointers, and object references, which are
initialized to suitably-typed
nil object references. A null pointer is returned if allocbuf for some
reason
cannot allocate the requested vector.
Since in the latest mapping the elements of string sequences are now
initialized as empty strings, wouldn"t it be more logical if allocbuf
would also initialize the elements of the returned string vector with
empty strings instead of null pointers?
closed
Summary: The CORBA::Exception::_raise() virtual member function should have the
const qualifier. Since it effectively throws a copy of the exception,
there isn"t any reason why you shouldn"t be able to call it on a const
Exception.
Make _raise a const member function.
Summary: In ptc/98-08-03 p.20-80:
For all the integer types, boolean, octet, char, wchar and
enumerated types, value box classes provide.
1. The phrase "integer types" should presumably read "integer types except for
fixed" in view of the separate mapping for fixed type on p. 20-85. It
is true that "integer type" can mean signed_int or unsigned_int, in
contexts such as Corba 2.3a grammar, but the phrase here seems
potentially ambigous.
2. The phrase should be extended to include floating point types
(including float, double, and long double).
Clarify the text.
Summary: the 1.4 version of the C++ mapping has an internal inconsistency. In
sections 20.16.2 and 20.16.3, the inserters and extractors for built-in
types that don"t require a from_* or to_* helper class are shown
as non-member functions of type Any.
However, section 20.39.5 shows the the inserters and extractors as
member functions of type Any.
Section 20.39.5 is wrong and needs be updated to reflect the signatures
in 20.16.
closed issue
Summary: ptc/98-09-03, p. 20-96: In "The C++ mappings for the IDL
CORBA::CustomerMarshal..." change Customer to Custom.
Fix the typo.
Summary: Issue: The CORBA2.3 C++ mapping for the TypeCode class
(section 20.31.2) has not been updated.
Suggested Resolution: Add get_compact_typecode() and valuetype/
valuebox operations. Also, remove the param_count and parameter
methods which were deprecated in CORBA2.2 and eliminated in
CORBA2.3.
This issue has already been resolved.
Summary: Does the standard require an implementation to use C++ classes for modules if there is no namespace support? Or is it simply a suggestion?
clarified
Summary: If no operator *() is defined for struct, union, or sequence _var types, some pieces of code will break.
withdrawn by submitter
Summary: Is it intended that use of T__alloc functions are the only conformant way to allocate values of (variable length) type T? Or can a conformant app also declare them on the stack?
clarified
Summary: Is a modifier function required under the C++ mapping of unions, and if it is, can it be used to set the discriminator to an illegal value?
clarified
Summary: To be compliant, does a client have to pass a string_alloc"ed string to a CORBA operation that takes an in string parameter? If so, why should the ORB care how the client created storage?
clarified
Summary: The spec is silent about whether to generate Any inserter and extractor (<<= and >>=) functions for exceptions, although they appear necessary for properly storing and manipulating exceptions.
added clarifying texed, fixed
Summary: Is this legal: union X switch(boolean)
{case TRUE: short a; case FALSE: long b;default: double c;};? If no, why? If yes, what does _d() return if the union was set with the c() access function?
fixed
The CORBA 2.3 C++ spec says (1.11):
"The Fixed(char*) constructor converts a string representation of a
fixed-point literal into a real fixed-point value, with the trailing 'd'
or 'D' optional."
However, the CORBA 2.3 spec for a fixed point literal says (3.2.5.5):
"A fixed-point decimal literal consists of an integer part, a decimal
point, a fraction part and a d or D. The integer and fraction parts both
consist of a sequence of decimal (base 10) digits. Either the integer
part or the fraction part (but not both) may be missing; the decimal
point (but not the letter d (or D)) may be missing."
This means that the following call is illegal:
CORBA::Fixed f("-1.0");
Even though this can be rewritten (legally) as:
CORBA::Fixed f(-CORBA::Fixed("1.0"));
I think it would be a good idea change the definition of the constructor
to also allow an optional sign (+ or -).
closed/resolved
The code example has a "ServantBaseBase_var".
closed, editorial fix
Summary: - The factories" names in the example IDL on page 1-88 are incomplete
Close as duplicate of 2354.
Issue 1776 was supposed to change all T_out classes so that their copy
constructor and assignment operators took a "const T_out &". The _out
class in 1.3.6 didn't get updated with this change.
closed/resolved
Sections 1.32.2 and 1.41.20 have TypeCode::type_modifier() returning a
ValuetypeModifier. It should be ValueModifier instead.
–
editorial fix...isssue closed
Summary: 2. Should it be legal to assign a null pointer to a string member of a
struct, sequence, array or exception?
closed/resolved
Summary: 1. What is the contents of a string member of a struct, sequence, array
or exception after out() or _retn() has been called? Is it a null
pointer, or an empty string?
I think that for best consistency, it should be an empty string, which
is the same state after default construction.
closed/resolved
Summary: CORBA 2.3 added the requirement (1.7 & 1.8) that string extractor
operators be defined for String_var & string member classes, for
example:
std::istream& operator >>(std::istream &, CORBA::String_var &);
However, the semantics of the extractor operations is undefined. Does
the extractor operator extract characters until the first whitespace?
until a newline? until the default width of the stream? until eof?
The same applies to wide strings.
closed/resolved
The constructors for CORBA::Exception, CORBA::SystemException and
CORBA::UserException should be protected, not public, since there is no
reason for a direct instance of these classes ever to be instantiated.
Close no change. Base exception classes are abstract, so this change is not necessary.
Summary: There is no reason that the _raise() function for CORBA::Exception
should not be const. We should change it"s signature to:
class Exception
{ public: ... void _raise() const = 0; ... };
Close no change. This issue is already addressed in the CORBA 2.3 specification.
Summary:
The mapping for string members has modifier functions for "char *",
"const char *", and "String_var". Shouldn"t there also be a modifier
function that takes the unnamed struct string member and array string
member types?
closed/resolved
Some of the unary operators for the Fixed class have the wrong return
type:
Close no change. This issue is already addressed in the CORBA 2.3 specification.
1. The resolution that we seemed to be converging on for issue 674
allows programmers to inherit servant implementations like this:
// IDL
interface A {
};
interface B : A {
};
// C++
class MyA : public virtual POA_A {
};
class MyB : public virtual POA_B, public virtual MyA {
};
However, this paradigm breaks when using abstract interfaces:
// IDL
abstract interface A {
};
interface B : A {
};
since the spec does not require a POA skeleton be generated for A.
I think we should change the spec to state that POA skeletons for
abstract interfaces are generated, but that these skeletons do not
inherit from ServantBase, and do not contain a _this() member function.
This will allow inheritence of implementations, even for abstract
interfaces.
I considered just having POA_B just inherit directly from the abstract
class A, but that would allow POA_B skeletons to be widened implicitly
to an abstract interface pointer (for implementations which define A_ptr
as A *), and that seems to be too trouble prone. If someone can think
of a way to do this and prevent implicit widening, then this would be
better, since it would even allow sharing of implementation between a
servant and a valutype that both inherit from the same abstract
interface.
resolved/closed
In formal/99-07-41 section 1.28 "NamedValue" it says "NamedValue is used
only as an element of NVList, especially in the DII." but this is not
correct. Note the remark in section 1.33.3 "Differences from C-PIDL" which
describes other uses: "Added create_named_value, which is required for
creating NamedValue objects to be used as return value parameters for the
Object::create_request operation."
editorial fix, issue closed
4. Is there any merit in adding narrow operations to AbstractBase that
would allow the programmer to narrow to ValueBase or Object_ptr?
closed/resolved
"Both interfaces that are derived from one or more abstract interfaces,
and valuetypes that support one or more abstract interfaces support
implicit widening to the _ptr type for each abstract interface base
class. Specifically, the T* for valuetype T and the T_ptr type for
interface type T support implicit widening to the Base_ptr type for
abstract interface type Base. The only exception to this rule is for
valuetypes that directly or indirectly support one or more regular
interface types (see Section 1.17.9, Valuetype Inheritance, on page
1-83). In these cases, it is the object reference for the valuetype, not
the pointer to the valuetype, that supports widening to the abstract
interface base."
This seems to prohibit widening from a valuetype pointer to an abstract
interface _ptr if the valuetype happens to support a normal interface.
I don't understand the restriction. This seems to prohibit the
programmer making a choice of using value or reference semantics in the
case of diamond inheritence of an abstract interface:
// IDL
abstract interface A {
};
interface I : A {
};
valuetype V1 : supports A {
};
valuetype V2 : supports I {
};
This means that I must always pass V2 valuetypes by reference to
operations expecting an A, and cannot choose to pass V2 valuetypes by
value instead. Why was this restriction added and what would be the
problem with relaxing it in this case?
see below
currently it is not possible to pull an exception out of an Any generically,
that is, I cannot write:
const CORBA::SystemException * sep;
CORBA::Any a;
// assume a contains a system exception...
a >>= sep;
Normally, I won't need this. However, it's come up as part of portable
interceptors. For example, I might want to write an interceptor that
logs things, including system exceptions. Now, if I have a system exception
in an Any, the only way to get it out is to successively try to extract
every possible system exception until I find one that works.
That's rather tedious. It would be nicer if I could extract a base
pointer to the actual exception, so I can print the minor number and
completion status.
I would like to suggest adding the following extraction operator:
Boolean operator>>=(const SystemException * &);
closed/resolved
Given that we have Any::to_object and Any::to_abstract_base, shouldn't
there be an Any::to_value_base as well?
closed/resolved
2. I do not understand this bullet in section 1.18.2:
"o Inserting an abstract interface reference into a CORBA::Any operates
polymorphically; either the object reference or valuetype to which the
abstract interface reference refers is what actually gets inserted into
the Any. Because abstract interfaces cannot actually be inserted into an
Any, there is no need for abstract interface extraction operators,
either. The CORBA::Any::to_abstract_base type allows the contents of an
Any to be extracted as an AbstractBase if the entity stored in the Any
is an object reference type or a valuetype directly or indirectly
derived from the AbstractBase base class. See Section 1.16.6, Widening
to Abstract Interface, on page 1-62 for details."
This seems to make no sense. It seems to state that the actual
reference or valuetype is inserted into the Any, which means that the
TCKind associated with the any will be tk_objref or tk_value, not
tk_abstract_interface. This seems to have particularly bad implications
with the DII & DSI. How does the DII know to encode an abstract
interface correctly in CDR if the Any it receives doesn't have a
tk_abstract_interface TypeCode? It also means that an application which
only knows the abstract interface type must handle the case where the
Any has a tk_objref or tk_value instead, use Any::to_abstract_interface
and then a narrow call to get the abstract interface pointer it needs.
This seems needlessly complex and unnecessary. This bullet should be
replaced with one that just states that abstract interfaces have
inserters and extractors generated for them just like normal interfaces.
closed/resolved
quite some time ago, we added the _var_type and _ptr_type definitions
to proxies to make it easier to write templates. Similarly, we have
the _whatever_seq typedefs for recursive structs and unions, to avoid
problems with anonymous types.
What's missing at the moment is a similar feature for _var types.
When I'm writing a template that does it's job in terms of _var types,
I also quite often want to do something to the underlying target type
of the _var. However, I can't do that unless I pass in an extra template
parameter (which, in turn, doesn't always work if I also want to use
STL standard binders and such...)
So, why not add a typedef for the target type to every _var type?
No Data Available
The description of Any::to_abstract_base does not have any information
about its memory managment implications. It should have the equivalent
semantics to Any::to_object, and require the resulting reference to be
released by the caller.
closed/resolved
The CORBA 2.3 spec needs to make it clear that for dynamic
implementations, invocations of the standard object operations
(get_interface, is_a, non_existent) call the virtual functions defined
in PortableServer::ServantBase, and do not call
PortableServer::DynamicImplementation::invoke().
closed/resolved
Minor editorial issue:
In Section 1.9.2, "T_out Types":
class T_out {
public:
//...
T_out(const T_out& p) : ptr_(p.ptr_) {}
T_out& operator=(const T_out& p)
};
Note the missing "const" in 1.7. I suspect String_out should do the
same as T_out and pass const references.
closed/resolved
Name: Bruce McIntosh
Company: Boeing Australia
mailFrom: bruce.mcintosh@boeing.com
Notification: Yes
Specification: C++ Language Mapping
Section: 1.36.2
FormalNumber: ptc/01-06-07
Version: Proposed Available Revision
RevisionDate: 01/26/2002
Page: 1-136
The example given has a couple of small typographical problems: (1) the function signature specifies a void return type, but returns a Foo* (2) the function returns "foo_servant->this;" which I think should be "return foo_servant->_this();"
Perhaps the example should read:
Foo* some_function (/.../)
{ Servant_var<Foo_impl> foo_servant = new Foo_impl; foo_servant->do_something(); // might throw... some_poa->activate_object_with_id(...); return foo_servant->_this(); }Updated the example code as suggested
What should allocbuf() for a bounded sequence return if I ask for more
elements than the sequence bound? The spec doesn't say. I think it should
return null in this case.
Also, what should allocbuf() return if I ask for zero elements?
closed/resolved
The Fixed::round() and Fixed::truncate() functions do not mention what to
do if their scale argument is larger than the current scale. I figure they
shouldn't do anything – for example, "truncating" by making something have
more digits doesn't seem to make sense. I propose adding the sentence below
after the sentence reading "The round and truncate functions convert a
fixed value to a new value with the specified scale." (page 23-32 of
ptc/99-03-04):
If the new scale is equal to or larger than the new scale, no rounding or
truncation is performed and the result is equal to the target object.
closed/resolved
Althrough I report my issue as a C++ issue, actually it is a common issue for other languages also. In current CORBA standard, a activated CORBA Servant object in the POA is shared by all the clients. But in many applications, a client connects to the server and calls some CORBA object methods to create a lot of connection related CORBA objects. Normally, the client will call "destroy" method of these CORBA object to destroy them before existing. But if the client exists abnormally, these created CORBA object will never be destroyed and never be used by any client. We can call this kind of CORBA object as "floating" CORBA object. The CORBA server application runs longer, the "floating" CORBA objects becomes more. And eventually, these "floating" CORBA objects will consume all the memory resources/CPU resources, then the CORBA server crashes and has to be restarted. The "floating" CORBA objects problem at the server side is not easy to be solved. For this problem, if the CORBA standard provides a method to solve it, the CORBA server will run more robust. Actually, the underlying network connection broken can be detected very effectively and rapidly. The CORBA server just simply ignores the network connection lost event and does not pass it to activated CORBA object even if the CORBA object is connection related object because current CORBA standard thinks that all the CORBA objects in the server are shared to all clients. If the server can notify the network connection lost event to the connection related CORBA objects, the developper can do the clean job on it. A simple method can solve the "floating" CORBA object problem. It is not required to add any new interface or data structure to current orb.idl. It is just required to add some new language mapping methods at server side only. I will give an example in C++ to show this simple method. A IShared,IConnSpec and IOtherConnectionSpec interfaces are defined below: interface IOtherConnectionSpec
{ ... }interface IConnectionSpec
{ IOtherConnectionSpec someMethod(); }interface IShared
{ IConnectionSpec createConnSpec( in string param ); }; These interfaces will be used in this example. 1) the IShared will be shared by all the clients, it is activated like this: SharedImpl sharedImpl( ... ); ... sharedImpl._this(); 2) add new mapping method for the "POA_IShared::createConnSpec()" like this: IConnectionSpec_ptr POA_IShared::createConnSpec( char* param, const ConnectionContext& connCtx ); In this method, a parameter named ConnectionContext that represents the connection between the client and server is added. This method has a default implementation like this: IConnectionSpec_ptr POA_IShared::createConnSpec( const char* param, const ConnectionContext& connCtx )
{ //just ignore the connCtx like the current CORBA standard defines return createConnSpec( param ); }3) If the user wants to create a connection related object, he/she must overload the "IConnectionSpec_ptr createConnSpec( char* param, const ConnectionContext& connCtx )" method and active the object with "this_( const ConnectionContext& connCtx )" method: IConnectionSpec_ptr POA_IShared::createConnSpec( const char* param, const ConnectionContext& connCtx )
{ ... IConnectionSpec *connSpecImpl = new IConnectionSpec( ... ); ... //use the connection related active method return connSpecImpl->this_( connCtx ); }in this method, the user uses the "this_( const ConnectionContext& connCtx)" method instead of the old "this()"" method to active the CORBA object. This activated CORBA object becomes a connection related object instead of shared object. Note: User can use the "this_( const ConnectionContext& connCtx)" method to active a shared object also. At this time, the ConnectionContext is a global variable "NO_CONNECTION_CONTEXT". 4) add a new mapping method named "getConnectionContext()" for every CORBA object. const ConnectionContext& IShared::getConnectionContext(); const ConnectionContext& POA_IConnectionSpec::getConnectionContext(); In this way, the IConnectionSpec can create and activate any other connection related CORBA object like this: IOtherConnectionSpec_ptr POA_IConnectionSpec::someMethod()
{ ... OtherConnectionSpecImpl *otherConnSpecImpl = new OtherConnectionSpecImpl(...); ... return otherConnSpecImpl->this_( getConnectionContext() ); //or ? //return otherConnSpecImpl->this_( this ); }5) add a new mapping method named "connectionLost()" for every CORBA object. When the network connection is lost, the CORBA server should find all the CORBA object associated with this network connection and call their "connectionLost()" method. The "connectionLost()" and its default implementation is listed below: void POA_IConnectionSpec::connectionLost()
{ //just delete this connection related object simply delete this; } void POA_IOtherConnectionSpec::connectionLost() { //just delete this connection related object simply delete this; }Because the SharedImpl object that created in the 1) step does not assicate with any connection, its "connectionLost()" method will not be called for ever.
The second-to-last paragraph of section 1.17.10.3 says
"For valuetypes that have no operations or initializers, a concrete type-specific factory class is generated whose implementation of the create_for_unmarshal function simply constructs an instance of the OBV_ class for the valuetype using new and the default constructor."
As specified, that requires the generation of invalid C++. The OBV_ class is abstract since it does not have implementations of the ValueBase reference counting functions.
Perhaps the intention is that the OBV_ classes in such cases should derive from DefaultValueRefCountBase. However, the wording and explanation in section 1.17.6 explicitly forbids this:
"Note that it is the application-supplied concrete valuetype classes that must derive from these mix-in classes, not the valuetype classes generated by the IDL compiler."
One solution that avoids the problem, and avoids restricting the application's use of the OBV_ classes is to generate yet another class that derives from both the OBV_ class and DefaultValueRefCountBase, for instantiation by the _init class's create_for_unmarshal function.
1.9.1 says:
"The copy constructor deep-copies any data pointed to by the T_var constructor
parameter. This copy will be destroyed when the T_var is destroyed or when a new
value is assigned to it. Compliant implementations may, but are not required to, utilize
some form of reference counting to avoid such copies."
and
"The normal assignment operator deep-copies any data pointed to by the T_var
assignment parameter. This copy will be destroyed when the T_var is destroyed or
when a new value is assigned to it. Assigning a null pointer to a T_var is legal and
results in deallocation of the data pointed to by the T_var."
So my question is, is it legal to use ValueBase::_add_ref() and _remove_ref() instead of _copy_value() in this instance when T_var is representing a valuetype?
C++ programmers will often want to use strings as
object identifiers, the C++ mapping provides several conversion
functions that convert strings to ObjectId and vice-versa:"
The purpose is so the programmer can pick an arbitrary natural language
string and use it as an ObjectId, not so that the programmer can
generate a randomly unreadable string out of a binary ObjectId.
[...] the C++ mapping provides several conversion functions
that convert strings to ObjectId and viceversa:
[...]
If conversion of an ObjectId to a string would result in
illegal characters in the string (such as a NUL), the first two
functions throw the CORBA::BAD_PARAM exception.
The conversion algorithm is not specified, and the ORB is free to
choose whatever encoding it likes for its Object IDs. (Object IDs
in stringified form need not be moved across address spaces (or,
at least, not across ORB boundaries), so having a proprietary
encoding is perfectly OK.)
The ORB interface destroy() operation defined in the core CORBA 2.3 spec seems to be missing from the associated C++ language mapping.
Add the destroy operation to the ORB definition in 4.35.1 and 4.45.21
Summary: We recently added _ptr_type and _var_type typedefs into interface classes
to make writing templates for interface types easier. We should add the
same typedefs for valuetype classes.
Add the missing typedefs
Suppose we have:
typedef fixed<4,3> FT;
interface I
{ FT op(); };
Suppose the server does:
FT
I_impl::
op() throw(CORBA::SystemException)
There are lots more digits in the return value than what is expected by the
client. What should be returned to the client. The rounded value? The
truncated value?
Similarly, what if we have:
double d = 10000000;
return CORBA::Fixed(d);
Do we return 9.999 to the client (which is the best we can do in this case)?
Of course, it is the responsibility of the programmer to make sure that
nonsense such as the second case doesn't happen. But the spec has to say
what happens if it does happen 
Also, the first case will be very common – what should happen in this case?
The Object::get_domain_managers() operation is a transmissible operation
with CORBA 2.3. Does ServantBase need anything added to handle this or
is this managed internally by the ORB/POA?
Footnote 11 on page 1-48 of the 1.1 version of the C++ language mapping states that sequence _var classes don't have a const version of "operator []". The justification in the footnote is incorrect.
This footnote should be removed, and the operator provided, since it otherwise prevents accessing sequence members through a const reference to a sequence _var.
Since the Any constructor from type code, void* value and boolean release flag has been eliminated, there is no longer any portable way to create an OUT argument for a DII request, without also assigning a value to it.
I propose either a constructor from type code or changing the behavior of the type code set method to always succeed if the Any's TCKind is tk_null.
Just as we prohibited direct extraction from any any into a _var type
due to the perils of memory management problems, we ought to prohibit
extracting into _out types of variable sized structured types for the
same reason
The addition amounts to a set of typedefs that would facilitate template
programming, added to each C++ skeleton class created for an IDL interface,
and analogous to the typedefs that already exist in the mapping for the stub
side. Say we have an IDL file
module foo
{
interface bar {};
};
Then in generated code we're talking about something like:
namespace POA_foo
{
class bar
;
};
need an _unchecked_narrow static operation that is similar to the _narrow. It will take in an object pointer but unlike _narrow will not check for compatibility before creating a new object reference.
In IDL it gives:
// IDL
valuetype V
;
But it should be
// IDL
valuetype V
;
implementing support for wchar/wstring I ran into some potential
problems with the UTF-8 encoding for the IDL 'char' type.
Lets suppose we have a C++ server with a native single-byte code set
like ISO 8859-1.
The Code Set Conversion specification states that UTF-8 is the fallback
code set for 'char'.
-> a client could decide to send characters in UTF-8 encoding.
What happens on the server side with UTF-8 encoded characters that use
more than 1 byte and thus don't fit into the single byte character as
specified by the C++ mapping for IDL type 'char'?
the C++ mapping should explicitly list operator == and operator Unable to render embedded object: File (= in the examples and text. If it is not allowed to use ==/) not found.= the methods should be declared private
The spec defines: // C++ class Seq_var; class Seq
{ public: typedef Seq_var _var_type; // ... }; We propose to extend this to the following to make it possible to write more generic C++ code. // C++ class Seq_var; class Seq_out; class Seq
{ public: typedef Seq_var _var_type; typedef Seq_out _out_type: typedef ::CORBA::ULong _size_type; // ... };
In section 4.11 add to the example at the end Seq_out and a _out_type typedef
as in the revised text below.
The _size_type typedef will make it possible in the user code to differentiate
between the index of a sequence type and a user defined ULong value. To
section 4.15 add the sentence
To facilitate template-based programming, a nested public typedef _size_type is delivered as the type
representing the length of the sequence.
And to the sequence class examples in section 4.15 the following
typedef ULong _size_type;
I was looking at the OMG IDL to C++ mapping specification, specifically
page 123 and came across the below. It looks to me that their
implementation in the spec is NOT correct. Shouldn't the swap function
take the "tmp" Servant_var?
Servant_var& operator=(Servant* p)
{
if (_ptr != p)
return *this;
}
Servant_var&
operator=(const Servant_var& b)
{
if (_ptr != b._ptr)
return *this;
}
Update assignment operator as proposed
To really support template meta programming the valuetype classes should deliver a typedef _out_type besides the _ptr_type and _var_type which are proposed to be added as part of issue 1794
Add a _out_type typedef to the valuetype class
To really support template meta programming the inteface should deliver a typedef _out_type besides the already defined _ptr_type and _var_type
Add a _out_type typedef to the interface class
The C++ keywords in section 4.47 should be updated and extended with the addition of C++0x
Add the following keywords to the table on page 154 as part of section 4.47
In section 4.5.4 it says: Unlike _duplicate, the parameter to _narrow is a reference of an object of any interface type (Object_ptr). If the actual (runtime) type of the parameter object can be widened to the requested interface’s type, then _narrow will return a valid object reference; it should say (widened to narrowed) Unlike _duplicate, the parameter to _narrow is a reference of an object of any interface type (Object_ptr). If the actual (runtime) type of the parameter object can be narrowed to the requested interface’s type, then _narrow will return a valid object reference;
In section 4.5.4 change widened to narrowed
Section 1.31.3 says:
I would suggest to delete the entire bullet point. In particular, the notion
of allowing alternative data types as propery values for contexts doesn't
work because the receiver expects a sequence of strings with an even number
of elements; if anything but a string sequence is sent, the receiver
has no chance of unmarshaling it.
Remove bullet as suggested
The Object::get_policy returns a Policy in IDL, not a Policy_ptr, that is the C++ return value
Replace in 4.36.1 the text Policy_ptr to Policy
On page 1-119, the spec says the following about _create_request() and
_create_request2():
[...] the ORB requires:
Note all the "optional" remarks.
It's not clear what "optional" actually means. We have two cases for
these parameters:
Two questions:
Where this is particularly annoying is for the return value. (The
"result" parameter to _create_request()):
I can call ORB::create_named_value(), but what should
I do then?
CORBA::NamedValue_var result;
orb->create_named_value(result);
At this point, I have a NamedValue containing an Any with
tk_null (because that's what the Any default constructor
creates). However, to correctly indicate that the operation
I want to call has a void return type, I have to make a
NamedValue that contains an Any with tk_void. But, how do
I achieve that? I can't use one of the Any inserters to
turn the TypeCode in the Any into tk_void, and I can't
use the type() member of the Any because I can't change the
type of an Any if it isn't consistent with the TypeCode that's
already there...
Even worse, the NamedValue doesn't seem to make sense as
the return value at all. For one, it has a name attribute.
Second, the NamedValue contains a flags attribute.
It seems that the easiest way to fix the problem is to state that, if a
parameter isn't needed, this is indicated by an empty sequence for lists,
and by a nil reference for objects.
However, the problems around create_named_value() and appear to be more
serious. How should we fix those?
The June 99 version of the C++ mapping doesn't mention ORB::destroy().
It should.
The second version of _create_request() accepts two context lists:
void Object::_create_request(
Context_ptr ctx, // <===
const char * operation,
NVList_ptr arg_list,
NamedValue_ptr result,
ExceptionList_ptr,
ContextList_ptr, // <===
Request_out request,
Flags req_flags
);
The spec then says:
The ContextList differs from the Context in that the former supplies
only the context strings whose values are to be looked up and sent
with the request invocation (if applicable), while the latter
is where those values are obtained.
So, I think (but I'm not sure), this means to say that:
If that is the intended interpretation, it's very difficult to discern
from the words in the spec now. I think this needs clarification.
Questions:
Also, looking at the ContextList interface:
pseudo interface ContextList
{ readonly attribute unsigned long count; void add(in string ctxt); string item(in unsigned long index) raises(Bounds); void remove(in unsigned long index) raises(Bounds); };
There is no further documentation on this. Some questions:
This seems insanely complex.
Suggestion: We should
Or, we could drop support for IDL context altogether (but I suspect we
can't get away with that
with 2.3, we got rid of all the C/C++ pseudo code for the DII and replaced
it with IDL. Unfortunately, this has broken something in the C++ mapping...
In the 2.0 spec, we had:
pseudo interface ORB
{ typedef sequence<Request> RequestSeq; // ... };
With 2.3, we changed this to:
module CORBA
{ // ... typedef sequence<Request> RequestSeq; // ... };
Unfortunately, the C++ mapping still shows the (now incorrect) definition
from CORBA 2.0 in Section 1.33.1.
In addition, the C++ mapping shows in Section 1.33.2:
class ORB {
public:
class RequestSeq
;
// ...
};
But then, in Section 1.41.21:
class ORB
{ public: typedef sequence<Request_ptr> RequestSeq; // ... };
The latter definition isn't C++...
So, we have several issues here:
1) How can we fix the C++ mapping to be in line with the core?
I'm toying with the idea of saying that RequestSeq is defined
in the CORBA namespace, with a typedef for backward compatibility
in the ORB interface. But I'm not sure what will break with
this kind of aliasing (repository IDs might change unexpectedly?)
2) Section 1.41.21 should be changed to show legal C++.
3) Depending on the resolution to this issue, both 1.33.2 and
1.41.21 will probably need updating to reflect the resolution.
what should _default_POA() return if the default ORB was never initialized?
The spec doesn't say...
I have the following questions to IDL - C++ mapping CORBA 2.3 (concerning valueboxes).
Can somebody give me an answer?
1. I assume that valueboxes T as a special kind of valuetypes also
need in C++ the T_var and the T_out types and the T_out types will be
used in function signatures for IDL out-parameters. Is it true?
2. The mapping for strings and wstrings requires a definition of C++
operators << and >> to allow a use of strings (wstrings) with the c++ iostreams.
What about valueboxes of strings (wstrings) - chapter 1.17.7.4?
Is it required to define (in C++) the operators <<, >> to use T_var and T_out
with C++ iostreams, where T is a type for a valuebox T of string (wstring)?
Given
valuetype WStringValue wstring;
is there any requirement to have stream inserters and extractors for the
boxed value type itself? The spec is currently silent on this issue.
Should the following work?
WStringValue ws;
cin >> ws;
cout << ws;
Incorporate Messaging changes relevant to the C++ mapping, as shown in
orbos/98-05-05 pages 115 and 116 together with any changes made to them
by the Messaging RTF, into the IDL-C++ mapping chapter.
Summary: The C++ mapping says:
A compliant mapping implementation shall provide overloaded operator<<
(insertion) and operator>> (extraction) operators for using String_var
and
String_out directly with C++ iostreams.
>From this definition it"s no clear whether operator>> allocates memory
or not. That is, is the following code correct?
CORBA::String_var str;
cin >> str;
closed/resolved
Summary: I"m trying to work out how valuetypes interact with My question is what should the two reference counts be, and why?
>From my understanding, myVal"s reference count should be 1, and myPtr"s
reference count should be 0.
Is this correct? Perhaps an example _out type for valuetypes should be
included in the spec to clear this up for future reference.
Close no change. The submitter of the issue misunderstood _var semantics.
Summary: Suggestion: generate concrete classes and factories
for valuetypes that do not have any initializers. If a
value type does not have any initializers, it should
be safe to use the default constructor for all members.
This would reduce the size of the code that needs
to be written by the application programmer.
Similarly, concrete factories could be generated for
value boxes
resolved/closed
Summary: full_desc: The C++ mapping for CORBA 2.3 introduces reference
counting on servants and provides the
PortableServer::ServantBase_var class for automated
reference counting. However, this class can not be
used if a more specific type of the servant is needed.
Proposal: add a _var type for each servant type, for
example POA_FooBar_var.
see below
Summary: After all the recently past work getting servant reference counting, it
just occurred to me that this doesn"t work with TIE. Or am I missing
something?
As things stand, to make it work it is necessary to derive a new class
from both the instantiated tie template and RefCountServantBase. This
then requires all the constructors to be redefined - ugh!
See resolution for issue 4114, which addresses this issue as well.
Summary: Section 20.38.3 of the CORBA 2.3 draft states:
I believe that the intent of this paragraph is to forbid the user from
calling invoke() and _primary_interface() directly, not to forbid the
POA from calling _primary_interface() in circumstances other than
processing a request.
The paragraph should be reworded to say:
"The invoke() and _primary_interface() methods will be called by the
POA, and should never be explicitly called by the application."
Close no change. This issue is already addressed in the CORBA 2.3 specification.
Summary: Valuetypes can be used to form arbitrary, potentially circular graphs.
This means that reference counts may never drop to zero and that more
advanced garbage collection is required, which does not come natural to
C++.
An ORB may keep track of circularity by traversing a graph and can detect
if the last outside reference is lost. However, the overhead is significant,
and the solution would be incomplete, as users need not use "proper" refe-
rence counting on graph nodes by ignoring both OBV_* classes and default
reference counting.
Possible solution: restrict CORBA::DefaultValueRefCountBase to
non-circular graphs. Users can decide much better when a graph is safe
to be cleaned up.
Close as duplicate of 2309.
Summary: The C++ mapping for Objects by Value requires factories for marshalling
valuetypes. Therefore, it needs to specify default factories for the
standard StringValue and WStringValue types.
Close no change. Valueboxes do not have factories.
Summary: From the C++ spec (CORBA2_3-c++.pdf) pg: 20-132
For static skeletons, the default implementation of the _get_interface
and _is_a functions provided by ServantBase use the interface associated
with the skeleton class to determine their respective return values. For
dynamic skeletons (see Section 20.37), these functions use the
_primary_interface function to determine their return values.
Does this mean that a dynamic implementation needs the IFR?
If not, then how can _is_a be implemented for sub-types?
I note that the java mapping includes the method _all_interfaces in Servant
for precisely this reason...
Already resolved.
Summary: The C++ mapping for valuetype includes a typesafe _narrow generated
for all values. The specification states that the caller
of _narrow must invoke _remove_ref once on the returned value
from _narrow (just like object reference _narrow).
f
Already resolved.
Summary: The passing of valuetypes as parameter to operations needs more
consideration. Section 20.22 of ptc/98-09-03 (98/11/06) specifies
that the callee should receive a deep-copy of each valuetype to
preserve location transparently.
Now, does this apply only to operations of interfaces, or also to
valuetype operations? With the current phrasing, this applies just
the same (meaning that valuetype operations also receive a deep-
copy). And then there are abstract interfaces, which may incarnate
a remote interface or a local valuetype.
Close no change. The specification is already clear about valuetype argument passing semantics.
Summary: Does it make sense to add the AbstractBase base
type to the IDL language, so that operations could
receive an AbstractBase parameter?
close with no change
Summary: Should it be possible to narrow an abstract interface
class to a concrete Object, or to downcast it to a
Valuetype?
closed/resolved
Summary: This is a new issue for the C++ RTF.
The mapping for sequences mandates a get_buffer() accessor for read/write
access to the members of the sequence. It is mentioned that an implemen-
tation is not required to store sequence elements in continuous memory
for efficiency reasons, but may choose to do so only when get_buffer()
is called.
However, this introduces coherency problems if sequence elements are
accessed and modified using both get_buffer() and operator[].
get_buffer() is not possible for recursive sequences anyway.
Close no change. The submitter of the issue misread the specification.
Summary: Sequence allocbuf functions should be specified such that passing zero for
their arguments is illegal. Allocating a sequence buffer of zero elements
is rather pointless because nothing useful can be done with such a buffer.
The result of passing zero to allocbuf should be implementation-defined,
since throwing an exception is not a good way to handle programming logic
errors (similar to how indexing past the end of a sequence is a logic error
for which an exception is pretty useless).
Close no change. Discussion of this issue determined that a zero parameter to allocbuf is legal and
Summary: In the latest spec (98-09-03) the Any class appears to be missing
insertion extraction operators for LongLong, ULongLong, etc.
Close no change. This issue is already addressed in the CORBA 2.3 specification.
Summary: C++ mapping should make available the exception id for each exception type.. Sun would like to revise sec. 3.17 to add following function: static const char * _exception_id();
closed/resolved
Summary: The base exception class should include an accessor to get the exception id of an exception.It"s obtained from environment.Ability to get exception id is desirable in C++
closed/resolved
Summary: Exceptions could be formatted onto ostreams using operator<<..Examples available on /archives/issues/issue266
closed/resolved
Summary: Isn"t it the mappings responsibility to decide how to project the semantics to the underlying "wire rep". You don"t need to put NULL on the wire. Sec 16.18 Pg 16-46 para 11 CORBA2.0
Close no change. This change is too intrusive and would break too much existing code
Summary: Sec 3.16.2 para 11 describes lifetime of inserted value. Since lifetime of the value is independent of value passed to operator<<=, Any must contain a copy of value.
close with no change
Summary: Generated C++ (example) ends up with redefinition errors. This is not addressed in current C++ mapping. Options are to amend IDL or to simply state that such IDL cannot be translated.
close with no change
Summary: identifiers containing a double underscore[..] are reserved for use by C++ implementations and standard libraries and shall be avoided by users. IDL could be amended to prohibit double undersc.
closed with no change
Summary: String_var could refer to memory without assuming memory management responsibilities for it, like void String_var::value(const char*, Boolean release = 0
close with no change
Summary: p41,sec 3.13.3,para 24: These functions should return buffers, not T* If you wanted a T* provide a conversion on returned buffer. No need to lock down implementation in this manner
closed with no change
Summary: Class defined for ServerRequest shows op_def() operation. Seems not to be in IDL for ServerRequest and there is no description in the rest of the section (CORBA 2 spec, Sect. 18.4.1)
Close no change. This issue is already addressed in the CORBA 2.3 specification.
Summary: Sentence in IDL spec "An identifier can only be defined once in a scope.However,identifiers can be redifined in nested scopes" seems to allow interface Foo
{ void Foo(in long 1); };
Close no change. This issue is already addressed in the CORBA 2.3 specification
Summary: Sec 4.10 para 2: pseudo object reference of form tc<type> made available for basic and IDL defined types. Sun wants replacements with global function of form TypeCode_ptr tc<type>
Close with no change
Summary: Sun would like to add the following accessors to Any: Boolean release(); void release(Boolean);
Close with no change
Summary: Sec 3.12 para1 describes union constructors.Sun would like to add new constructor that takes as its sole argument a discriminant value.It initializes union according to specified discr. value
Close with no change
Summary: SystemException class should contain a string name field for easy printing of error messages,or operator<< should be overloaded for each system exception
closed/resolved
Summary: Accessors that return a reference to a non-const object can be used for read-write access. They are provided only for following types: struct, union, sequence, any.Provede for all types..
Close no change. This change is too intrusive and would break too much existing code.
Summary: CORBA2.0 Sec 16.18 Pg 16-45 para 9 The caller has sufficient knowledge to release, but not sufficient knowledge to know if contiguous. ("to allow..we adopt the policy....")
Already resolved.
Summary: Struct Mapping: IONA that accessor functions be provided for struct members. Direct access to member variables still available. Enhancement affords the user a consistent interface.
Closed with no change
Summary: Sec 3.13.2 para 25describes allocbuf. Sun prefers that allocated sequence elements be initialized as if vector were allocated by sequence constructor
Close no change. This issue is already addressed in the CORBA 2.3 specification.
Summary: Sec 16.6 Pg 16-11 CORBA2.0: Sec D.12 states that client stub allocates buffer of specified size for bounded strings.This may result in unnecessary memory consumption.
close with no change
Summary: SystemException has accessor functions minor() and completed() rather than public data members like exceptions normally do. Normal mapping is to make exception data into public data members
Close with no change.
Summary: tables not present in CORBA2.0 What about structs, unions, exceptions, and arrays?
Close no change. This issue is already addressed in the CORBA 2.3 specification
Summary: Sec 16.14.6 Pg 16-38 para 44 CORBA2.0 How are you supposed to delete/duplicate this void* value if you don"t know the type? Do we have to emulate a C++ compiler
Close no change. This issue is already addressed in the CORBA 2.3 specification.
Summary: If operation in an IDL spec. has a context spec, then a Context_ptr input parameter follows all operation specific arguments (OMGD 3.19) It should map to const Context_ptr
Close with no change. Object references are always passed as a plain _ptr parameter and never as a c
Summary: For structs and exceptions: Unions" access functions return primitives by value, not by refs.I need to use temporaries.Change them to refs
Close no change. This issue is already addressed in the CORBA 2.3 specification.
Summary: Tables not present in CORBA2.0 Aren"t anonymus sequences still allowed in structs, union, and exception?
Close no change. This issue is already addressed in the CORBA 2.3 specification.
Summary: Implementation dependent: Namespaces available/not available
Close no change. Issue withdrawn by submitter.
Summary: Please find example/discussion in corresponding archive file
closed and resolved
Summary: The semantics of get_next_response sec 4.3.4 are not well-defined with respect to blocking behavior. There is no explicit description of the behavior of the C++ routines
resolved, issue closed
Summary: Section 16.2: "A shown" should be "As shown". Section 16.6: The title is incorrect "TMapping" remove the "T"
Close as fixed. A search through the current draft does not locate either of the two typos mentioned
Summary: I was writing some C++ code and noticed that the following doesn"t work:
// IDL
interface A {
};
interface B : A {
};
// C++
B_var bv = get_b_from_somewhere();
A_var av = A::_duplicate(bv);
because there is no conversion defined from a B_var to an A_ptr. Is
there a way that this could be added to the language binding without
ambiguity problems?
close with no change
Summary: Should the C++ mapping for ServantBase also have _duplicate,
_var mappings ? For example if get_servant is called on POA, what
are the ownership rules for the returned Servant. It seems providing
a _duplicate, _release operations on ServantBase might be useful. These
operations could be used to ensure that the Servant is not released
while the caller has a reference to it.
resolved and closed in ptc/1998-09-03
Summary: If the same servant and ObjectId are registered with two POAs, _this() can"t know which object to return outside of a method invokation
Close no change. This issue is already addressed in the CORBA 2.3 specification.
Summary: It appears to be impossible to implement the policy objects using the root POA due to race conditions on the Polilicy::destroy() operation. There appears to be no safe time to delete servant
Close no change. This issue is already addressed in the CORBA 2.3 specification.
Summary: IDL for Object Interface differs from that provided by core specification in section 7.2 page 7.2
Close with no change. The relevant functions are shown in the latest C++ mapping.
Summary: Appendix E page E-2 and E-3: String_var and Any_var classes are missing T_ptr definition that occurs in the template for var types. These should be added for completness.
Close with no change. Only object reference types have _ptr type. They do not apply to strings or ty
Summary: IDL spec states that identifiers can have characters that are things like an A with accent aigu, or a german script B. Can IDL identifiers have these characters? How are they mapped ontoC/C++?
Close as non-issue. IDL no longer permits non-ASCII letters in identifiers.
Summary: C++ mapping spec should be clearer about the rules for inout strings.There are currently two possible interpretations of what server can do with an inout string (details in archive)
resolverd and closed
Summary: The discussion of how _this() operates is missing explicit information about what to do if there is no request context. Should _this() return nil reference, or should exception be thrown
Close no change. This issue is already addressed in the CORBA 2.3 specification.
Summary: IDL from Environment has an attribute called "exception" which is invalid. This member should be renammed to "ex"or some other name which is a legal identifier
Close no change. Environment is defined as PIDL, so this is legal.
Summary: C++ mapping for pseudo request class contains const member functions mapped from readonly attributes. IDL does not define C++ mapping for readonly attribs to const member functions.
close with no change
Summary: CORBA2.0 Care must be taken to avoid using T_var types with these extraction operators. They will try to assume responsibility for deleting storage owned by Any. Problem in mapping.
Close with no change. That's how the mapping was designed to work.
Summary: Sec 16.12 Pg 16-28 CORBA2.0 p. 44, sec 3.14 para 8: Why are these global functions rather than static methods of T_var?
closed/resolved
Summary: Sec 16.12 Pg 16-27 CORBA 2.0 Why is a Long Array_slice declared to be a typedef Long[]? Why are these locked down rather than allowing a slice to be a class?
resolved/closed
Summary: Sec 16.11 Pg 16-23 CORBA2.0 What is the semantics of the length() member? When can I do reallocation? Can it truncate? Can it realloc if length== current size?
Close no change. This issue is already addressed in the CORBA 2.3 specification.
Summary: [Sec 16.9 Pg 16-15 CORBA2.0 p.32, Section 3.11 para 4: Seems to describe an implementation. Why is it specified. Is this how Sec. 3.10.1 para 14 issue is supposed to be addressed?
Close no change. We do not have enough context to determine what the issue is.
Summary: [Sec 16.8.1 Pg 16-14 CORBA2.0] p.31, Section 3.10.1 para 12: How do I know if the T_var I"ve been passed (in C++) has been initialized?
Close no change. This change is too intrusive and would break too much existing code.
Summary: Sec 16.8 Pg 16-13 CORBA2.0 p. 29, Section 3.10 example para 4. : This example looks incorrect. Example shown in 3.10.1 is inconsistent with the code in paragraph 4.
Close no change. We do not have enough context to determine what the issue is.
Summary: Sec 15.1.1 Pg 15-1 CORBA2.0 "Conforming client or server program is portable across all conforming implementations" We object the word "portable"being used in this context.
Close no change. We do not have enough context to determine what the issue is.
Summary: Sec 16.11.2 Pg 16-25 CORBA2.0 p.41, section 3.13.2 para 21 Do I have to make an application level full copy? This doesn"t meet the performance goal outlined in the beginning
Already resolved.
Summary: Sec 16.11.2 Pg 16-24 CORBA2.0 p. 40 Section 3.13.2, para 17 Looks like C, not C++
Close no change. We do not have enough context to determine what the issue is.
Summary: [Sec 16.11 Pg 16-21 CORBA2.0 Since autoextension is not apparently supported, you should change "may" to "must"
resolved and closed
Summary: Sec. 16.14.3 Pg 16-34 para 30 CORBA2.0 p.48, sec 3.16.3, para 26 Why is this specified. Why are pointers treated differently from Values. Primitives are not set to NULL
Close with no change. It is no longer possible to identify the document to which the question refers
Summary: What happens if i assign a container of data I hold Does aliasing allow in more than simple temporary. Is there a restriction that there can be NO overlapping?
Close no change. We do not have enough context to determine what the issue is.
Summary: Do you anticipate end user"s instantiating the Array_forany class? Isn"t this a implementation detail? The name conflicts with IDL specifiable. Section should be removed.
closed/resolved
Summary: The POA does not properly define the behavior of POA operations
for requests that are currently executing in an object that
has been deactivated.
Close no change. This issue is already addressed in the CORBA 2.3 specification.
Summary: 2. The spec is silent on whether POA servant classes need to use
virtual inheritence when an IDL class inherits from the same base
interface more than once:
// IDL
interface A
;
interface B : A { };
interface C : A { };
value D : supports B, C { };
Must POA_B & POA_C inherit virtually from POA_A or can defined
independently with all of interface A"s operations? This makes a big
difference for values that support interfaces, since, for example, value
D is defined by the C++ language mapping to inherit from both POA_B and
POA_C. So, does value D inherit one or two versions of A::op()?
resolved
Summary: 2. The spec does not explicitly mention the existence of an Any_out
class. I believe that this class is necessary, following the same
pattern as the normal T_out class for variable length structured types.
resolved and closed
Summary: 1. The spec insection 20.9.2 does not specifically address the form of
T_out types for fixed length structured types. So, should the T_out
type be:
typedef T &T_out;
or should it follow the form of the T_out type for variable length
structured types and define as a "class T_out"? In this case, of course
the copy contructor operator from T_var would not delete the pointer
held by the T_var.
Since the "class T_out" solution for fixed length types does not appear
to have any advantages over the typedef, I recommend that the spec be
modified to state that T_out types for fixed length structured types
simply be a typedef of "T&".
see below
Summary: 3. The spec is too terse in defining the T_var types for fixed length
structured types as having "the same semantics as T_var types for
variable-length types." This is not quite true, since the signatures
for out and return values of these types are different, thus changing
the semantics of the implicit and explicit (out() and _retn())
conversion operations. The spec should show the definition of the out()
and _retn() operations for fixed length types as:
T &T_var::out()
{ return ptr_; }closed/resolved
Summary: // IDL
typedef fixed<4,2> F;
interface foo
{ void op(in F param); };
What should happen if at run time, I do the following?
F myf = "12345.678D";
foo_var fv = ...;
fv->op(myf); // ???
I think the operation should raise BAD_PARAM, because silent truncation
is too dangerous. Note that the operation cannot send a fixed<8,3> because
the operation expects a fixed<4,2> and will get a marshalling error if
what arrives over the wire does not match the IDL definition.
Close no change. This issue is already addressed in the CORBA 2.3 specification.
Summary: The fixed mapping in 98-07-12 shows:
Fixed operator > (const Fixed &val1, const Fixed& val2);
Fixed operator < (const Fixed &val1, const Fixed& val2);
Fixed operator >= (const Fixed &val1, const Fixed& val2);
Fixed operator <= (const Fixed &val1, const Fixed& val2);
Fixed operator != (const Fixed &val1, const Fixed& val2);
Fixed operator == (const Fixed &val1, const Fixed& val2);
I"m surprised at the return type – shouldn"t that be bool for ANSI
compilers and int for non-ANSI compilers?
Already resolved.
Summary: Section 20.13 states:
"For each different named OMG IDL sequence type, a compliant
implementation provides a separate C++ sequence type."
This certainly means that each declared sequence with a different bound
and component type maps to a unique C++ class. But how about this:
// IDL
typedef sequence<long> LongSeq1;
typedef sequence<long> LongSeq2;
Are LongSeq1 & LongSeq2 mapped to the same or different C++ classes?
Close no change. This issue is already addressed in the CORBA 2.3 specification.
Summary: Look at this code and tell me what is wrong with it (CORBA:: left off
for simplicity):
So, now the question is: Inside the
TypeCode_var::operator=(TypeCode_ptr tc)
assignment operator, when tc == this, what should happen?
Should this call release(this) to satisfy the requirements of code frag
#3? Or should it be a noop to satisfy the requirements of code frag #4?
Close no change. The submitter of the issue misunderstood _var reference counting semantics.
Summary: Since it is a native, the parameter passing rules for ValueFactory
must be specified so the register/unregister/lookup operations
can be mapped.
Already resolved.
Summary: There are a few minor editorial mistakes in the C++ language
mapping examples. These are included in this single issue for
brevity.
Already resolved.
Summary: 2. The mapping for the "_out" type for Fixed is broken. It is
specified as a typedef, for example "Fixed<3,1>" maps to:
typedef Fixed<3,1> &Fixed_3_1_out;
but the IDL grammar allows fixed types to be declared as attribute
types, operation parameters and return values. This causes problems
because it is no longer obvious where to declare the _out type for an
out parameter.
Close as fixed. The new Fixed mapping takes care of this.
Summary: the Any class shown on page 20-115 of 98-01-11 appears to be missing
support for some of the new IDL types. In particular, no operators
are shown for (unsigned and signed) long long and long double.
Also, there is no operator to insert an unbounded wide string.
Close no change. This issue is already addressed in the CORBA 2.3 specification.
Summary: The last paragraph of section 5.3.6.3 says the standard language mapping
rules are followed when determining these operation signatures. Since
one of the arguments/return values is a Native, this isn"t quite
possible.
Already resolved.
Summary: Should the ORB hide the difference between fixed and variable length structs from the application developer?
Close no change. This change is too intrusive and would break too much existing code.
Summary: The operations duplicate and release work together to provide memory mgmt. functionallity. It"s desirable to use both via similar interface/syntax. nil/is_nil similar problem
close with no change
Summary: In the DII, testing what variety of exception is stored in the Request Pseudo-object requires a sequence of dynamic_cast<> or (_narrow) calls. It would be useful to have a single call.
closed/resolved
Summary: [Ch 17 CORBA2.0] Sun would like section 4 to include the interface for the dynamic server invocation
Close no change. This issue is already addressed in the CORBA 2.3 specification.
Summary: Section 3.1 para 4 specifies the rule for resolving identifier conflicts with C++ keywords. A similar rule is required to resolve name conflicts resulting from the mapping.
Close 192 with no change
Summary: Implementation dependent: What happens if the typecode & value for the unsafe Any operations do not match?
Close no change. Issue withdrawn by submitter.
Summary: Implementation dependent: illegal access of union member accessor functions when the discriminator has the wrong value
Close no change. Issue withdrawn by submitter.
Summary: Suggest changing the mapping so that object references for an interface "T" are passed as "const T_ptr&" instead of just "T_ptr" for "in" parameters.
Close no change. This change is too intrusive and would break too much existing code.
Summary: Implementation dependent: Implementation representation of the void * pointer returned by Any::value() for unknown types
Close with no change. The latest draft has already deprecated the void * member functions for type A
Summary: Mapping for Interface [16.3 CORBA2.0] Mapping example in 3.5.6 implements the ptr type as full pointer. A pointer could be implemented as a class
Close no change. This change is too intrusive and would break too much existing code.
Summary: Implementation dependent: _ptr member accessors for strings & object references
Close no change. Issue withdrawn by submitter.
quite some time ago, we added the _var_type and _ptr_type definitions
to proxies to make it easier to write templates. Similarly, we have
the _whatever_seq typedefs for recursive structs and unions, to avoid
problems with anonymous types.
What's missing at the moment is a similar feature for _var types.
When I'm writing a template that does it's job in terms of _var types,
I also quite often want to do something to the underlying target type
of the _var. However, I can't do that unless I pass in an extra template
parameter (which, in turn, doesn't always work if I also want to use
STL standard binders and such...)
So, why not add a typedef for the target type to every _var type?
the spec is currently not terribly clear about the server's responsibilities
when throwing an exception from an operation that has a variable-length
out param.
The intent of the spec is that the server is responsible for deleting
the memory it allocated to an out param before it throws an exception:
// Correct implementation
void
Foo_impl::
op(CORBA::String_out out_p) throw(CORBA::SystemException)
// Incorrect implementation
void
Foo_impl::
op(CORBA::String_out out_p) throw(CORBA::SystemException)
However, the spec never states this clearly. In fact, it sort of says
the opposite. On page 1-110, table item 3:
To maintain local/remote transparency, the caller must always
release the returned storage, regardless of whether the callee
is located in the same address space as the caller or is located
in a different address space.
There is no mention here of what should happen in the presence of exceptions.
I think it would be nice to clarify that the skeleton will never look
at an out param in the presence of exceptions and that the operation
implementation is responsible for deallocating memory in this case.
in the resolution to issue 863, we decided to get rid of the read-only
restriction for parameters. However, we forgot to remove a few snippets.
Page 1-110, table, case 3:
Remove the following text:
Following the completion of a request, the caller is not allowed
to modify any values in the returned storage--to do so, the
caller must first copy the returned instance into a new instance,
then modify the new instance.
Page 1-110, table, case 6:
Remove the following text:
Following completion of a request, the caller is not allowed
to modify any values in the returned storage--to do so, the
caller must first copy the returned array instance into a new
array instance, then modify the new instance.
Section 1.17.11 of ptc/2000-01-02 says that DataInputStream &
DataOutputStream are mapped according to the normal valuetype mappings.
This mapping results in operations that are at best cumbersome to use in
marshalling sequences of primitive types:
Operations read_xxx_array and write_xxx_array are defined, taking argments
of type CORBA::xxxSeq. These are obviously intended to be sufficient for
marshalling all defined sequences of the corresponding primitive type xxx.
However, the c++ mapping for sequences requires that each distinctly
declared sequence type be unique and separately overloadable. This
guarantees that a marshaller attempting to marshal an sequence of primitive
other than CORBA::xxxSeq will not be able to pass that sequence to the
corresponding read_xxx_array and write_xxx_array operations. Instead, code
must be written to bypass strict typing.
To fix this, either the mappings for DataInputStream and DataOutputStream
need to be non-standard, the mapping of sequences needs to change, or the
mapping of CORBA::xxxSeq needs to change to something special.
the text for set_servant doesn't say what should happen if I call
set_servant(0). I would suggest to throw BAD_PARAM in this case.
For servant reference counting, the words "at least once" appear
in a number of places when it comes to servant activation. set_servant(),
activate_object(), activate_object_with_id(), servant_to_id(),
servant_to_reference(), and _this() all use this language (pages 1-137 and
1-138):
... will invoke _add_ref at least once on the Servant argument...
Problem: suppose my ORB calls _add_ref() twice in each of these operations
for some reason. I now have a problem. That's because, for servant
activators, responsibility for calling _remove_ref() passes to
etherialize(). However, if the ORB is permitted to call _add_ref() as
many times as it likes, I have no idea how many times I have to call
_remove_ref() from within etherealize(). I think that the spec should say
that _add_ref() is called exactly once for these operations if the
corresponding servant is not in the AOM already.
I vaguely remember the discussion about optimization of the calls
to _add_ref() and _remove_ref(). I think the idea was to permit the ORB
to avoid redundant calls. However, it seems that the language in the spec
isn't precise enough. Under one interpretation, the refcount counts
the number of entries in the AOM. Under another interpretation, it counts
the number of calls in progress as well (because an ORB could call _add_ref()
when a call is dispatched and call _remove_ref() when it finishes).
Under yet a third interpretation, the refcount counts the number of
object references in my address space. That interpretation is happens
if every call to _this() calls _add_ref()...
The language is not precise enough, I think...
I believe the specification for insertion of object references to Anys is
somewhat ambiguous. And, if it is intended to be as I think, it may also be
less than ideal.
Consider the following idl:
interface B
{...};;
And then consider the following code:
D_ptr d; // initialize this to non-null value somehow
B_ptr b = B::_narrow(d);
Any ab;
ab <<= b;
Any ad;
ad <<= d;
// ...
B_ptr b_val;
if (ab>>=b_val)
; // 2
D_ptr d_val;
if (ab>>=d_val)
; // 4
>From what I can see of the spec, it is a bit unclear about whether then
insertion of an object should use the static type or the dynamic type of the
object to initialize the typecode. Simplicity and consistency with other
related operations suggests that it should use the static type. That is what
we currently do, and a quick test of ORBIX 2000 seems to tell me it does it
that way too.
With that interpretation, 1&4 will work, while 2&3 will fail.
Nobody should be surprised that 3 fails, but it is inconvenient
that 2 doesn't work.
If insertion used the dynamic type of its argument, then 1&2
would work, while 3&4 would fail.
To get reasonable behavior when derived types might be present,
(and how often can you be certain they cannot?)
it seems that one should almost never use type specific object
extraction. Instead, one must do something like:
Object_var o;
B_var bv;
if (ad>>=to_object(o._out()) &&
!CORBA::is_nil(bv = B::_narrow(o)))
;
This is unfortunately a bit inconvenient.
So, is there any text in the spec that says, when inserting an object
reference type into an any, if the repository id in the typecode should be
the static type of the inserted argument or the dynamic type of the value of
the argument?
If not, I think we need to add some text.
The C++ "Mapping of PortableServer Dynamic Implementation Routine" states
that "If DynamicImplementation::_this() is invoked outside of the context
of a request invocation on a target object being served by the DSI servant,
it raises the PortableServer::WrongPolicy exception".
This conflicts with the behaviour of _this() in static skeletons as de-
fined in "Skeleton Operations".
In particular, this means that DSI servants cannot be implicitly acti-
vated, and therefore, the choice of DSI vs. static skeleton is not trans-
parent to the application integrator.
Is there any rationale behind this?
I seem to remember that we decided to deprecate the void * functions
on type Any. However, looking at the latest C++ draft, they are not
marked as deprecated.
Can anyone remember what we decided to do? Is this a bug in the spec
or a bug in my memory?
C++ issue #1: The C++ specification should state that valuetype
parameters which are copied by the ORB for collocated invocations are
done using an ORB internal mechanism, not _copy_value().
The CORBA 2.3 C++ mapping is clear on what the use of
ValueBase::_copy_value is, but is unclear as to who is responsible for
providing an overriding definition of this pure virtual function. Is
it the IDL compiler, generating an overriding _copy_value() function for
each valuetype C++ class, or is the user, when he provides a valuetype
implementation class?
C++ issue #2: The ValueBase::_copy_value() function should be
deprecated in favor of a new ValueBase::_clone_value() operation:
// IDL
module CORBA {
abstract valuetype CloneContext { };
};
// C++
namespace CORBA {
...
class ValueBase
;
...
};
The _clone_value() function provides an independant copy of the
valuetype it is invoked on. Any valuetypes reachable via the state of
the original valuetype are also copied, and relationships between
original valuetype(s) will be preserved in the cloned copies. The
CloneContext argument provides the necessary state information for the
ORB to properly maintain relationships between copied valuetypes. If
_clone_value() is called with a null CloneContext, a new CloneContext
will be generated and returned by the ORB as a result of the call.
The CORBA 2.3 C++ specification, section 1.22 states that valuetypes
passed as in parameters to an invocation of an object are copied, even
if the object is collocated with the caller. It does not make this
statement for inout or out parameters (or return results), which
strongly suggests that valuetype copying is not necessary. In fact, the
text for valuetype inout parameters strongly suggests that copying is
not performed.
I think this is wrong and inout & out valuetypes should be copied as
well (inout parameters should be copied before and after the invocation,
while out and return values should be copied after the invocation
completes.) Without the copies, call transparency will be broken and
the client can distinguish between a local and a remote call.
The mapping for user exceptions and structures is identical, except
for one thing: user exceptions have an additional constructor with
one parameter for each member, so I can construct and throw the exception
with a single throw statement.
However, structures are second-class citizens: I can't instantiate and
initialize a structure at the same time. (Well, at least not in general,
because static initialization only works for aggregates and, at any rate,
I can only instantiate and initialize with compile-time constants.)
So, why don't we add the same constructor to the mapping for structures?
It seems inconsistent to have one mapping for structures and a slightly
different one for exceptions, when in fact they both could be the same.
Summary: This may be a naive question, but it seems like the C++ mapping
for value boxes is incomplete. As far as I can tell, the specification
defines the mapping for the following types:
basic types, enum, objref, string, wstring, struct, union, sequence, array, fixed, any
But what about the types that have not been mentioned?
value, value box, TypeCode, Principal, native, except
If these types aren"t allowed, does the specification say that somewhere?
Summary: We all know that the names of the C++ #include files generated from IDL are
not standardized, and are thus the one remaining major source portability
issue. One way to fix this would be to agree on some standard filenames,
but we"ve tried this before and have never succeeded.
Just thinking out loud here, but another way to fix it would be to agree on
some standard macro names that applications could use to portably include
the appropriate files. For example, define one macro for a client-side
include and one macro for a server-side include, both taking the basename
of the IDL file as an argument:
#ifndef CORBA_CXX_CLIENT_INCLUDE
#define CORBA_CXX_CLIENT_INCLUDE(base) <base ## Client.hh>
#endif
#ifndef CORBA_CXX_SERVER_INCLUDE
#define CORBA_CXX_SERVER_INCLUDE(base) <base ## Server.hh>
#endif
Obviously, the exact definition of the macro would depend on the names of
the generated files.
I believe these could then be used portably in the client and server source
code like this:
#include CORBA_CXX_CLIENT_INCLUDE(file)
With this approach, nobody has to change the names of the files they
currently generate.
Summary: Consider the following IDL:
----------------------------------------------------------------------
// IDL
typedef long MyArray[1000000];
interface I
;
----------------------------------------------------------------------
Now let"s assume that I want to implement this using the DSI:
----------------------------------------------------------------------
// C++
void
I_impl::invoke(ServerRequest_ptr request) throw()
{
String_var name = request -> op_name();
if(strcmp(name, "set_array") == 0)
{ NVList_ptr list; orb -> create_list(0, list); Any* any = list -> add(ARG_IN) -> value(); XXX request -> params(list); MyArray_forany arg; *any >>= arg; ... // Do something with arg; return; }else
{ NVList_ptr list; orb -> create_list(0, list); request -> params(list); Any* any = new Any; *any <<= new BAD_OPERATION(); request -> exception(any); } }
----------------------------------------------------------------------
At the line I marked with XXX, I have to set the TypeCode of the
Any.
Summary: Michi Henning & Steve Vinoski have previously challenged people to come
up with a modification to the C++ language mapping that would allow for
type safe widening of object reference _var types for assignment or copy
construction. I believe I have come up with the solution, and Michi
agrees with me:
Proposal:
For object reference _var types, replace the copy and assignment
operators:
class T_var
{ public: ... T_var(const T_var &); T_var &operator = (const T_var &); ... };
with:
class T_var {
public:
...
template <class C_var>
T_var(const C_var &cv) : ptr_(T::_duplicate(cv.in()) {
}
template <class C_var>
T_var &operator = (const C_var &cv) {
if ((void *)this != (void *)cv)
return *this;
}
...
private:
T_ptr ptr_;
};
Summary: There seems to be nothing in the spec that specifies the name of the include files for things in the CORBA module (e.g. type definitions). Add such a requirement to each language mapping
Summary: In a number of places in the sample code for the C++ binding, the symbol
_ptr is used as a member variable in _var types. In all of these the
actual member is shown as private, so it is clear that actual
implementations could use something else.
The one exception to this is in section 20.10 on the Mapping for Struct
Types. This discusses (without sample code) the mapping for string and
object reference members of structs.
Summary: The current C++ chapter for custom marshalled values on p. 20-94 lacks
information about how one implements a custom value.
The "Value Type Semantics" chapter in "ptc/98-10-06, 15 Oct. 98[REVIEW]"
p. 5-11 says,
" The implementer of a custom value type shall provide an
implementation of the CustomMarshaller operations. The manner
in which this [sic] done shall be specified for each language mapping..."
Summary:
The C++ mapping does not permit extraction of a Fixed from an Any
in a generic way – I must always specify matching digits and scale in
order to call Any::to_fixed(). This is inconvenient if an application
wants to deal with Fixed values generically (because Fixed is a generic
type in C++ anyway).
Proposal:
Add an overloaded >>= operator for extraction of Fixed from an Any.
The operator sets the Fixed value to whatever scale and digits
are present in the type code.
Cheers,
Michi.
Summary: The mapping right now offers Any::to_fixed to get a Fixed value out of an Any:
to_fixed(Fixed &f, UShort d, UShort s);
The spec doesn"t state what should happen if the digits and scale do
not match what is in the type code. I believe extraction should fail in
this case.
Summary: Section 20.9, page 20-28 of orbos/98-07-12 describes what types are
considered variable-length. Since the new Fixed class has non-trivial
constructors, it should also be a considered a variable-length type. Note
that any fixed-length struct containing one cannot be statically initialized.
Summary: There is no mention of PortableServer::ValueRefCountBase after this
page. It is not clear why values that also implement interfaces
do not use the same reference counting scheme as other values.
Summary: The C++ mapping document (98-09-03, p. 108) states that "... the callee
shall receive a copy of each valuetype argument passed to it even if the
caller and callee are collocated in the same process."
In the collocated case, should the ORB invoke _copy_value() to produce
the copy?
Since the user could implement _copy_value() to return a nil value, it
seems unlikely that the ORB could rely on this mechanism. However, a
properly implemented _copy_value() would likely provide a significant
speed improvement over marshalling and unmarshalling.
Summary: Section 20.21, "Argument Passing Considerations," says that for valuetypes:
"The caller shall eventually invoked _remove_ref on the valuetype
instance it receives back as either an inout, out, or return value."
For memory management purposes, this is not sufficient in some cases.
Summary: What happens if I write
CORBA::Any a = ...;
const char *p;
a >>= p;
and the type code in the Any indicates a bounded string? Does the extraction
succeed or fail? The mapping doesn"t say.
The semantics for insertion of a valuetype into an Any are unclear.
(Note, this is related to issue 2531 in the IDL-to-Java RTF.
It is also related to orb_revision issue 3205.)
In section 1.16.2 of ptc/2000-01-02, two forms of insertion are defined:
copying and non-copying. The non-copying form is described as:
"The noncopying valuetype insertion consumes the valuetype pointed to by the
pointer that T** points to. After insertion, the caller may not access the
valuetype instance pointed to by the pointer that T* points to. The caller
maintains ownership of the storage for the pointed-to-T* itself."
There is no specific description of the copying form specific to valuetypes,
so the generic description must apply:
"For the copying version of operator<<=, the lifetime of the value in the
any is independent of the lifetime of the value passed to operator<<=. The
implementation of the any may not store its value as a reference or pointer
to the value passed to operator<<=."
One possible interpretation (1) is that the copying form should be
implemented via a call to the _copy_value virtual function, while the
non-copying form should simply retain the provided pointer (without calling
_add_ref) and eventually call _remove_ref when done with it.
If so, what is the significance of the rule about the caller not continuing
to use the pointer? It it only that it has lost a reference count, and may
continue using the pointer if it has another reference count? Or does this
imply that continued access to the value is forbidden regardless of
reference count?
Another possible interpretation (2) is that the description is nonsense, and
that the non-copying form should use _add_ref and the copying form should
use _copy_value. In this interpretation the caller would be free to continue
using the original pointer and would be obligated to _remove_ref it
eventually. This seems like a more practical interpretation, but is
inconsistent with usage for other non-copying insertions.
Suggested Resolution:
Replace the paragraph on non-copying insertion of valuetypes (quoted above)
with:
"The noncopying valuetype insertion takes ownership of one reference count
to the valuetype pointed to by the pointer that T** points to. After
insertion, the caller should treat the pointer as if _remove_ref had been
called on it. The caller maintains ownership of the storage for the
pointed-to-T* itself."
"For copying valuetype insertion, the lifetime of the value in the any is
independent of the lifetime of the value provided. The implementation of the
any shall duplicate the value using the virtual function _copy_value or an
equivalent mechanism. The caller retains ownership of the T* pointer and
remains obliged to call _remove_ref on it."
The mapping is currently a bit ambiguous about the insertion/extraction
operators for Any. It says:
Assuming that boolean, char, and octet all map the C++ type
unsigned char, the private and unimplemented operator<<= and
operator>>= functions for unsigned char will cause a compile-time
error if straight insertion or extraction of any of the
boolean, char, or octet types is attempted.
This is ambiguous. It is not clear what is qualified by the first part
of the sentence "Assuming that...". It could qualify all of the paragraph,
in which case the interpretation is:
Only on platform where these three types indeed map to the same
C++ type will it be necessary to have these unimplemented operators.
// C++ Octet
oct = 040;
Any any;
any <<= oct; // this line will not compile
any <<= Any::from_octet(oct); // but this one will
This is unambiguous, but it doesn't make it clear whether this will be
the case for all mapping implementations, or only those where the
IDL types map to ambiguous C++ types.
It is important to note that the previous example is only one
possible implementation for these helpers, not a mandated one.
Other compliant implementations are possible, such as providing
them via in-lined static any member functions if boolean, char,
and octet are in fact mapped to distinct C++ types. All
compliant C++ mapping implementations must provide these helpers,
however, for purposes of portability.
Again, this is slightly ambiguous because, even though it requires the
presence of the helpers, it doesn't make any statement about whether the
prohibition of the direct insertion operators is mandatory for all
implementations.
I would suggest to clarify the text to state that direct insertion/extraction
of Bool, Octet, and Char must fail with a compile-time error, regardless
of how these types are mapped.
Question: Is it legal to do the following if I use a C++ mapping that
uses C++ exceptions instead of using CORBA::Environment to
handle errors?
CORBA::Environment my_env;
The spec says (page 114):
The C++-PIDL specification differs from the C-PIDL specification
as follows:
[...]
Supports a default constructor that initializes it to hold no
exception information.
However, the class definition that follows does not show the
default constructor.
So, the text disagrees with the class definition that is shown because
"supports a default constructor" does not have a "may" or "might", so
the text would appear to make the default constructor mandatory for
both EH and non-EH mappings.
The C++ language mapping does not specify what criterion should be used to
determine the validity of a typesafe extraction from an Any.
The closest it ever comes is the statement in 1.16.3:
"In this case, the version of operator>>= for type Long must be able to
determine whether the Any truly does contain a value of type Long...".
There are two obvious candidates: the equal and equivalent operations of
TypeCode.
Proposed resolution:
Replace the first sentence of 1.16.3:
"To allow type-safe retrieval of a value from
an any, the mapping provides the following
operators for each OMG IDL type T:"
with:
To allow type-safe retrieval of a value
from an Any, the mapping provides an
operator>>= for each OMG IDL type T.
Each such operator returns a boolean
indicating success or failure, and if
successful, makes the value of the any
available via a user supplied argument.
The success of the operation is determined
by applying the
needs to be discussed. I believe there
are valid arguments for each.
I believe that the CORBA::release and CORBA::is_nil
functions that take a POA_ptr argument do not
reference the proper scope:
1.41.11 release and is_nil
// C++
namespace CORBA
Should be:
1.41.11 release and is_nil
// C++
namespace CORBA
I don't see in the specification where the scope
of POA_ptr is explicitly defined. But, I believe
that the correct definition of POA_ptr is in the
PortableServer namespace (i.e. the enclosing scope
of the POA class).
Then again I can't find anything in the specification
that asserts that any Foo_ptr type must go in the
immediately enclosing class or namespace containing
the Foo type. :-/
Also, if POA_ptr is in PortableServer when an ORB is
mapping of modules to classes the definition of the
above release and is_nil functions in the CORBA class
will be impossible.
So I feel compelled to ask:
Do we really need to have release and is_nil functions
for types outside of the CORBA module?
the new mapping for _var types for fixed-length underlying types shows:
T_var &operator=(T *t) {
if (t != m_ptr)
return *this;
}
This guards against self assignment when a pointer is assigned to the _var.
I don't think this is right:
MyStruct * p = ...;
MyStruct_var v = p; // OK
// ...
v = p; // Almost certainly an error
A_var &operator=(const A_var& a)
{ reset(p); return *this; } This is inconsistent: assignment of a _ptr to a _var reference
is not safe against self assignment, so assignment of a pointer
to the _var for a fixed-length type shouldn't be either.
Note that the other assignment operators are just fine – I'm only objecting
to testing for self-assignment for operator= with a pointer as the RHS.
(A nice compiler could even insert an assertions if a _var is assigned the
same thing that it already points at.)
the spec currently says (page 1-101):
Request invocations made through the DII may result in
user-defined exceptions that cannot be fully represented
in the calling program because the specific exception type
was not known at compile-time. The mapping provides the
UnknownUserException so that such exceptions can be represented
in the calling process: [...]
Here is a code snippet for the DII:
req->invoke();
if (req->env()->exception())
The para on page 1-101, by implication, says that:
It's not as clearly spelled out as this, but it can be implied from the
words on page 1-101.
This is bad. For one, it implies "action at a distance". For example,
linking the stubs for a user exception into a completely unrelated
part of the same binary (possibly via a library) would change
the behavior of the above DII call. Further, to make this behavior
happen would require some form of global initialization data structure.
In effect, there would have to be something that would let the ORB
know (globally) for which user exceptions stub code is linked in.
We rejected the need for global data recently in another context (for
the proposed extraction operator for user exceptions). For the same reason,
we should reject this here and mandate that, if I use the DII, all user
exceptions are always returned as UnknownUserException.
I think we have a defect/omission in the C++ mapping with respect
to exception safety. Consider a servant class with a constructor:
class FooImpl : public virtual POA_Foo
{ public: FooImpl(); // ... };
Consider what happens if FooImpl() throws an exception for some reason.
By the time FooImpl() runs, the base class constructor POA_Foo() has run
already. So, when the compiler deals with the exception, it invokes
~POA_Foo().
The problem arises because, in our implementation at least, ~POA_Foo()
checks if the reference count is zero and asserts if not.
There doens't appear to be any portable way to implement an object that
inherits from an abstract interface using the DSI in C++ without compile
time knowledge of the abstract interface. The basic problem is that I
can create an object reference from a POA, but there is no way to
convert the reference into an abstract interface reference so that I can
send it out on the wire.
We need some mechanism to coerce an object reference into an abstract
interface reference (with a runtime check) to make this work.
what should _default_POA() return if no default ORB exists in the server
(that is, ORB_init() with an empty ORB ID was never called)?
Summary: The ValueBase::_copy_value() function is included in the discussion
of the "reference counting interface" in section 1.17.5 of 99-07-41.
Later, the description of the reference counting mix-in classes
says:
"Each of these classes shall be fully concrete and shall completely
fulfill the ValueBase reference counting interface..."
However, I do not believe that the intent was to require the mix-in
classes to implement _copy_value().
Therefore I suggest one of two clarifications:
1) Move the discussion of _copy_value() out of the reference-counting
section, or
2) Specify which functions the mix-in classes are actually expected to
implement, e.g.,
"Each of these classes shall be fully concrete and shall completely
fulfill the ValueBase reference counting interface (_add_ref,
_remove_ref, and _refcount_value), ..."
the spec says (on page 1-23):
The T* constructor creates a T_var that, when destroyed, will
delete the storage pointed to by the T* parameter. The parameter
to this constructor should never be a null pointer. Compliant
implementations are not required to detect null pointers passed
to this constructor.
This seems broken for two reasons:
Foo_var fv(some_ref->op(my_corba_environment));
and op() raises an exception (which will be returned in the
environment), I'm hosed.
It seems that disallowing initialization from null pointer is some
historical hangover? I think the restriction should be removed.
In section 1.17.5, the C++ class for Valuebase does not show the
get_value_def operation.
Section 1.17.7.5 states: "Value boxes for these types [including Fixed]
map to classes that have exactly the same public interfaces as the
underlying boxed types...".
Does this also include overloaded operators that are defined in the
Fixed class?
It sure seems weird to allow some operators to work but not others:
// IDL
valuetype FixedVal fixed<5,2>;
// C++
FixedVal *fv = ...;
++fv; // legal?
CORBA::Fixed f = fv * 2; // illegal?
In the CORBA 2.3 spec, section 6.2, CORBA::AbstractBase is defined as:
module CORBA
{ native AbstractBase; };
This implies that the C++ mapping for AbstractBase when used as a
parameter is like this:
class DataOutputStream
{ // from CORBA 2.3, section 5.5.2 void write_Abstract(AbstractBase value); };
But section 1.18.1 of the CORBA 2.3 C++ mapping makes it clear that the
signature should be:
class DataOutputStream
{ // void write_Abstract(AbstractBase_ptr value); };
Now I know that DataInputStream & DataOutputStream can be special cased
to handle this, but if we need to add additional operations that use
AbstractBase in the future, it would be nice if this could be fixed to
behave consistently with the other native type mappings to C++.
Summary: The C++ language mapping chapter contains many blocks of IDL like stuff
with the comment
// IDL
in the first line, but the stuff in the block is not valid IDL for
various reasons:
Uses "pseudo" as an apparent keyword.
(ii) Contains declarations like
attribute exception exception;
I suggest that the comment "// IDL" be replaced by "// Augmented IDL
(see "Usage" on page x-y)" cross-referencing to section 20.23 Usage, so
that people know for sure that this is not IDL.
Furthermore, to make the claim in section 20.23 true, the declaration:
attribute exception exception;
should be fixed to be something else, or alternatively, the exceptional
use of exception should be called out as a specific augmentation of IDL
in section 20.23.
consider:
// IDL
struct VariableStruct
{ ... };
interface I
;
Then:
// C++
void
MyImplForI::foo(VariableStruct_out s)
void
MyImplForI::bar(VariableStruct_out s)
The freeing of memory for out params relies on the default conversion
by the _out constructor from a pointer to the _out type which, as a
side effect, frees the memory return by the previous call. However,
in this case, and _out param is passed to another call, so the
assignment operator runs, not the constructor:
T_out& operator=(T* p)
{ ptr_ = p; return *this; }The assignment operator doesn't free the previous memory, so we get
the leak.
Should the assignment operator be changed?
The mapping requires that it must be possible to insert CORBA::Exception
into an any (section 1.19.2).
Question: Is it possible to insert UnknownUserException into an Any?
If the answer is yes, what are the members of UnknownUserException, what
is its CDR representation, and what is its TypeCode?
If the answer is no, we should clearly state this and specify what happens
if I attempt to insert UnknownUserException into an Any.
the mapping says in section 1.1.2:
To avoid C++ compilation problems, every use in OMG IDL of a
C++ keyword as an identifier is mapped into the same name preceded
by the prefix "cxx." For example, an IDL interface named "try"
would be named "_cxx_try" when its name is mapped into C++.
For consistency, this rule also applies to identifiers that
are derived from IDL identifiers. For example, an IDL interface
"try" generates the names "_cxx_try_var" and "cxx_try_ptr,"
^^^^^^^^^^^
that is, the IDL compiler behaves as if the interface were
names "cxx_try" and then applies the normal mapping rules.
^ ^^^^^^^
Four issues here:
1) I think we have a typo at the first place I highlighed. I
believe it should be "_cxx_try_ptr". (The leading underscore
is missing in the text as it stands now.)
2) Typo: It should be '...were named "cxx_try"', not
'... were names "cxx_try"'
3) To state that the compiler behaves is if the interface were
named "cxx_try" doesn't explain where the additional leading
underscore comes from because we get cxx, not cxx_
for the mapped identifiers.
Unfortunately, changing this sentence to state that the compiler
behaves as if the interface were named "_cxx_try" won't fix
it, because the leading underscore would be dropped by the
IDL keyword escape mechanism.
4) The explanations are insufficient:
interface try {};
This will result in "_cxx_try" as the interface name. But what
about the generated tc type code constant? It could be:
a) _cxx_tc_try
This mapping would be consistent with the statement that
the "cxx" is a prefix.
b) cxx_tc_try
Same as above but, given that, normally, the tc type code
constants already start with an underscore, the escaped
mapping results in a double underscore.
c) _tc_cxx_try
This mapping would be consistent with the directive to map
as if the type were named "cxx_try".
d) tc_cxx_try
Same as above but preserves the underscore for both the
"tc" and the "cxx", resulting in a double underscore.
To me, interpretation (d) seems the most natural and intuitive because
it preserves the leading "tc" for all type code constants (including ones
for identifiers that are C++ keywords). Also, if the mapping of the type
is to "_cxx_try", then it makes sense to have the double underscore because
that is consistent and doesn't make an exception to the rule of "use
"tc" for type code constants and "cxx" for IDL identifiers that are
C++ keywords."
Proposal:
Rewrite the above para to read:
To avoid C++ compilation problems, every use in OMG IDL of a
C++ keyword as an identifier is mapped into the same name preceded
by the prefix "cxx." For example, an IDL interface named "try"
would be named "_cxx_try" when its name is mapped into C++.
For consistency, this rule also applies to identifiers that
are derived from IDL identifiers. For example, an IDL interface
"try" generates the names "_cxx_try_var," "_cxx_try_ptr,"
and "tc_cxx_try".
accept the suggested proposal
The current specification of the local mapping requires the
implementation to enforce the "localness" of the object. This was very
similar to the (old) java mapping. The inheritance heirarchy is as
follows
CORBA::LocalObject : CORBA::Object
abstract MyLocalObject : CORBA::Object
MyLocalObjectImpl : MyLocalObject, CORBA::LocalObject
The problem here is that there is no way for the ORB or the code
generators to enforce the last inheritance. And I am not even sure how
an ORB can detect the following case
MyLocalObjectImpl : MyLocalObject
which I suspect would be a very common error.
Proposal:
Fix the mapping to have the following heirarchy.
CORBA::LocalObject : CORBA::Object
abstract MyLocalObject : CORBA::LocalObject <===== Difference is here
MyLocalObjectImpl : MyLocalObject <== and here
Now an _is_a("IDL:omg.org/CORBA/LocalObject:1.0") is guaranteed to give
a correct answer and it is enforced by the IDL compilers.
This is also backward source compatible.
see issue #4160 (the proposed resolution rejects this suggestion)
There seems to be only two choices:
1. Accept that changing interfaces to local breaks old code that implemented
POA interfaces using servants. Not wonderful, but I can live with it, since
the source code changes are evident and fixed in a straightforward fashion.
2. Try to come up with a scheme where local objects can be implemented either
by using LocalObject or by the traditional servant route. This is more
specification work, but cleaner, and I an live with it too.
While we are at it, we should make sure that any other CORBA 3.0 changes are
properly reflected in the C++ mapping as well.
see proposed resolution for issue #4160
a discussion in comp.object.corba pointed out the difficulty
of testing whether a T_var has been initialized. There is
no _is_null() member function or some such. As a result,
calling operator->() appears to be the only way to test
whether a T_var is initialized:
if (T_var.operator->())
// It's initialized...
Not exactly elegant, but workable. However, the following
words in the spec get in the way:
"The overloaded operator-> returns the T* held by the T_var,
but retains ownership of it. Compliant applications may not
call this function unless the T_var has been initialized with a
valid non-null T* or T_var."
These words forbid me to call operator->() until after the
T_var has been initialized, meaning that there is no portable
and compliant way to test whether a T_var is nil. I think
what was meant here is that
"Compliant applications may not *dereference the return value
of this function* unless the T_var has been initialized with a
valid non-null T* or T_var."
BTW – using operator->() to test for null is a bit obscure.
We could add a _is_null() member to T_var for this. But,
given the versioning confustion we'd cause and the fact
that adding the member provides only marginal benefit,
I think it may be better to leave things as they are. (But
we should fix the description of operator->(), of course.)
see above
in ptc/01-06-07, 1.34.1, several operations seem to be missing in the Object
interface, e. g.
get_client_policy()
get_policy_overrides()
validate_connection()
These are also missing in the Object C++ class, 1.34.2. create_request2() is
also missing here.
see above
This e-mail addresses three CORBA C++ Revision Task Force issues:
3796
3797
4530
It also addresses section 6.10.2 of your book, "Advanced CORBA
Programming with C++" ((C) 1999).
Starting with 6.10.2 of your book, p. 164, you show an example where a
CORBA::String_var is implicitly converted to 'const char *' in a
function call, with the conversion operators as defined on p. 157 (sect.
6.10).
However, the C++ language won't choose the 'const char *() const'
operator as you (and I) would think. Instead, since the String_var
isn't const in the call's scope, the 'char *()' (i.e., non-const)
operator is chosen.
Aparently, the conversion path
String_var -> char * -> const char *
Is considered "better" than the conversion path we'd expect, namely
String_var -> const String_var -> const char *
Further, updating String_var with the resolutions of Issues 3796 and
3797 (as found in http://cgi.omg.org/issues/cxx_revision.html), namely
removing 'operator char *()' and adding 'operator char *&()' now leads
to the conversion path
String_var -> char *& -> const char *
The 'const char *' operator is still bypassed, and with 'operator char
*&()' in the picture, it seems trouble is more likely.
For reference, take a look at the USENET newsgroup comp.std.c++, the
thread of "Subject: Implicit conversion of g++", starting 2000/03/02 (I
know that long URL's don't e-mail well, but...
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&threadm=p6qr
9dsxi04.fsf%40informatik.hu-berlin.de&rnum=1&prev=/groups%3Fhl%3Den%26lr
%3D%26ie%3DUTF-8%26oe%3DUTF-8%26selm%3Dp6qr9dsxi04.fsf%2540informatik.hu
-berlin.de)
For reference, I've attached a little source-code. Imagine that the
class is String_var. This program produces identical results under two
compilers:
Though the String_var implementations I've seen aren't adversely
affected, I wanted to bring this compiler behavior to your attention. I
think the CORBA & C++ folks should eventually know, too, since CORBA and
C++ seem to miss each other here.
see above
The Core issue that adds get_orb to CORBA::Object has passed. It would
be good if you were to initiate an issue in the C++ RTF to make the
necessary changes in the C++ pseudo-object mapping section for Object to
incorporate this new operation. While you are at it you might also wish
to throw in the get_component operation, which was added by the
Components specification, and is yet to get into the C++ mapping chapter
(I think).
These might be way easier tor esolve than some of the weightier issues
that you have been struggling with, since these have very
straightforward and non-controversial resolutions
same as proposed resolution for issue #4871
The bit that defines the mapping of local
interfaces to C++ seems to be missing from the specification (ptc/99-10-09 has a change
> based on the CCM specification, which does not appear in
> ptc/01-06-07. )
same as proposed resolution for issue #4160
he spec shows on page 1-13:
class A_var {
public:
// ...
operator const A_ptr&() const
// ...
};
The conversion operator is overloaded for const and non-const.
Now, two issues here:
1) It seems that "const A_ptr &" as the return type for the
first operator is wrong because it really means
"A * const", not "const A *". So, if anything, I think it
would have to be written as
operator const A * &() const
{ return ptr_; } 2) But why provide a const version of the conversion operator
at all? Object references are never passed with a const
qualifier, so why provide this conversion operator? I think
it could simply be deleted without affecting anything.
Proposal: Delete the const version of the conversion operator.
Opinions?
see above
On page 1-3 of the mapping, it says:
For more information about CORBA compliance, refer to the
Preface, "Definition of CORBA Compliance" on page viii.
That preface hasn't existed for a long time now.
Proposal:
Strike this sentence.
Strike this sentence
The C++ mapping says in section 1.10:
An OMG IDL struct maps to C++ struct, with each OMG IDL struct
member mapped to a corresponding member of the C++ struct.
This doesn't say that the order of the struct members in C++ must be the
same as in the IDL. Without that guarantee, code that compares pointers to
members is non-portable. We need a requirement to preserve the order here.
see below
The definition of the _downcast operation generated for valuetypes is
unclear about whether it increments the reference count of the valuetype
before returning the downcasted pointer. I assume by the fact that it
is called _downcast rather than _narrow that it should not increment the
reference count.
Proposal:
Add the following text to the end of the last paragraph in 1.17.3:
"The _downcast function does not increment the reference count of the
valuetype."
Add the proposed text
PortableServer::ValueRefCountBase derives from both CORBA::ValueBase and
PortableServer::ServantBase. This create a problem because ValueBase
contains
virtual ValueBase * _add_ref() = 0;
but ServantBase contains
virtual void _add_ref();
The easy fix would appear to be to change the ValueBase version to return void.
Anyone see a problem with this? (I don't understand why the ValueBase version
currently returns a ValueBase * anyway. Any subtle reason for this that I
am not aware of?)
Change _add_ref() on ValueBase to return void.
In the latest C++ mapping including RTF report changes (ptc/01-06-07) I see no mention of a mapping for CORBA::LocalObject. CORBA 2.4.x 3.7.6.2 states that this is to be specified in each language mapping.
How does it get mapped and, in particular, what are it's memory management semantics and relevant methods?
same as proposed resolution for issue #4160
From orbos/99-07-01 (is there a more up-to-date version with the C++
mapping?)
—
namespace CORBA
{
class LocalObject
: public virtual Object
;
};
Member functions and any data members needed to implement the Object
pseudo-operations and any other ORB support functions must also be
supplied but are not shown.
_add_ref
The _add_ref member function is called when the reference is duplicated.
A default implementation is provided that does nothing. A derived
implementation may use this operation to maintain a reference count.
_remove_ref
The _remove_ref member function is called when the reference is
released. A default implementation is provided that does nothing. A
derived implementation may use this operation to maintain a reference
count, and delete the object when the count becomes zero.
—
This implies that by default a LocalObject will not be reference
counted. That seems counter-intuitive. What was the intention here? It
seems that every application I can think of will want reference counted
local objects – however, to get this at present the application developer
either has to implement the reference counting themselves or inherit
off some proprietary interface.
same as issue #4160
I took a closer look at orbos/99-07-01 to see how I'd have to implement
local objects.
Several questions came to my mind:
1)
what happens if you invoke CORBA::Object::_duplicate on a LocalObject?
2)
how is memory handling done on existing interfaces?
4.1.5 defines a list of interfaces that are changed to local interfaces
e.g. CORBA::Current. How are they supposed to support proper memory
handling when the default implementations of _add_ref/_remove_ref do
nothing?
3)
local interfaces can be implemented by the application programmer, e.g.
PortableInterceptors.
This mapping creates more problems than it solves.
It breaks at least one of the basic rules of OO design: base classes
must not know about subclasses.
Also disabling some methods that are valid on CORBA::Object (e.g. is_a)
is a hint for bad design.
Why not take the same interface 'inheritance' approach as with value
types?
see above
The text added by the CCM spec that describes LocalObject has no
information on how to portably create a local object reference. Since
we have ORB services, like the Security or Transaction service which
must create local object references, and since we have a goal that these
services should be portable as source code between ORBs, we need a
portable way to create a local object reference.
Proposal:
Add a static _create_reference() member function to local object
interface classes:
// IDL
local interface I
;
// C++
... I_ptr;
class I : ...
{ public: I_ptr _create_reference(I *); };
A programmer can then create a new local object reference portably:
class MyI : public I, public CORBA::LocalObject
{ ... };
I_var new_i = I::_create_reference(new MyI());
same as issue #4160
Is the definition of CORBA::Object given the C++ specificaton intended
to be normative? If so then the C++ mapping given in the components
spec won't work since it's clear that LocalObject is supposed to
override the various methods provided on CORBA::Object.
same as issue #4160