RE: Problem with overloaded function selection

RE: Problem with overloaded function selection

[Rupert Wood]

Bjorn Rhode Jensen wrote:

>  I guess, one will have to look in the specs to
> see, who is right in this matter. My gut feeling
> is, that it gcc is right. Conversions and function
> overloading seem pretty othogonal to me. Why should
> two conversions be worse than one conversion in matching
> an overloaded function??

I haven't had a chance to look at the standards either but I did play
with this a little: if you make test accept an A reference instead of an
A object:

    void test(A&) {}

then the GCC problem goes away. I guess the copy construction counts as
a second conversion.

Rup.

Re: Problem with overloaded function selection

[bjorn rohde jensen]

Hi Rupert,

 Rupert Wood wrote:
> 
>     void test(A&) {}
> 
> then the GCC problem goes away. I guess the copy construction counts as
> a second conversion.

 Is that not just ordinary polymorphism through references,
that is conversion of reference to derived to reference to
base class?

Yours sincerely,

Bjorn

Problem with overloaded function selection

[Andrey Pozdeev]

I tried to compile the following example using GCC and MS Visual C++:
-----------
class A
{
    public:
    A(){};
};

class B
{
    public:
    operator double() {return 0L;};
    operator int() { return 0; };
    operator A() { return A();};
};


void test(char){};
void test(A){};

int main()
{
  B b;
  test(b);
  return 0;
}
-------------
Both compilers compiles this example succesfully.
But if we comment line with 'operator double' or with 'operator int' then GCC 
will complain, Visual C++ will not.

What's the matter ?

Andrey.
----
  http://www.rambler.ru

Re: Problem with overloaded function selection

[bjorn rohde jensen]

Hi Andrey,

The conversions

>     operator double() {return 0L;};
>     operator int() { return 0; };

 are equally poor, as one level of user defined
conversions and one level of default conversions
are required to match

> void test(char){};

 Having both conversions causes neither to be
considered, which means that

>     operator A() { return A();};

is the only choice.

 Removing either of
>     operator double() {return 0L;};
>     operator int() { return 0; };

 makes the call
>   test(b);

 ambiguous, since
> void test(char){};

is a candidate through one level of user defined
conversions and one level of default conversions
and

> void test(A){};
is a candidate through one level of user defined
conversions.

 I guess, one will have to look in the specs to
see, who is right in this matter. My gut feeling
is, that it gcc is right. Conversions and function
overloading seem pretty othogonal to me. Why should
two conversions be worse than one conversion in matching
an overloaded function??

Yours sincerely,

Bjorn

Problem with overloaded function selection

[Andrey Pozdeev]

I tried to compile the following example using GCC and MS Visual C++:
-----------
class A
{
    public:
    A(){};
};

class B
{
    public:
    operator double() {return 0L;};
    operator int() { return 0; };
    operator A() { return A();};
};


void test(char){};
void test(A){};

int main()
{
  B b;
  test(b);
  return 0;
}
-------------
Both compilers compiles this example succesfully.
But if we comment line with 'operator double' or with 'operator int' then GCC 
will complain, Visual C++ will not.

What's the matter ?

Andrey.
----
  http://www.rambler.ru

Problem with overloaded function selection

[Andrey Pozdeev]

I tried to compile the following example using GCC and MS Visual C++:
-----------
class A
{
    public:
    A(){};
};

class B
{
    public:
    operator double() {return 0L;};
    operator int() { return 0; };
    operator A() { return A();};
};


void test(char){};
void test(A){};

int main()
{
  B b;
  test(b);
  return 0;
}
-------------
Both compilers compiles this example succesfully.
But if we comment line with 'operator double' or with 'operator int' then GCC 
will complain, Visual C++ will not.

What's the matter ?

Andrey.
----
  http://www.rambler.ru