[orbitcpp-list] Re: orbitcpp status and question

[John L. <jk...@lu...>]

> Hello,
> 
> I have been interested in C++ bindings for ORBit for sometime now,
> although I don't have a lot of time to keep up-to-date :-(. I have
> three questions.
> 
I hope this won't have to do with velocity of swallows!

> 1. What is the current status of this project? After porting my program
> to use these bindings, I suddenly noticed a lot of important functions
> have error("NYI") (eg. deactivate_object). Any ideas when these
> functions will be implemented?
> 
Alot is still not completed, but most of the POA stuff is. The example
you cite shows that the orbitcpp you are using is older than God, I
think a lot of this stuff is in the latest release. And if it isn't then
it certainly is in CVS. Of couse you also need to have a very late dev
snapshot (or CVS) of ORBit to use bleeding edge orbitcpp. Also do not
install this stuff in /usr or you will be sorry because precompiled
versions of GNOME depend on release ORBit, and will die with the latest
dev ORBit.

As for the pace, things seem to have slowed down. Everyone that writes
free software enjoys it, but most of us have jobs and or other
engagements necessary for survival. I have not heard from Phil Dawes
lately, and I would assume that this is the case with him. The holiday
season has made me awfully busy myself. The IDL compiler has come along
nicely, but there are still some issues with it that I am going to take
a look at over the next week. Hopefully things will settle down for the
other developers so that orbitcpp can pick up the pace.
If after installing CVS orbitcpp and ORBit, you find any NYIs for simple
things, reports to the mailing list are appreciated.

> 2. In C, it is not always safe to copy an object (eg CORBA struct
> containing interfaces and strings) using =, as only a shallow copy is
> created, and you risk freeing nested objects multiple times. Do the
> C++ bindings overload the copy constructor to create deep copies, or
> is this something which has to be done manually by the programmer?
> 
> (this is IMHO one of the hardest aspects of CORBA programming -
> especially with C or C++ - knowing how/when to copy/free/deactivate
> objects - few examples seem to deal with these issues, but rely on
> memory being freed when the program exits).

The goal of this project is to faithfully implement the CORBA C++
mapping.
In the binding spec, deep copying is done sequences and arrays,
and orbitcpp tries to follow the spec.
Now if you (or anyone) finds places where compliant code crashes due to
a buggy copy (shallow where it should be deep), please contact the list.

> 
> 3. Also, I noticed in <URL:http://gnome.dataplus.se/gnomefaq/html/x703.html>
> 
> "...Now, that might be a shared library which got mapped into your
> address space and you are now doing straight function calls into
> it..."
> 
> this is something that really interests me. From
> <URL:http://orbitcpp.sourceforge.net/> it says that a secondary
> objective is to "Allow C and C++ objects in the same address space to
> short-circuit calls (i.e. no on-the-wire marshalling) for maximum
> speed.", which I assume is the same thing.

In someway this is already done, as ORBit itself short circuits the
calls if the server is in the same address space. orbitcpp is merely
wrapping  the stubs and skels of ORBit, and ORBit does this
optimization.

> 
> Previously,I always thought CORBA objects had to run as separate
> processes or threads. I now get the impression that this is not the
> case.  However, how do I construct an object as a shared library that
> is meant to be run from the same address space?
> --
> Brian May <ba...@sn...>

ORBit handles this sort of thing automatically. If the server is in the
same address space, when you deal with the IORs and the client resolves
the IOR, if the servant is in the same space, then the object reference
that the client gets will be "complete", and will have a pointer to the
actual entry point vectors for the servant The stubs check if the
CORBA_Object is complete and call the method directly instead of going
on the wire.  Also, as long as you have the CORBA_Object from the
servant creation, it is totally safe to pass that around in client code,
I believe that the binding allows this. 

John

> 
> --__--__--
> 
> _______________________________________________
> orbitcpp-list mailing list
> orb...@li...
> http://lists.sourceforge.net/mailman/listinfo/orbitcpp-list
> 
> End of orbitcpp-list Digest