On 10/12/07, Marco <mrcekets@gmail.com> wrote:
- if the intersection between "rs" and "ss" is not empty then the new target (i.e. "f") overwrites all the targets related to the signatures included in the intersection.
I hope to have answered to your question.
Yes thanks. I would have read the previous posted policy better. My concern has more to do with a language corner than with overload 'per se'. The whole point is that the 'comparison' used when adding a function to the overload set is different from the 'comparison' used when choosing among the function given a set of arguments, i.e. at call time. In particular at registering time we (but also C++ compiler) uses perfect signature match to test a function signature against the others. As example class A { void foo(char); void foo(long); }; compiles because void(char) and void(long) are different function types. Also void foo1(char); void foo2(long); boost::overload<void(char), void(long)> ov; ov.set(&foo1); ov.set(&foo2); compiles the same. But at call time matching between passed in arguments and function to call is done (in C++) not with "perfect type match" comparison but with "type match + implicit conversions" comparison. That's the reason that instruction; A a; a.foo(7); // compile error! fails with message "ambiguous call, 2 candidates...", not with message 'I don't find a suitable foo()' This ambiguity is, of course, intrinsically present also in 'overload' because registering is done on perfect signature matching, while at runtime class member overloading is used (i.e. implicit conversions are taken in account). Please note that this is good! is what C++ does, the only difference is that with a.foo(7); a compile error is produced and user is warned about this ambiguity that he must resolve explicitly in some way. I didn't know what, in the above case ov(7); should produce. Thanks Marco P.S: In case you are wondering "why didn't he tried?" is that I had some compiler error (probably SFINAE related) and didn't had the time to dig it more.