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

[Christer Palm <palm nogui se>]

Daniel Elstner wrote:
> Am So, den 13.06.2004 um 12:57 Uhr +0200 schrieb Christer Palm:
> > 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.

I would say that this is quite dependent on the locking scheme, lock 
contention potential, lock wait time, the complexity of the object 
beeing serialized and whether you are talking of efficiency in terms of 
lead time, consumption of CPU cycles or code size. But I happily stand 
corrected if you could back that claim up.

>  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.

Not only do you need to know how to serialize the object, but you also 
need the code to do it. And if you don't have it, apart from actually 
writing it - where would it go? It should, and may have to go into the 
classes themselves, because of OO principles and the potential need to 
access private members.

As much as I would like to have that in C++, it just isn't there. It 
seems to me that attempting to fix that in Glib just so that you could 
do cross-tread signalling is just way over the top.

I do agree that passing or sharing objects safely between threads, or 
indeed, just making a copy of an object has similar limitations in C++. 
However, we're not trying to solve that problem. The user _would_ still 
have to take necessary precautions.

If your stance is that you'd rather avoid doing something altogether if 
there's no way of making it foolproof, then so be it.

--
Christer