ambiguous definition

[xuatla]

compile error:

test1.cpp:21: error: ISO C++ says that
`T mtd::CDiffOperator::getdp(const mtd::mVector&, long int,
mtd::mBCTYPE) const'
and
`void mtd::CDiffOperator::getdp(mtd::mVector&, const mtd::mVector&,
mtd::mBCTYPE) const'
are ambiguous even though the worst conversion for the former is better
than the worst conversion for the latter

'mtd::mVector' is a class. Why the compile thinks these two functions
are ambigous?

Thanks in advance for the help.

X

[usr.root]

xuatla 写�：

compile error:

test1.cpp:21: error: ISO C++ says that
`T mtd::CDiffOperator::getdp(const mtd::mVector&, long int,
mtd::mBCTYPE) const'
and
`void mtd::CDiffOperator::getdp(mtd::mVector&, const mtd::mVector&,
mtd::mBCTYPE) const'
are ambiguous even though the worst conversion for the former is better
than the worst conversion for the latter

'mtd::mVector' is a class. Why the compile thinks these two functions
are ambigous?

Thanks in advance for the help.

X

it's because the second parament,if you set an int number and it can't
chose to use which fuction

[Greg]

xuatla wrote:

compile error:

test1.cpp:21: error: ISO C++ says that
`T mtd::CDiffOperator::getdp(const mtd::mVector&, long int,
mtd::mBCTYPE) const'
and
`void mtd::CDiffOperator::getdp(mtd::mVector&, const mtd::mVector&,
mtd::mBCTYPE) const'
are ambiguous even though the worst conversion for the former is better
than the worst conversion for the latter

'mtd::mVector' is a class. Why the compile thinks these two functions
are ambigous?

Thanks in advance for the help.

X

Some more detail, including the actual declarations would probably be
of help here. But one way that a member name can be ambiguous in a
derived class, is for that name to appear separately in two base
classes and neither of those two base classes inherit from the other.
Note that it is the "name" that is ambiguous and that causes the error
in this case The error occurs before the compiler attempts to resolve
an overloaded function call. The actual declarations of the functions
whose names are ambiguous are not a factor and have no bearing on the
ambiguity.

An explicit qualification for the name will resolve the ambiguity by
indicating which class or namespace the name can be found.

Greg

[Dave Rahardja]

On Mon, 26 Sep 2005 19:20:35 -0700, xuatla <xu****@gmail.com> wrote:

compile error:

test1.cpp:21: error: ISO C++ says that
`T mtd::CDiffOperator::getdp(const mtd::mVector&, long int,
mtd::mBCTYPE) const'
and
`void mtd::CDiffOperator::getdp(mtd::mVector&, const mtd::mVector&,
mtd::mBCTYPE) const'
are ambiguous even though the worst conversion for the former is better
than the worst conversion for the latter

'mtd::mVector' is a class. Why the compile thinks these two functions
are ambigous?

Thanks in advance for the help.

X

What are the types of the parameters that you are passing to getdp? It may be
that mtd::mVector has a constructor taking a long, and you're trying to pass
parameters of types ([non-const]mtd::mVector, long, mtd::mBCTYPE), and the
compiler can't decide whether to convert the first parameter to a const
mtd::mVector&, or to construct a temporary mtd::mVector, passing a long as a
parameter.

-dr

[xuatla]

Dave Rahardja wrote:

On Mon, 26 Sep 2005 19:20:35 -0700, xuatla <xu****@gmail.com> wrote:

compile error:

test1.cpp:21: error: ISO C++ says that
`T mtd::CDiffOperator::getdp(const mtd::mVector&, long int,
mtd::mBCTYPE) const'
and
`void mtd::CDiffOperator::getdp(mtd::mVector&, const mtd::mVector&,
mtd::mBCTYPE) const'
are ambiguous even though the worst conversion for the former is better
than the worst conversion for the latter

'mtd::mVector' is a class. Why the compile thinks these two functions
are ambigous?

Thanks in advance for the help.

X

What are the types of the parameters that you are passing to getdp? It may be
that mtd::mVector has a constructor taking a long, and you're trying to pass
parameters of types ([non-const]mtd::mVector, long, mtd::mBCTYPE), and the
compiler can't decide whether to convert the first parameter to a const
mtd::mVector&, or to construct a temporary mtd::mVector, passing a long as a
parameter.

-dr

Thanks for all the help.
class mVector
{
private:
int size;
double *ele;
public:
mVector(long int size=1);
mVector(const mVector&);
};

And there's no type change between mVector and long int or int.

To call, I use
mtd::mVector vec;
mtd::mBCTYPE bc;
getdp(vec, 1, bc);

The 2nd argument is a (long)int here.

dr - in your reply, do you mean that the compiler may use the 2nd
argument as a parameter of mtd::mVector's constructor and then cause the
ambiguous problem? I just can't understand why it can automatically
'construct' an object.

Also, the above problem occured in my test. I used mtd::mVector as a
template class. everything is fine. And then after I undefine the
template part and make it a non-template class, the above problem happened.

Thank all again for the help.

X

[Jay Nabonne]

On Tue, 27 Sep 2005 10:24:34 -0700, xuatla wrote:
<snip>

To call, I use
mtd::mVector vec;
mtd::mBCTYPE bc;
getdp(vec, 1, bc);

The 2nd argument is a (long)int here.

Not to the compiler.

1 is an int.
1L is a long int.

- Jay

[xuatla]

my question again:
I wrote a simple code to test the ambigous definition problem:
--------------

#include <iostream>

class A
{
public:
double e;
A(double d=1.0) { e = d; } ;
} ;

class B
{
public:
void func(const A& a1, int i) const // func (1)
{ std::cout << 1 << std::endl; } ;

void func(const A& a1, const A& a2) const // func (2)
{ std::cout << 2 << std::endl; } ;
} ;

int main()
{
A a1, a2;
B b;

b.func(a1, 1); // test (I)
b.func(a1, a2); // test (II)

return 1;
}

---------------

no problem for above code.

But:

if I change func (2) to:
void func(A& a1, const A& a2) const // func (2)
{ std::cout << 2 << std::endl; } ;
i.e., remove the 'const' from the first argument, then compile error
occured for test (I):

testc.cpp:24: error: ISO C++ says that `void B::func(const A&, int)
const' and `void B::func(A&, const A&) const' are ambiguous even though
the worst conversion for the former is better than the worst conversion
for the latter.

No compile error for test (II) (I commented out test (I) and tried (II)
only, passed).

----------------

If I also removed 'const' from func (1), then compile ok.

Anyone knows the reason? Thank you.

X
xuatla wrote:

Dave Rahardja wrote:

On Mon, 26 Sep 2005 19:20:35 -0700, xuatla <xu****@gmail.com> wrote:

compile error:

test1.cpp:21: error: ISO C++ says that
`T mtd::CDiffOperator::getdp(const mtd::mVector&, long int,
mtd::mBCTYPE) const'
and
`void mtd::CDiffOperator::getdp(mtd::mVector&, const mtd::mVector&,
mtd::mBCTYPE) const'
are ambiguous even though the worst conversion for the former is
better than the worst conversion for the latter

'mtd::mVector' is a class. Why the compile thinks these two functions
are ambigous?

Thanks in advance for the help.

X

What are the types of the parameters that you are passing to getdp? It
may be
that mtd::mVector has a constructor taking a long, and you're trying
to pass
parameters of types ([non-const]mtd::mVector, long, mtd::mBCTYPE), and
the
compiler can't decide whether to convert the first parameter to a const
mtd::mVector&, or to construct a temporary mtd::mVector, passing a
long as a
parameter.

-dr

Thanks for all the help.
class mVector
{
private:
int size;
double *ele;
public:
mVector(long int size=1);
mVector(const mVector&);
};

And there's no type change between mVector and long int or int.

To call, I use
mtd::mVector vec;
mtd::mBCTYPE bc;
getdp(vec, 1, bc);

The 2nd argument is a (long)int here.

dr - in your reply, do you mean that the compiler may use the 2nd
argument as a parameter of mtd::mVector's constructor and then cause the
ambiguous problem? I just can't understand why it can automatically
'construct' an object.

Also, the above problem occured in my test. I used mtd::mVector as a
template class. everything is fine. And then after I undefine the
template part and make it a non-template class, the above problem happened.

Thank all again for the help.

X

[John Harrison]

xuatla wrote:

my question again:
I wrote a simple code to test the ambigous definition problem:
--------------

#include <iostream>

class A
{
public:
double e;
A(double d=1.0) { e = d; } ;
} ;

class B
{
public:
void func(const A& a1, int i) const // func (1)
{ std::cout << 1 << std::endl; } ;

void func(const A& a1, const A& a2) const // func (2)
{ std::cout << 2 << std::endl; } ;
} ;

int main()
{
A a1, a2;
B b;

b.func(a1, 1); // test (I)
b.func(a1, a2); // test (II)

return 1;
}

---------------

no problem for above code.

But:

if I change func (2) to:
void func(A& a1, const A& a2) const // func (2)
{ std::cout << 2 << std::endl; } ;
i.e., remove the 'const' from the first argument, then compile error
occured for test (I):

testc.cpp:24: error: ISO C++ says that `void B::func(const A&, int)
const' and `void B::func(A&, const A&) const' are ambiguous even though
the worst conversion for the former is better than the worst conversion
for the latter.

No compile error for test (II) (I commented out test (I) and tried (II)
only, passed).

----------------

If I also removed 'const' from func (1), then compile ok.

Anyone knows the reason? Thank you.

X

Well this stuff is complex and intricate but here goes.

Given

void func(const A& a1, int i) const // func (1)
{ std::cout << 1 << std::endl; } ;

void func(A& a1, const A& a2) const // func (2)
{ std::cout << 2 << std::endl; } ;

and

func(a1, 1); // test (I)

