Re: [sigc] Re: [gtkmm] libsigcx and gtkmm 2.4

[Daniel Elstner <daniel elstner gmx net>]

Am So, den 13.06.2004 um 12:57 Uhr +0200 schrieb Christer Palm:
> > Daniel Elstner wrote:
> > 
> >> When I thought about adding signal parameter support to Glib::Dispatcher
> >> a while ago, I played with the idea of making Glib::Dispatcher provide a
> >> low-level interface for sending raw blocks of memory through the pipe.
> >> On top of that there could be some kind of plugin interface that
> >> requires you to implement two functions that convert your data to raw
> >> memory and back again.
> > 
> > 
> > Isn't this exactly what CORBA, for example, is all about?
> > While it
> > 
> 
> Whoops, it got chopped off... Here we go again.
> 
> While I think that this would be great for a inter-process or 
> inter-network communication mechanism, I don't think it's a very good 
> idea for inter-thread communication.
> 
> Serializing/deserializing is usually very inefficient and is also 
> extremely hard to do in a C++ environment. You'd need to know how to 
> marshal each and every class in the objects type as well as containment 
> hiearchy. Leaving all this to the implementor of the top-level class 
> will definitely break the basic OO principles, and will be bound to be 
> very error-prone.

Wrong.  Locking is inefficient.  Serializing is much faster unless
you're talking about serializing a whole file or something.  And right,
you do need to know how to serialize each and every object you use.
Just as you'd need to know details about the implementation of a class,
such as "does it use reference counting internally?" before you can be
sure that simply locking a mutex actually works.

--Daniel