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;
    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, gregod at, cpdaniel at, john at