Re: libsigc++2 in gtkmm-2.4? (was: Re: [gtkmm] ANNOUNCE: glibmm 2 .3.0)

[Chris Vine <chris cvine freeserve co uk>]

On Sunday 19 October 2003 11:12 am, Martin Schulze wrote:

> I think you don't really understand the situation. libsigc++2 has been
> rewritten from scratch. The idea was not to do some minor improvements
> to the library but to get the maximum out of c++ and to do it "the
> right way", i.e. code as close to the standard as possible. This has
> to do with Karl's initial plans to try and get libsigc++ into boost. 1)
>
> The result is that there are some substantial differences in the API
> (implicit type conversions, unnumbered signal/slot templates,
> accumulators instead of Marshallers, slot iterators, more powerful
> adapters, etc.).
> This doesn't mean that libsigc++2 cannot be made API compatible to
> libsigc++-1.2 but IMO it is much wiser to do this in a compitibility
> header than to put this burden on libsigc++2 itself. However, such a
> compatibility header is only possible when it uses its own namespace.
> I have no intention to break the signal/slot API for gtkmm users until
> at least gtkmm-3.0.

If changing the namespace name is necessary to enable the API compatibility 
layer to be more cleanly implemented, fair enough, and thank you for the 
explanation.  Having the old and new APIs available in different namespaces 
is a good way of doing it.  However, your earlier post said that changing 
naming conventions for its own sake was desirable as bringing the library 
closer to the standard, which in the way in which you said it was bizarre.  
And since I believe that gtkmm takes maintaining API compatibility far too 
lightly (and therefore in my opinion it is unsuitable for large projects or 
professional use, which is a lesson which the GTK+ developers have at least 
taken on board), it sent me the wrong signal(!).

> 1) The reason why this never happened is that the boost people don't
> use m4 to produce human-readable files but insist on their c
> preprocessor magic. Also their own signal/slot library has dependencies
> to other boost stuff in the core parts which would be unacceptable for
> libsigc++ users since boost as a whole is too big a dependency.

This is a problem which blights boost generally.  What's more, the 
dependencies are not documented anywhere, which makes it very difficult to 
take bits of it out and use it separately.  (Lyx now uses boost signals 
instead of libsigc++, and I think boost regex, and it has to carry a 
considerable part of boost around with it in consequence).  There are similar 
problems with boost threads (I did go through a process of isolating what was 
needed to make them work - when I last looked, boost threads also offered 
less functionality than glibmm threads with respect to such things as thread 
pools.)

Chris.