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

;

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:

• 1.1.14
• at the beginning of 1.7
• in the footnote on page 1-29
• at the end of 1.10
• at the end of 1.12
• at the beginning of 1.13.3
• at the end of 1.16.10
• at the end of 1.20
• at the end of 1.23
• at the beginning of 1.26
• 1.31.3
• 1.42.1

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

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

;

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

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:

• Microsoft's Visual C++ 6.0 (SP3)
• CygWin's gcc v3.2

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

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?

• does it call _add_ref on the local object (as the spec seems to say in
  4.1.2)?
• is it allowed to return a copy of the object?

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.

• what happens if my _duplicate operation on CORBA::Object creates a
  copy (which is legal) and my implemenation of the local interface
  contains some state?

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

;

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