"Douglas Paul Gregor" <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > 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. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
