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: 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: 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.