Re: cpp: Wrapping C server implementations.

[murrayc t-online de (Murray Cumming)]

On Thu, 2002-04-18 at 00:43, Michael Meeks wrote:
> On Tue, 2002-04-16 at 14:32, Murray Cumming wrote:
> > I'm trying to think about how to wrap libbonobo*'s various server
> > implementations for C++. These seem to be anything that derives from
> > BonoboObject. They implement an interface and provide a sugary C API.
> > For instance, BonoboControlFrame in libbonoboui.
> 
> 	Right.
> 
> > Obviously the C++ equivalent should inherit from the generated 
> > POA_Bonobo::ControlFrame skel, just like a real C++ CORBA server.
> 
> 	Why ?

Because a server in C++ should look like a server in C++. But this is
one of the assumptions that we can fall back to.
 
> > But by
> > doing that we are actually implementing another server. We'd then have 2
> > CORBA servers "running" (I'm not sure exactly what that means), with the
> > C++ server delegating to the C server. That seems odd.
> 
> 	Hmm; it would be far, far better to inherit from the BonoboObject, and
> hook the skel code to proxy the BonoboObjects' CORBA_Object rather than
> a new object - if that's possible ? is it feasible to construct a C++
> skel from a C CORBA_Object ?

I don't think that's practical. For instance, we generally wrap
GObject/GtkObject stuff by having a GObject* member instance that's
instantiated in the C++ constructor. We can't derive directly because
the C++ compiler has no way to know that the underlying C instance can
only be allocated by calling a certain C function.

Also, we might lose other stuff that's automatically provided by C++
servers. This might just be the _this() method, or there might be other
stuff that a newbie like me doesn't know about.

I don't expect you to understand all of the C++ aspects of this, but
it's worth writing it down anyway because you might happen to spot any
rampant CORBA-newbie wrongness.

I've started to do this as a server-in-a-server, with the C++ server
delegating to the C server. We worry that this might have huge
performance problems, but we blindly hope it's OK because it's all
in-proc.

I tried to optimise this by accessing the C server's _impl functions
directly instead of going through a client reference, but I wasn't sure
how to get the first PortableServer_Servant argument. 

Here's some simple code snippets:

The constructor:

Control_EasyImpl::Control_EasyImpl(Gtk::Widget& widget)
{
  //Instantiate a server that implements this CORBA interface, using the
C Bonobo helper,
  //then implement this server in C++, delegating all of the methods to
the C server:
  gobject_ = bonobo_control_new( widget.gobj() );

  //Get a client reference:
  //Use the C++ mapping because it's simpler.
  corbaref_ =
::_orbitcpp::stub::Bonobo::Control::_orbitcpp_wrap(BONOBO_OBJREF(gobject_));
}

An implementation of a CORBA method:

void Control_EasyImpl::activate(CORBA::Boolean activate)
  throw (CORBA::SystemException)
{
  return corbaref_->activate(activate);
}


-- 
Murray Cumming
murrayc usa net
www.murrayc.com