[boost] Re: Boost signals suggestions

From: Edward Diener (eddielee_at_[hidden])
Date: 2002-12-26 12:31:36

"Douglas Paul Gregor" <gregod_at_[hidden]> wrote in message
news:Pine.BSF.4.31.0212252228420.39075-100000_at_attempto.cs.rpi.edu...
> On Tue, 24 Dec 2002, Edward Diener wrote:
> > One should be able to order the call of slots when connecting them to a
> > signal by saying that a slot should currently come first or last in the
> > overall order without having to manually manufacturer low and high group
> > numbers. This is especially so because disparate slots will not know
about
> > the group numbers of other slots in a signal-slot system.
>
> This could be simulated with an appropriate wrapper around the GroupName
> template parameter. In fact, that is probably the best solution ("don't
> pay for what you don't use" philosophy).

In the doc I am looking at group numbers being passed in the
boost::signal<>::connect function. I was thinking along the lines of
'connect(LAST,function_object)' or 'connect(FIRST,function_object)' perhaps
using negative group numbers in your implementation. I don't know if this
could be done or how much work it would take to do it.

I was surprised that the normal connect, without group numbers, did not have
the calling of slots in the same order as the connecting to a signal.

>
> > One should be able to say sig.disconnect(someslot) in the same way that
one
> > says sig,connect(someslot).
>
> If I could do it, I would. Unfortunately, this requires comparison of,
> e.g., Boost.Function objects which can't generally be done. It _may_ be
> possible to do in limited cases, however.

OK, I see that now. I didn't realize on first reading that disconnecting
occurred by holding on to the return value of the connection and calling
disconnect on it at some later time. Makes sense.

>
> > Combiners are neat but a better explanation of their general
signature(s)
> > would be appreciated. I can just make it out from the examples but I
imagine
> > other users might not be able to.
>
> Noted. I'll introduce more documentation and additional examples
> describing combiners in the near future.

Good. Makes it easier to designer one's own combiners and understand how to
do it..

>
> > Borland has had a simple signal/slot mechanism in C++ Builder
(__closures)
> > at least 7 years previous to MS .NET's incarnation. Just thought you
should
> > know.
>
> Yes, Borland's event/closure mechanism should be mentioned. (It should
> probably also be supported directly in Boost.Function, but that's another
> matter).

Supporting Borland's event/closure mechanism in Boost.Function might mean
supporting an extension to C++. Perhaps Boost doesn't want to do things like
that if they already have a good pure C++ way of doing things like
Boost.Function and Boost.Bind along with Boost.Signal. Also, out of pure
interest, Microsoft's latest VC++ .NET has their own __event mechanism
extension for unmanaged C++ code which is slightly different than their
'delegate' mechanism for managed C++ .NET code ( and C# of course ).

I mentioned Borland only because your notes on other signal/slot
implementations mentioned .NET 'delegates', which is fairly new, and
Borland's '__closure' has been around for many years already. I always find
it bemusing when people, for whatever reason, ignore Borland's earlier
advanced conceptual ideas in favor of Microsoft's similar ones coming many
years afterward. I think you may know that the person responsible for much
of the language underpinnings of .NET and C# is the same person responsible
for much of the design of Delphi/C++ Builder ( Anders Hejlsberg I believe
his name is, although I may have the spelling wrong ). Anyway, all this is
nether here nor there as far as Boost goes.