Boost logo

Boost :

From: Marco (mrcekets_at_[hidden])
Date: 2007-10-13 06:38:09

On Sat, 13 Oct 2007 08:20:32 +0200, Marco Costalba <mcostalba_at_[hidden]>

> On 10/12/07, Marco <mrcekets_at_[hidden]> 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;
>; // 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 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.

You catched exactly the point. :-)
At call time boost::overload rules are the same followed
by normal (member) function calls.
There is no surprise for the user. What's better ?
I want only to point out that there is nothing odd
in the fact that C++ allows to define both:
> void foo(char);
> void foo(long);
because the compiler doesn't know if the call will
be ambiguos or not, that is:

foo(7); // is ambiguos, but

long l = 7;
foo(l); // there is no ambiguity

Problably you had already argued all that,
but just to be sure :-)

> Thanks
> Marco

You're welcome,
good weekend,

> 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.

That sounds odd to me I used only partial template specialization and
just one enable_if in all my code.
What compiler are you using ?

Using Opera's revolutionary e-mail client:

Boost list run by bdawes at, gregod at, cpdaniel at, john at