orbitcpp: structs, memory managment, etc. (fwd)

[ERDI Gergo <cactus cactus rulez org>]

I'm sending this to the list as well, per Murray's request.

-- 
   .--= ULLA! =---------------------.   `We are not here to give users what
   \     http://cactus.rulez.org     \   they want'  -- RMS, at GUADEC 2001
    `---= cactus@cactus.rulez.org =---'
Ha kleptomániás vagy, lopj rá gyógyszert!

---------- Forwarded message ----------
Date: Fri, 15 Mar 2002 13:53:18 +0100 (CET)
From: ERDI Gergo <cactus@cactus.rulez.org>
To: Murray Cumming <murrayc@usa.net>
Subject: orbitcpp: structs, memory managment, etc.

So I thought I should summarize the issues at hand, so we have some
established base to talk about.

The problem space that orbit/c++ represents is very large, so for starters
let's just worry about three types: objects, atomic types, and structs.
Hopefully, this subset is small enough to fit inside our mind without
"swapping", so we can grasp the whole picture. The rest of this mail
assumes you've read generated/struct_simple-cpp-*.{cc,h} in the
struct-simple test app.

The problem with structures is that for method invocations, there needs to
be a way to write a single method that returns a pointer to an allocated,
valid C representation of the struct. As an example, see the stub for
Test::TestIface::test_in (simplified):

void TestIface::test_in (const ::Test::SimpleStructArg &in_struct,
			 char const *greeting)
{
	Test_TestIface_test_in (_orbitcpp_get_c_object (),
				in_struct._orbitcpp_get_c_struct (),
				greeting,
				_ev._orbitcpp_get_c_object ());
}

You also need to do the reverse (see the skeleton):

void TestIface::_skel_test_in (::PortableServer_Servant _servant,
			       const Test_SimpleStructArg *in_struct,
			       char const *greeting,
		  	       ::CORBA_Environment *_ev)
{
	POA_Test::TestIface *_self = ((_orbitcpp_Servant*)_servant)->m_cppimpl;

	_self->test_in (SimpleStructArg::_orbitcpp_wrap (*in_struct),
		 	greeting);
}

So let's forget about forwarders for now (since, like I said yesterday on
iRC, I don't like them), and think about how it all should work. We need a
structure wrapper class that is able to present a live C view of itself,
but behaves the way the C++ mapping standard of structs said it should
behave. The C view needs to be live to support [in]out arguments.

For the struct itself, there are two ways to store the actual data: either
in C form, or in C++ form. Naturally, when one of these is chosen, the
other one needs to be emulated in some clever way. Here's simplified code
for the SimpleStructArg struct used in the sturct-simple test, for both
cases:

1. Using a C representation as the actual data

class SimpleStructArg
{
	Test_SimpleStructArg c_struct;
	/* ... */
}

2. Using a C++ representation as the actual data (this, of course, is what
the C++ CORBA mapping says)

class SimpleStructArg
{
	/* ... */
public:
	OutputStream_var stream;
	CORBA::Long      number;
	/* ... */
}

And here's a snippet from client.cc that fills a new SimpleStructArg:

	Test::SimpleStructArg test_struct;
	test_struct.stream = stream_ptr;
	test_struct.number = 10;

The problem with (1) is that we need to export an interface to the
end-developer that hides the fact that we're not really doing (2), the
spec-prescribed thing. This is where forwarders came into the play. The
problem with forwarders is that I'm sure we're never get them complete,
and there are always going to be operations on members that prove to be
impossible to do with these forwarder hacks.

The problem with (2) is implementing _orbitcpp_get_c_struct(). While we
could create a new C Test_SimpleStructArg on heap, fill it, and return
some smart pointer to avoid memory leaks, I have no idea how we could make
this C structure 'live' in the sense that modifying its members are
delegated back to the C++ struct (this is needed for out/inout arguments,
to get changes back to the caller). So, even if we have a memory scheme
for freely creating C representations from C++ ones or vice versa, this
issue is not solved.

So this is where I am now. I hope that this, together with the generated
C++ sources in struct-simple, clears up what the current problem is that
I'm looking at to solve.

-- 
   .--= ULLA! =---------------------.   `We are not here to give users what
   \     http://cactus.rulez.org     \   they want'  -- RMS, at GUADEC 2001
    `---= cactus@cactus.rulez.org =---'
Minden általánosítás hamis, ezzel együtt.