Re: [boost] Boost Overload Documentation

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]>  
wrote:

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

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

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: http://www.opera.com/mail/