copy ctor

S

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 ?
 
A

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".
 
R

Rolf Magnus

Alf said:
* subramanian:

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.
 
A

Alf P. Steinbach

* Rolf Magnus:
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>
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads


Members online

No members online now.

Forum statistics

Threads
473,769
Messages
2,569,581
Members
45,056
Latest member
GlycogenSupporthealth

Latest Threads

Top