Re: [orbitcpp-list] Re: cpp branch: CORBA_Object struct hidden?

[Sam Couter <sam topic com au>]

Murray Cumming <murrayc@t-online.de> wrote:
> That's exactly what I was looking for. I think it means that we don't
> need to have a 1-to-1 mapping of C and C++ stub instances. So, we

The way ORBit-C++ worked previously, there was a direct 1-to-1 mapping
of C and C++ stub instances because they were the same piece of memory.
C++ objects were binary compatible with the C objects, and could be cast
back and forth with no problems. The new and delete operators were
overloaded to use the C allocation functions, so however you got your
piece of memory, it was the same whether you called it C or C++.

> shouldn't need that g_object_set_qdata()-like thing anymore. That should
> have been obvious to me - this is CORBA, after all.

I think I'm missing something here, because I'm not sure what the
g_object_set_qdata()-like call would be used for.

> More thinking aloud, in case anybody cares or objects:
> 
> And I see no great advantage in inheriting from CORBA_Object, so I'll
> look at making the CORBA_Object a member of CORBA::Object instead. That
> conveniently solves the hidden CORBA_Object declaration issue too.

One of the original goals of the ORBit-C++ project was that a programmer
should be able to treat a C++ object as the C equivalent, and any C
objects as the C++ equivalent. This goal meant that, amongst other
things, the C++ object was the exact same size of the C object. This was
usually achieved by having a single member variable, which was the C
struct representing the type. Not a pointer to the struct, but the
struct itself.

Now, let me join you in this aloud-thinking stuff:

If the CORBA_Object struct is hidden (and may change size or shape),
then the size and shape of CORBA::Object can't rely on it, which means
the C <-> C++ interoperability goal is out the window.

Now, I don't know if this is a bad thing or a good thing. I would
imagine that C++ is the only binding where the (mis)features of the
language allow such shenanigans, and so we would lose nothing that other
language bindings have. But being able to use the C binding for things
where the C++ binding is lacking (eg, Policies) is nifty.

I can't think of any way of retaining this C <-> C++ compatibility if
the CORBA_Object struct definition remains private and subject to
change. But I'm certainly not a C++ expert by any stretch of the
imagination.

So... thoughts, anyone?
-- 
Sam "Eddie" Couter  |  mailto:scouter@bigpond.net.au
Debian Developer    |  mailto:eddie@debian.org
                    |  jabber:sam@jabber.topic.com.au
OpenPGP fingerprint:  A46B 9BB5 3148 7BEA 1F05  5BD5 8530 03AE DE89 C75C

PGP signature