Boost logo

Boost :

From: Marco (mrcekets_at_[hidden])
Date: 2007-10-11 07:21:57

On Tue, 09 Oct 2007 19:15:27 +0200, Michael Fawcett
<michael.fawcett_at_[hidden]> wrote:

> On 10/9/07, Dean Michael Berris <mikhailberis_at_[hidden]> wrote:
>> I thought about this, and the only problem is that it assumes that
>> 'include' does not replace the already existing mapping between a
>> function signature and the actual function being 'included'. Consider:
>> void foo(int) { };
>> void bar(int) { };
>> overloads<void(int), void(std::string)> functions;
>> functions.include(&foo);
>> functions.include(&bar);
>> functions(1); // will imply that 'foo' and 'bar' will both be called
>> The above code suggests that functions(1) should call both foo and
>> bar, because both functions are included in the overload set.
> It doesn't suggest that to me. If we were talking normal overload
> sets, it would fail to compile because it was ambiguous. The user is
> trying to introduce an ambiguity with the second include line, and
> he's ignoring the return value, which I presume contains 'false', as
> in, not inserted.
> --Michael Fawcett
> _______________________________________________
> Unsubscribe & other changes:

Not sure, but maybe we're speaking of different "overloads".
The overload implementation that I, Marco Costalba and Dean Michael Berris
are working on is a multi-signature wrapper of boost.function.
The assignment of a functor target mimic the behavior of boost.function:
deduced the matching signature the new functor is assigned and the old one,
if present, is discarded.
At invocation time the implementation relies directly on standard
C++ overloading,
and mimic its behaviour.


Using Opera's revolutionary e-mail client:

Boost list run by bdawes at, gregod at, cpdaniel at, john at