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

else

}
----------------------------------------------------------------------

At the line I marked with XXX, I have to set the TypeCode of the
Any.

Summary: Value Boxes inherit from CORBA::ValueBase and
must therefore implement get_value_def(), but
cannot return a sensible value.

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

;

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.

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

;

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), ..."

In the CORBA 2.3 spec, section 6.2, CORBA::AbstractBase is defined as:

module CORBA

;

This implies that the C++ mapping for AbstractBase when used as a
parameter is like this:

class DataOutputStream

;

But section 1.18.1 of the CORBA 2.3 C++ mapping makes it clear that the
signature should be:

class DataOutputStream

;

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)

The assignment operator doesn't free the previous memory, so we get
the leak.

Should the assignment operator be changed?