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:
> http://lists.boost.org/mailman/listinfo.cgi/boost

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.

Regard,
Marco

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

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