Re: [orbitcpp-list] Re: cpp branch: CORBA_Object struct hidden?
- From: Sam Couter <sam topic com au>
- To: orbit-list <orbit-list gnome org>
- Cc: orbitcpp-list <orbitcpp-list lists sourceforge net>
- Subject: Re: [orbitcpp-list] Re: cpp branch: CORBA_Object struct hidden?
- Date: Thu, 21 Feb 2002 22:34:34 +1100
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
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]