Re: libsigc++2 in gtkmm-2.4? (was: Re: [gtkmm] ANNOUNCE: glibmm 2 .3.0)
- From: Martin Schulze <martin-ml hippogriff de>
- To: Chris Vine <chris cvine freeserve co uk>
- Cc: murrayc usa net, gtkmm-list gnome org
- Subject: Re: libsigc++2 in gtkmm-2.4? (was: Re: [gtkmm] ANNOUNCE: glibmm 2 .3.0)
- Date: Sun, 19 Oct 2003 12:12:13 +0200
Am 2003.10.18 14:27 schrieb(en) Chris Vine:
On Wednesday 15 October 2003 8:18 am, Murray Cumming Comneon com
> From: martin-ml hippogriff de [mailto:martin-ml hippogriff de]
> > Well first of all sorry for answering this late.
> > As to changing back to "SigC::Slot" in libsigc++2 I must say
> > that I would really prefer a compatibility header:
> Yes, that would be OK if it can be done. We would have
> #ifndef LIBSIGC_DISABLE_DEPRECATED
> Around the API.
Changing the API by going from initial upper case letters for
to lower case letters seems to me to be a self-indulgence which should
resisted (but I have no expectation that my view will have any effect,
previous exchanges of view on other API breakage issues).
However, if initial capitals for namespaces causes aesthetic problems
maintainer why not just use a namespace alias, so allowing either to
without having to mess around with configure time definitions:
namespace sigc = SigC;
in the relevant header files.
Of course this will not work if it is also proposed to change all type
forming part of the public interface to initial lower capitals, but
could be dealt with by using the equivalent typedefs and thus avoid
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
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.
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.
] [Thread Prev