Boost logo

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