Overload resolution and copy constructors that take non-const references

[Anthony Williams]

Hi,

Should the following compile, and what should it print?

#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' argument o
f 'std::auto_ptr<_Tp>:perator std::auto_ptr_ref<_Tp1>() [with _Tp1 = int, _Tp
= 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.

Anthony

 

[Branimir Maksimovic]

Hi,

Should the following compile, and what should it print?

Really, I don't know.Sorry to answer question
with question.

#include <memory>
#include <iostream>

void foo(std::auto_ptr<int> x)

Is same as

struct dummy
{
    dummy(std::auto_ptr<int> const&)
    {}

};

void foo(dummy x) ....
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:

....
It isn;t clear to me following example:

class A{
public:
A(){}
A(A&){}
};

A foo(){ return A(); }

int main()
{
A a;
a = foo();
}

g++ gives strange error:

cctor.cpp: In function ‘A foo()’:
cctor.cpp:7: error: no matching function for call to ‘A::A(A)’
cctor.cpp:4: note: candidates are: A::A(A&)
cctor.cpp: In function ‘int main()’:
cctor.cpp:12: error: no matching function for call to ‘A::A(A)’
cctor.cpp:4: note: candidates are: A::A(A&)

I don;t have msvc handy but I think saw somewhere,
that, it compiles without error.
So, perhaps, as g++ wants A(A) this is similar to
your question.
As I never used non const reference copy constructor,
I'm really confused about it's behavior.
It seems to me that compiler writers are too

Greetings, Branimir.

 

[Branimir Maksimovic]

Returning a temporary from 'foo' requires copy-constructing
another temporary (allowed to be optimized away, but semantially
should still be possible).  But the only copy c-tor in 'A' takes
a ref to non-const A.  The ref argument for 'A(A&)' cannot be
bound to the temporary, and that would probably be a clearer
message...

I don;t think that's the case since g++ gives proper
error if, for example, ordinary function foo takes non const reference
to temporary.In this case g++ really wants A(A),
I think. But then again, you may be right, it's just
strange error.

What about
A foo()
{
A a;
return a;
}
A a;
a = foo();
Is compiler obliged to call copy constructor?

.. unless you disable language extensions ..

I think that msvc issues warning if that's the case.
But I am really not sure, could be what you say,
so someone with msvc with disabled extensions
could confirm that this does not compile (second version
of foo that does not returns temporary perhaps).

Greetings, Branimir.

 

[Branimir Maksimovic]

What about
A foo()
{
  A a;
  return a;}

A a;
a = foo();
Is compiler obliged to call copy constructor?

Err, I mean to construct temporary.
It will call copy constructor all right, but
still gives error that it wants A(A)

Greetings, Branimir.

 

[dizzy]

Yes, with assignment it would have to create a temporary (and BTW
I really hope the 'a = foo();' statement is inside some function
otherwise it would be ill-formed). There are no provisions in the
Standard to allow skipping creating a temporary when one would be
required because the expression on the right-hand side of the
assignment operator produces it. The creation of the temporary
is only allowed to be skipped in the case of initialising an object
of the same type:

A a = foo();

I think there was one more case where copy ctor elusion is permited. I would
also like to add that this is special treatement in the standard for these
cases even if the copy ctor has observable behaviour altering code. Because
in general if calling or not calling the copy ctor results in the same
observable behaviour (which is to be expected to most copy ctors that
usually don't have side effects) then the compiler can optimize out the
call anyway no matter of being in such a special case or not

 

[Branimir Maksimovic]

Sorry, I don't know what you mean here.

I had to wait several hours to be sure that this is
not already sent, because I clicked send twice
but google didn't confirmed.
Ok, following program does not compiles:

class A{
public:
A(){}
A(A&){}
};

A foo()
{
A a;
return a;
}

int main()
{
A a;
a = foo();
}

bmaxa@maxa:~$ g++ -Wall cctor.cpp -o cctor
cctor.cpp: In function ‘int main()’:
cctor.cpp:16: error: no matching function for call to ‘A::A(A)’
cctor.cpp:4: note: candidates are: A::A(A&)

Since temporary is constructed by local variable now, I think
that this should compile since A::A(A&) should be called.
But I got same error again.
That is what confuses me. Is compiler right or should
this compile?
Thanks for your time (I'm really rusty with English language)

Greetings, Branimir.

 

[James Kanze]

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' argument o
f 'std::auto_ptr<_Tp>:perator std::auto_ptr_ref<_Tp1>() [with _Tp1 = int, _Tp
= 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, §13.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 ¿conversion¿ 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.