On Thu, 26 Dec 2002, Edward Diener wrote:
> "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.
The type of the group ordering is a template parameter, so group names
need not be numbers. To use a syntax such as the one you suggest, one
could use something like this class template:
enum sandwich_position { FIRST, MIDDLE, LAST };
template<typename T>
class sandwich
{
public:
sandwich(sandwich_position pos) : value()
{
switch (pos) {
case FIRST:
position = --first;
break;
case MIDDLE:
position = 0;
break;
case LAST:
position = ++last;
break;
}
}
sandwich(const T& value) : value(value), position(0)
{
}
bool operator<(const sandwich& other) const
{
return (position < other.position) ||
(position == other.position && value < other.value);
}
private:
T value;
int position;
static int first;
static int last;
};
template<typename T> int sandwich<T>::first = 0;
template<typename T> int sandwich<T>::last = 0;
It's not perfect (integer overflow will be a problem), but the basic
notion is that we can enforce a first/last ordering using a simple
wrapper. It should give the syntax and semantics you need.
> 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.
You're probably not the only person surprised by that :(. That property is
only due to an implementation decision (Signals use a multimap
internally), and I believe it does not represent the "best" interface we
could have. It seems that the underlying slot storage model really needs
to be parameterized: in some cases it is unnecessary to have any slot
ordering, in other cases a simple ordering suffices (e.g., your FIRST and
LAST suggestion), and in yet other cases a more powerful scheme (such as
the one currently implemented) is required.
> > > 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 ).
There is nothing wrong with supporting an extension, so long as we do not
require the extension to use the library effectively. It's merely a
convenience for users that don't mind code that is not fully conformant
C++. Boost.Function could target .NET delegates and the __events as well,
if someone wants to contribute code and/or compiler for it :)
> 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.
Ah. I omitted Borland's __closure mechanism from the documentation only
because it is not a mechanism for multicast callbacks like most
signal/slot systems. It's more like a subset of Function + Bind (or
Lambda) and not very much like Signals.
Doug
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
