Boost logo

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

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, gregod at, cpdaniel at, john at