copy ctor

[subramanian]

Consider the code fragment:

class Test {
public:
Test(const Test &temp);
...
};

....

In the copy ctor, we put "const". I understand that by putting const,
we do not intend to modify the parameter. Is there any other reason for
putting const in the copy ctor ?

[Alf P. Steinbach]

* subramanian:

>
In the copy ctor, we put "const". I understand that by putting const,
we do not intend to modify the parameter. Is there any other reason for
putting const in the copy ctor ?

With the current standard it allows you to copy a temporary, since a
temporary can be bound to a reference to const, but not to a reference
to non-const.

Note, by the way, that there are four possible copy constructors for a
class T, only two of which has reference to const argument:

T( T& );
T( T const& );
T( T volatile& );
T( T const volatile& );

AFAIK there isn't any reason, ever, to use 'volatile' here; it's just a
consequence of an attempt to unify the rules for 'const' and 'volatile'
qualifications, so-called "cv qualification".

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[Rolf Magnus]

Alf P. Steinbach wrote:

* subramanian:

>>
In the copy ctor, we put "const". I understand that by putting const,
we do not intend to modify the parameter. Is there any other reason for
putting const in the copy ctor ?

With the current standard it allows you to copy a temporary, since a
temporary can be bound to a reference to const, but not to a reference
to non-const.

Note, by the way, that there are four possible copy constructors for a
class T, only two of which has reference to const argument:

T( T& );
T( T const& );
T( T volatile& );
T( T const volatile& );

Actually, there is an infinite number of possible copy constructors. A
constructor with more than one argument can still be a copy constructor if
all the following arguments have default values.
The standard (at lest the 98 version) also seems inconsistent about what is
allowed for the first parameter to make it a copy constructor. §12.1/10
only mentions T& and const T&, while 12.8 also mentions the versions with
volatile.

[Alf P. Steinbach]

* Rolf Magnus:

Alf P. Steinbach wrote:

>* subramanian:

>>In the copy ctor, we put "const". I understand that by putting const,
we do not intend to modify the parameter. Is there any other reason for
putting const in the copy ctor ?

With the current standard it allows you to copy a temporary, since a
temporary can be bound to a reference to const, but not to a reference
to non-const.

Note, by the way, that there are four possible copy constructors for a
class T, only two of which has reference to const argument:

T( T& );
T( T const& );
T( T volatile& );
T( T const volatile& );

Actually, there is an infinite number of possible copy constructors. A
constructor with more than one argument can still be a copy constructor if
all the following arguments have default values.
The standard (at lest the 98 version) also seems inconsistent about what is
allowed for the first parameter to make it a copy constructor. §12.1/10
only mentions T& and const T&, while 12.8 also mentions the versions with
volatile.

Yes. I once suggested in [comp.std.c++] to make the former para just
refer to the latter. There's also the question of tidying up the
wording for consistency, i.e. same kind of wording for default
constructor and copy constructor, and possibly elsewhere, especially
since the different wording might seem to allow T(...) as default
constructor but not T(T const&,...) as copy constructor. E.g. consider

struct T
{
T(){};
T(T const&, ...){}
};

int main()
{
T x(( T() ));
}

It might seem that the second constructor isn't a copy constructor, but
in fact it has only one parameter: the ellipsis is not regarded as a
parameter (it all hinges on the meaning of "parameter" , whereas that's
not a problem with the wording adopted for the default constructor).

Everybody agreed that some cleaning up of the wording would be a good
idea, but AFAIK nothing more came out of it.

The exclusion of templated copy constructors in §12.1/10 is also problem
wrt. to what "copy constructor" really means in the standard.

Perhaps that's what stands in the way, that the whole thing is a bit
complicated.

Let's just hope the OP is not now hopelessly confused... <g>

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?