🚀 go-pugleaf

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