|
Boost : |
From: Johan Nilsson (r.johan.nilsson_at_[hidden])
Date: 2007-10-10 02:24:08
Michael Fawcett 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.
I'll persist (yes, yes ... the imfamous bicycle shed): What's wrong with
add:
functions.add(&foo);
functions.add(&foo); // Throws
functions.insert(&foo); // Returns false
functions.replace(&foo); // Overwrites if exists, inserts if not
The above is based on the fact that only one overload of each signature is
stored - analogous to method overloads.
If some kind of multiple dispatch is desired - how about "multi_overloads"
(compare set/multiset, map/multimap).
/ Johan
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk