Re: [orbitcpp-list] Comments about o2cpp

[Phil d. <ph...@us...>]

Andreas Kloeckner wrote:
> 
> Hi Phil,
> 
> Phil dawes wrote:
> >
> > Hi Andreas,
> >
> > I've got a couple of comments about o2cpp:
> >
> > 1) Licensing issues: Is your runtime LGPL? I could only find the GPL
> > license in your tarball.
> 
> Whoops. I intended it to be all-LGPL. I just looked into it, and at the
> top of the copying file it said
> snip ---------------------------------------------------------------
>                   GNU LIBRARY GENERAL PUBLIC LICENSE
>                        Version 2, June 1991
> 
>  Copyright (C) 1991 Free Software Foundation, Inc.
>                     675 Mass Ave, Cambridge, MA 02139, USA
>  Everyone is permitted to copy and distribute verbatim copies
>  of this license document, but changing it is not allowed.
> 
> [This is the first released version of the library GPL.  It is
>  numbered 2 because it goes with version 2 of the ordinary GPL.]
> snip ---------------------------------------------------------------
> 

Doh! You're right - I don't know how I missed that!

> > 2) A little bug report: GCC 2.95.2 won't compile the basic example
> > because the ORBit C skels declare an 'in' string as const char*, where
> > as o2cpp's stubs declare it without the const. The compiler barfs on the
> > epv function pointers.
> 
> fixed.
> 

Cool. This is an annoying 'feature' of the current ORBit tree which
means you can't have code which works with both the stable ORBit and the
cvs ORBit.

> >
> > 3) There's a lot of code in the runtime. I haven't had a lot of time to
> > look at it in detail, but it looks like a lot of the ORBit-C stuff is
> > duplicated in the orb layer (interface hash lookups, poa implementation,
> > reference counting, etc..).
> > I've already made this mistake in ORBit-C++, and am now in the middle of
> > rewriting the runtime code to take advantage of the built-in binary
> > compatibility between the C and C++ language mappings.
> >
> > If you give the C and C++ types the same binary footprint, then you can
> > convert between them with a reinterpret cast. No need for hash lookups
> > to identify the stub factory, and no need to deal with C++ object
> > lifecycles in the stubs/skeletons and for a new ref counting
> > implementation. The code size is much smaller and the marshalling code
> > is almost non-existant (the only thing that requires stub code at all is
> > marshalling exceptions from the environment structures).
> 
> Wow. After reading this, I ran (I did not walk) to my nearest mapping
> specs. It really seems possible for object references, structs and all
> the primitve stuff.
> 
> I am not quite sure whether it will work for sequences (yet, seems so),
> and I do not really get how you can get around stub factory hashing.
> Could you give me some clues?
> 

orbitcpp-0.25 (from the web page) already uses this feature for
marshalling sequences. You simply have the ORBit C sequence struct as
the only data member of the C++ wrapper  so that both the C and C++
version has the same memory footprint (and no virtual functions -i.e. no
vtable). Then write an operator-new() and operator-delete() to use the
appropriate ORBit C alloc and free functions. 

N.B. you also need a special string class (called String_mgr in
ORBit-C++) for string data members that does deep copies of const char*
strings (because the spec requires it). Since this class has a char* as
the only data member, it is also binary compatible with the C
CORBA_char* string mapping and so works in string sequences. The
String_mgr has an empty operator-delete() because calling CORBA_free()
on the underlying sequence buffer (again via operator-delete) will
implicitly free the strings; if you don't do this, the C++ runtime will
attempt to free them.

You can get round the stub factory hashing by using the same technique
for object stubs. Marshaling an out or return value object ref from C to
C++ means just reinterpret_cast'ing it to the C++ type. (method calls
will work because the compiler will 'do the right thing' because of the
type that it thinks it is).
Narrowing may be a bit more tricky, but it looks as if ORBit already has
an implemented CORBA_Object_is_a() function so that me be all that's
needed.



> > Do you have emacs or indent settings for your C++ indentation style -
> > maybe we could automate the translation between your style and one of
> > the 'standards' (I don't care which one) before it goes into CVS?
> 
> I do have emacs settings for it, but they suck. Indentation is not a
> matter of life or death to me. I like my style of indentation, but I
> have no problem using any other one, if that gives us loads of coders
> <g>
> 

Good. Can you recommend a good C++ indent program? (I've seen a couple
on freshmeat so I might investigate...)

> As you may have noticed, the compiler also does some indentation of its
> output, and of course the output is indented my way. we might have to
> look into that, or remove indentation entirely.

With the python compiler I didn't bother with indenting, and assumed
that I could probably just pass the file through indent or something
after compilation.

Cheers,

Phil.