Boost logo

Boost :

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.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk