|
Boost : |
Subject: Re: [boost] [review] Conversion review ends today
From: Jeffrey Lee Hellrung, Jr. (jeffrey.hellrung_at_[hidden])
Date: 2011-09-01 02:13:03
2011/8/31 Agustín K-ballo Bergé <kaballo86_at_[hidden]>
> On 01/09/2011 2:33, Jeffrey Lee Hellrung, Jr. wrote:
>
>> Create a new class that keeps references to all such function objects, and
>>> > implements implicit conversions to each of them. Then you can use an
>>> > instance of this class as an "overloaded function object".
>>> >
>>>
>> Wouldn't that result in a conversion ambiguity? How would the compiler
>> know
>> which function object to implicitly convert to when invoking operator()?
>>
>
> Of course, that technique only works as long as the function call is not
> ambiguous. I confess not having read the entire thread; I just assumed that
> this was implied by "function overloads", same overload resolution rules
> that work for regular functions do apply in this case.
Hmmm...actually I'm not sure it works even in that case. The following does
not compile for me if I remove the comment from "//x(0);" (MSVC9):
struct X
{
struct Y
{ void operator()(int) const { } };
operator Y() const { return Y(); }
};
int main(int argc, const char* argv[])
{
X x;
//x(0);
static_cast< X::Y >(x)(0);
return 0;
}
Is this what you had in mind, or something else?
- Jeff
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk