🚀 go-pugleaf

In article <9509251126.AA04531@voyager.cs.uni-sb.de>, neis@cs.uni-sb.de (Stefan Neis) says:
>
>        Hi there,
>
>Using g++-2.7.0 (which normally just works great...) I got a strange error
>message today:
>module_div2.C: In function `int main()':
>module_div2.C:26: call of overloaded method `operator <<(order)' is ambiguous
>alg_number.h:418: candidates are: operator <<(ostream &, const module &)
>alg_number.h:174:                 operator <<(ostream &, order &)
>
>I defined classes "order" and "module" and there is a cast - operator which
>makes modules out of orders. 
>
>Do I just not sufficiently understand the details of C++? In my opinion
>the compiler should always be able to recognize, that it should use
>operator <<(ostream &, order &)  to output an order, even if there is a
>cast from order to module, the "cast" from order to order & should be 
>prefered, shouldn't it?
>
>        Cheers,
>                Stefan
>
>P.S.: I know, I didn't supply any code, but to decide, whether this is an
>        bogus error or not, the information should be sufficient...

The compiler's confusion is justified; since it can convert an order to a
module, there is no way of telling which << it should use.

If my understanding of the error message is correct, the compiler is doing
a conversion from order to order& anyway, since there is no operator
<<(ostream &, order)

If you can't see the difference, re-read!  One's a reference, the other isn't.
Try a cast of your order object to order&, i.e instead of

cout << TheOrder  (which is confusing the compiler)

try

cout << (order&)TheOrder  (which should be specific)

The compiler does get extremely pedantic at times!  This should work; I
haven't tried it but if it fails the only other thing you can do is remove
one of the ambiguities.

> P.S.: I know, I didn't supply any code, but to decide, whether this is an
> 	bogus error or not, the information should be sufficient...

The fact that you think that was enough tells me that it was you
who did something wrong :)

Carlo

Eyretel Ltd. (eyretel@fastnet.co.uk) wrote:
: neis@cs.uni-sb.de (Stefan Neis) says:
: >
: >        Hi there,
: >
: >Using g++-2.7.0 (which normally just works great...) I got a strange error
: >message today:
: >module_div2.C: In function `int main()':
: >module_div2.C:26: call of overloaded method `operator <<(order)' is ambiguous
: >alg_number.h:418: candidates are: operator <<(ostream &, const module &)
: >alg_number.h:174:                 operator <<(ostream &, order &)
: >
: >I defined classes "order" and "module" and there is a cast - operator which
: >makes modules out of orders. 
: >
: > (Stuff from my original posting deleted;
: 
: The compiler's confusion is justified; since it can convert an order to a
: module, there is no way of telling which << it should use.

Bjarne Stroustrup states (in "The C++ programming language", p.589):
"[1] Exact match: Sequences of zero or more trivial conversions are
	better than all other sequences...."

	(Note: Conversion from "order" to "order &" is such a so
	called trivial conversion)

So in my understanding, the compiler should detect, that
	"operator <<(ostream &, order &)"
matches better, than "operator <<(ostream &, const module &) which
involves a "user defined conversion", shouldn't it?

Note, that gcc-2.6.3 does not give this error. It produces perfectly
well working code.

: If my understanding of the error message is correct, the compiler is doing
: a conversion from order to order& anyway, since there is no operator
: <<(ostream &, order)

Well, I still assume, that such "trivial conversions" aren't really
counted -- unless that's been changed in the ANSI-draft-standard.
 
: If you can't see the difference, re-read!  One's a reference, the
: other isn't. Try a cast of your order object to order&.

Of course I tried that and it works, but I didn't understand, why this
should be necessary...


	Stefan Neis

In article <44p5gu$jp2@hades.rz.uni-sb.de>,
Stefan Neis <neis@cs.uni-sb.de> wrote:
:Eyretel Ltd. (eyretel@fastnet.co.uk) wrote:
:: neis@cs.uni-sb.de (Stefan Neis) says:
:: >
:: >        Hi there,
:: >
:: >Using g++-2.7.0 (which normally just works great...) I got a strange error
:: >message today:
:: >module_div2.C: In function `int main()':
:: >module_div2.C:26: call of overloaded method `operator <<(order)' is ambiguous
:: >alg_number.h:418: candidates are: operator <<(ostream &, const module &)
:: >alg_number.h:174:                 operator <<(ostream &, order &)
:: >
:: >I defined classes "order" and "module" and there is a cast - operator which
:: >makes modules out of orders. 
:: >
:: > (Stuff from my original posting deleted;
:: 
:: The compiler's confusion is justified; since it can convert an order to a
:: module, there is no way of telling which << it should use.
:
:Bjarne Stroustrup states (in "The C++ programming language", p.589):
:"[1] Exact match: Sequences of zero or more trivial conversions are
:	better than all other sequences...."
:
:	(Note: Conversion from "order" to "order &" is such a so
:	called trivial conversion)
:
:So in my understanding, the compiler should detect, that
:	"operator <<(ostream &, order &)"
:matches better, than "operator <<(ostream &, const module &) which
:involves a "user defined conversion", shouldn't it?
:
:Note, that gcc-2.6.3 does not give this error. It produces perfectly
:well working code.
:
:: If my understanding of the error message is correct, the compiler is doing
:: a conversion from order to order& anyway, since there is no operator
:: <<(ostream &, order)
:
:Well, I still assume, that such "trivial conversions" aren't really
:counted -- unless that's been changed in the ANSI-draft-standard.
: 
:: If you can't see the difference, re-read!  One's a reference, the
:: other isn't. Try a cast of your order object to order&.
:
:Of course I tried that and it works, but I didn't understand, why this
:should be necessary...
:
:
:	Stefan Neis

According to the April 28 1995 Draft:

[13.3.3.1] Implicit conversion sequences

3	Except in the context of a initialization by user-defined conversion
	(13.3.1.3), a well-formed implicit conversion sequence is one of
	the following forms:

	- a standard conversion sequence (13.3.3.1.1)

	- a user-defined conversion sequence (13.3.3.1.2)

	- an ellipsis conversion sequence (13.3.3.1.3)

[13.3.3.1.4] Reference binding

1	The operation of binding a reference is not a conversion, but for the
	purposes of overload resolution, it is considered to be part of a
	standard conversion sequence (specifically, it is the last step in
	such a sequence).

4	A reference binding in general has no effect on the rank of a standard
	conversion sequence, but there are two exceptions:

[13.3.3.2] Ranking implicit conversion sequences

2	When comparing the basic forms of implicit conversion sequences (as
	defined in 13.3.3.1)

	- a standard conversion sequence (13.3.3.1.1) is a better conversion 
	  sequence than a user-defined conversion sequence or an ellipses
	  conversion sequence [. . .]

My interpretation of this is that gcc2.7.0 is wrong...you should submit a
bug report.
-- 
Stephen Gevers
sg3235@shelob.sbc.com