Re: [orbitcpp-list] Typecode implementation

[Phil D. <ph...@li...>]

Gordon Miller wrote:
> 
> Since I've started down the Any path, I'll go ahead and look at
> implementing typecode.  I'm very familiar with what a typecode is and
> does, but I'm going to have to look at the Typecode support in orbit to
> see how they do things and then how to implement it.  I'll probably work
> on the pyIDL stuff first just to get things to compile and then work on
> the C++ classes that wrap the orbit functions.  I'll get working on that
> tonight or tomorrow morning.  pyIDL will probably be done within a
> couple days (Thursday ideally) and then I'll move to the C++ classes.
> As you stated Phil, the Any implementation will rely on Typecode.
> 

Hi Gordon,

Here's some info and tips for wrapping the ORBit C stuff in C++:

CORBA_free
----------
ORBit has it's own memory management scheme which allows all CORBA types
to be deep free'd using CORBA_free() (which is a requirement of the
CORBA C mapping spec - a bit of a crap one IMHO). It does this by
imbedding a structure in memory directly behind the type when it is
created, which contains information about the type and a function
pointer to a destructor. When you call CORBA_free it swizzles the
pointer to get the structure.

Wrapping C types in C++
-----------------------
If at all possible, strive to make the C++ type binary compatible with
the eqivalent C type. Ideally, this means that the type can be new'd in
C++, and then CORBA_free()'d in C. This makes the marshalling trivial
and fast (a simple reinterpret_cast does the trick!). I've achieved this
in all the complex CORBA types I attempted except objref using the
following technique:

1) Define the C++ class with one data member - the C type. Base all the
functions around this.
2) Don't implement any virtual functions, otherwise the C++ compiler
will create a vtable, and all bets are off. (This is the reason for not
being able to do it for objref, which requires inheritance)
3) Write an operator new and delete to use the equivilent ORBit C
function for creation and CORBA_free for deletion (and doing the
appropriate reinterpret casting).

I think think this is alright with regards to portibility, since a
compliant c++ compiler must lay out C++ structs to be binary compatible
with C ones. At the moment I'm assuming that cpp classes have the same
binary layout as cpp structs, however I'm not sure whether this is
actually in the language spec anywhere.

Hope this helps with your typedef porting efforts,

Phil.