Re: [orbitcpp-list] Comments about o2cpp

[Andreas K. <ak...@ix...>]

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

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

> 
> 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?

To be honest, my runtime code was largely influenced by yours in some
parts, and most of the things you mention stem from that source (though
at times i called things differently to make it less obvious :)

> 4) Your indentation style is a little bizarre. If we do merge code I'd
> be a little concerned that it would be off-putting to other developers
> (just as my use of python was to you). Have you tried K&R, stroustrop or
> any of the other styles?
> 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>

(erm, that is, given you do the conversion :) 

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.

> 
> Cheers,
> 
> Phil.
> 

cu
andreas