0

I understand how auto_ptr works in C++03. It is based on this trick. The trick uses a user-defined conversion to steal the pointer from one object to another when code such as this auto_int p(auto_int(new int())); is written. However, I've several questions in this regard.

  1. Why isn't the compiler-generated copy-ctor called?
  2. Why does the user-defined conversion take precedence over a compiler-generated copy-ctor?
  3. Is there a compiler-generated copy-ctor to begin with?
  4. If not, what language rule suppresses it?
Community
  • 1
  • 1
Sumant
  • 4,286
  • 1
  • 23
  • 31

1 Answers1

0

Why isn't the compiler-generated copy-ctor called?

Because the class already supplied a copy-constructor, a mutable one which is still valid, so the compiler does not generate a default one.

Why does the user-defined conversion take precedence over a compiler-generated copy-ctor?

There is no compiler generated copy-constructor.

Is there a compiler-generated copy-ctor to begin with?

Finally! Nope, there isn't.

If not, what language rule suppresses it?

It's 12.8.2:

A non-template constructor for class X is a copy constructor if its first parameter is of type X&, const X&, volatile X& or const volatile X&, and either there are no other parameters or else all other parameters have default arguments.

And 12.8.4:

If the class definition does not explicitly declare a copy constructor, one is declared implicitly.

K-ballo
  • 80,396
  • 20
  • 159
  • 169
  • As far as I understand copy-ctor must have a const parameter. So you are suggesting that a non-const parameter still makes it a "copy-ctor"? I mean, you can define both if you want. Then which one is the copy-ctor? – Sumant May 25 '12 at 21:10
  • @Sumant: See the edits for the standard references, a copy-constructor needs not have a const parameter. I'd guess if you define both, then overload resolution applies. – K-ballo May 25 '12 at 21:11