func (2) is preferred on the first argument and func (1) is prefered on
the second argument. Hence it is ambiguous.

But given
void func(A& a1, int i) const // func (1)
{ std::cout << 1 << std::endl; } ;

void func(const A& a1, const A& a2) const // func (2)
{ std::cout << 2 << std::endl; } ;

func(a1, 1); // test (I)

func (1) is preferred on both arguments. Hence it is unambiguous.

john

[xuatla]

John Harrison wrote:

xuatla wrote:

my question again:
I wrote a simple code to test the ambigous definition problem:
--------------

#include <iostream>

class A
{
public:
double e;
A(double d=1.0) { e = d; } ;
} ;

class B
{
public:
void func(const A& a1, int i) const // func (1)
{ std::cout << 1 << std::endl; } ;

void func(const A& a1, const A& a2) const // func (2)
{ std::cout << 2 << std::endl; } ;
} ;

int main()
{
A a1, a2;
B b;

b.func(a1, 1); // test (I)
b.func(a1, a2); // test (II)

return 1;
}

---------------

no problem for above code.

But:

if I change func (2) to:
void func(A& a1, const A& a2) const // func (2)
{ std::cout << 2 << std::endl; } ;
i.e., remove the 'const' from the first argument, then compile error
occured for test (I):

testc.cpp:24: error: ISO C++ says that `void B::func(const A&, int)
const' and `void B::func(A&, const A&) const' are ambiguous even
though the worst conversion for the former is better than the worst
conversion for the latter.

No compile error for test (II) (I commented out test (I) and tried
(II) only, passed).

----------------

If I also removed 'const' from func (1), then compile ok.

Anyone knows the reason? Thank you.

X

Well this stuff is complex and intricate but here goes.

Given

void func(const A& a1, int i) const // func (1)
{ std::cout << 1 << std::endl; } ;

void func(A& a1, const A& a2) const // func (2)
{ std::cout << 2 << std::endl; } ;

and

func(a1, 1); // test (I)

func (2) is preferred on the first argument and func (1) is prefered on
the second argument. Hence it is ambiguous.

Thank you!
If I change func (2) to
void func(A& a1, std::string c) const;
Then it's fine.
It seems that 'class object' & 'int' or 'double' etc can't be
disctincted well enough by compiler. But 'int' & 'string' can be.

I will change my code and give up 'const' for func (1) - I doubt it's
not a good manner. Thanks for all the replies and help.

-X

But given
void func(A& a1, int i) const // func (1)
{ std::cout << 1 << std::endl; } ;

void func(const A& a1, const A& a2) const // func (2)
{ std::cout << 2 << std::endl; } ;

func(a1, 1); // test (I)

func (1) is preferred on both arguments. Hence it is unambiguous.

john

[John Harrison]

xuatla wrote:

John Harrison wrote:

xuatla wrote:

my question again:
I wrote a simple code to test the ambigous definition problem:
--------------

#include <iostream>

class A
{
public:
double e;
A(double d=1.0) { e = d; } ;
} ;

class B
{
public:
void func(const A& a1, int i) const // func (1)
{ std::cout << 1 << std::endl; } ;

void func(const A& a1, const A& a2) const // func (2)
{ std::cout << 2 << std::endl; } ;
} ;

int main()
{
A a1, a2;
B b;

b.func(a1, 1); // test (I)
b.func(a1, a2); // test (II)

return 1;
}

---------------

no problem for above code.

But:

if I change func (2) to:
void func(A& a1, const A& a2) const // func (2)
{ std::cout << 2 << std::endl; } ;
i.e., remove the 'const' from the first argument, then compile error
occured for test (I):

testc.cpp:24: error: ISO C++ says that `void B::func(const A&, int)
const' and `void B::func(A&, const A&) const' are ambiguous even
though the worst conversion for the former is better than the worst
conversion for the latter.

No compile error for test (II) (I commented out test (I) and tried
(II) only, passed).

----------------

If I also removed 'const' from func (1), then compile ok.

Anyone knows the reason? Thank you.

X

Well this stuff is complex and intricate but here goes.

Given

void func(const A& a1, int i) const // func (1)
{ std::cout << 1 << std::endl; } ;

void func(A& a1, const A& a2) const // func (2)
{ std::cout << 2 << std::endl; } ;

and

func(a1, 1); // test (I)

func (2) is preferred on the first argument and func (1) is prefered
on the second argument. Hence it is ambiguous.

Thank you!
If I change func (2) to
void func(A& a1, std::string c) const;
Then it's fine.
It seems that 'class object' & 'int' or 'double' etc can't be
disctincted well enough by compiler. But 'int' & 'string' can be.

Well there is no conversion from int to string so there is no ambiguity
if you have

void func(const A& a1, int i) const; // func (1)
void func(A& a1, std::string c) const; // func(2)

func(a1, 1); // test (I)

It must call func (1).

I will change my code and give up 'const' for func (1) - I doubt it's
not a good manner. Thanks for all the replies and help.

Seems reasonable.

john