Michael Fawcett wrote:
On 10/9/07, Dean Michael Berris <mikhailberis@gmail.com> 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