From: bill_kempf (williamkempf_at_[hidden])
Date: 2002-02-20 12:55:05
--- In boost_at_y..., Douglas Gregor <gregod_at_c...> wrote:
> On Tuesday 19 February 2002 06:19 pm, you wrote:
> That last parameter is a bit vexing, and deserves more
documentation than it
> has. It's a hack to get around the lack of partial ordering of
> templates. Consider:
> I'll add this to the documentation.
Thanks. Now I understand it better. I'm glad you'll be adding
documentation on this one.
> > * The use of other Boost libraries in the test programs is at
> > little suspect. Failures in these other libraries may cause a
> > representation of the suitability of Boost.Signals for a given
> > platform/compiler. Note that I did not evaluate whether or not it
> > was possible/useful to factor these other Boost libraries out of
> > tests, however.
> There are three tests that fall into this category:
> deletion_test.cpp, and random_signal_system.cpp. The former two use
> Boost.Bind (this dependency could be removed without too much
> random_signal_system test relies on the BGL to mimic the signal
> graph, and it would be horrible to rewrite all of that graph-
> Unfortunately, there are platforms (e.g., Borland C++) where the
BGL does not
> work but Signals does. Maybe I can just document around the problem?
Documentation isn't enough, but the solution isn't simple. What
would be ideal is some programmatic means to determine if the
external library is supported by the platform and to skip the test
with no success or failure response in that case.
This issue certainly won't exempt the library from inclusion, IMO,
but we need some sort of solution to this problem for all of Boost.
> > * I wonder if some of the names used in Boost.Signals are too
> > for placing directly in namespace boost.
> I assume you're referring to 'connection' and 'trackable'?
> If so, I think the long-term goal should be to split the Signals
> two: a Tracking library and a Signals library. Everything related
> connections would become a part of the Tracking library, which the
> library would use instead of having its own mechanism. Then it
might not be
> so unreasonable for 'connection' and 'trackable' to be in the Boost
That only works if the "connection" and "trackable" concepts fit in
the cases where the names would conflict. For instance, a sockets
library might have a connection class, and it certainly won't be
compatible. This is one of those sticky wicket situations where no
matter which choice you make it will likely be the wrong one. I
commented only to insure some thought was put into it.
> > * It might be useful to have an overloaded connect() that takes a
> > second parameter of type trackable. This would allow an
> > to derivation from trackable, though at the expense of a more
> > complicated interface. The trade off might be worth it to some,
> > though.
> I think I'd like to think about other alternatives to derivation
> adding these overloads. I guess I'd prefer something like:
> sig.connect(track(some_function_object, a_trackable_object));
> Then the notion of attaching additional trackable objects would be
> from the notion of connection. This goes back to the idea of having
> Tracking library.
I like this idea even if it's not in a Tracking library :).
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk