On May 7, 11:44 am, Anthony Williams <anthony_w....@[EMAIL PROTECTED]
> wrote:
> Should the following compile, and what should it print?
I'm not sure, but it's a very delicate point, and it wouldn't
surprise me if a lot of compilers get it wrong.
> #include <memory>
> #include <iostream>
> void foo(std::auto_ptr<int> x)
> {
> std::cout<<"copy"<<std::endl;
>
> }
> struct dummy
> {
> dummy(std::auto_ptr<int> const&)
> {}
> };
> void foo(dummy x)
> {
> std::cout<<"dummy const ref"<<std::endl;
> }
> int main()
> {
> std::auto_ptr<int> const x(new int);
> foo(x);
> }
> MSVC 9.0 and g++ 4.3 disagree.
> MSVC compiles it and prints "dummy const ref", which is what I expected.
> g++ refuses to compile it, saying that:
> test_copy.cpp: In function 'int main()':
> test_copy.cpp:23: error: passing 'const std::auto_ptr<int>' as 'this'
argu=
ment o
> f 'std::auto_ptr<_Tp>::operator std::auto_ptr_ref<_Tp1>() [with _Tp1 =3D
i=
nt, _Tp
> =3D int]' discards qualifiers
> test_copy.cpp:23: error: initializing argument 1 of 'void
foo(std::auto_=
ptr<in
> t>)'
> implying that it chose the first overload of foo.
Both functions are found during lookup, and are part of the
initial set of candidate functions. The question is whether the
first is viable. It meets the first condition (it can be called
with a single argument). The exact wording it:
Second, for F to be a viable function, there shall exist
for each argument an implicit conversion sequence
(13.3.3.1) that converts that argument to the
corresponding parameter of F. If the parameter has
reference type, the implicit conversion sequence
includes the operation of binding the reference, and the
fact that a reference to non-const cannot be bound to an
rvalue can affect the viability of the function (see
13.3.3.1.4).
The question hinges on whether there is "an implicit conversion
sequence" which converts an std::auto_ptr<int> const to an
std::auto_ptr<int>. And I think that the standard is far from
clear about this. In particular, =A713.3.3.1 says:
When the parameter type is not a reference, the implicit
conversion sequence models a copy-initialization of the
parameter from the argument expression. The implicit
conversion sequence is the one required to convert the
argument expression to an rvalue of the type of the
parameter. [Note: when the parameter has a class type,
this is a conceptual conversion defined for the purposes
of clause 13; the actual initialization is defined in
terms of constructors and is not a conversion. ] Any
difference in top-level cv-qualification is subsumed by
the initialization itself and does not constitute a
conversion. [Example: a parameter of type A can be
initialized from an argument of type const A. The
implicit conversion sequence for that case is the
identity sequence; it contains no =BFconversion=BF from
const A to A.] When the parameter has a class type and
the argument expression has the same type, the implicit
conversion sequence is an identity conversion. When the
parameter has a class type and the argument expression
has a derived class type, the implicit conversion
sequence is a derived-to-base Conversion from the
derived class to the base class. [Note: there is no
such standard conversion; this derived-to-base
Conversion exists only in the description of implicit
conversion sequences.] A derived-to-base Conversion has
Conversion rank (13.3.3.1.1).
Note that there is actually a contradiction in this text for the
case which interests us: "the implicit conversion sequence
models a copy-initialization of the parameter from the argument
expression", which bans the initialization of an std::auto_ptr<>
from an std::auto_ptr<> const, and "Any difference in top-level
cv-qualification is subsumed by the initialization itself and
does not constitute a conversion", which explicitly says that
the case in question does *not* constitute a conversion, i.e.
that it is treated as an exact match.
Of course, once the first function has crossed the line and is
considered viable, it's obviously the "best viable function"; if
it is to be eliminated, it can only be because it isn't viable.
Globally, I think that the intent is probably that the function
shouldn't be viable, since the argument cannot be used to
initialize a variable of the type of the argument. But the
wording in the paragraph I just cited seems contradictory enough
that it can be interpreted either way.
--
James Kanze (GABI Software) email:james.kanze@[EMAIL PROTECTED]
en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34
|
