probelm on copy constructor of a derived class.

[shuisheng]

Dear All,

I am wondering how the default copy constructor of a derived class
looks like. Does it look like

class B : public A
{
B(const B& right)
: A(right)
{}
}

Ann also how to access a derived class's base object?

Thanks,

Shuisheng

 

[Rolf Magnus]

Dear All,

I am wondering how the default copy constructor of a derived class
looks like.

There is no "default copy constructor". You probably mean the
compiler-generated copy constructor.

Does it look like

class B : public A
{
B(const B& right)
: A(right)
{}
}

Basically, yes.

Ann also how to access a derived class's base object?

There is nothing special you need to do. The base object is just part of the
derived object.

 

[Victor Bazarov]

I am wondering how the default copy constructor of a derived class
looks like. Does it look like

class B : public A
{
B(const B& right)
: A(right)
{}
}

;

I'd probably force the argument (since 'A' can have another c-tor
that takes a 'B'):

B(const B& right)
: A(static_cast<const A&>(right))
{
}

Ann also how to access a derived class's base object?

To do what? Members that are public and protected are accessible,
unless their names are hidden, in which case you have to help the
compiler resolve them by using qualification (A:. The object
itself is part of '*this' object, and can be obtained using the
standard conversions from derived to base (pointer or reference).

V

 

[Kai-Uwe Bux]

There is no "default copy constructor". You probably mean the
compiler-generated copy constructor.

May I ask what the benefit of such linguistic purity is? Also, I think, the
term "compiler-generated copy constructor" is not better supported by the
standard than the term "default copy constructor". For starters, there is
no requirement that the implementation be a compiler. Thus, at best there
is a "copy constructor with predefined behavior (given by the standard)
that will be generated by the implementation unless there is a
user-declared copy constructor". I think, this copy constructor can
justifiedly be referred to as a "default copy constructor" since it is
present unless the user overrides the default behavior by declaring a copy
constructor to replace it. Also note that the standard does not define the
term "default copy constructor" for any other meaning. So using it within
the C++ community as a name for the copy constructor with predefined
behavior (given by the standard) that will be generated by the
implementation unless there is a user-declared copy constructor will not
create any ambiguity.


Best

Kai-Uwe Bux

 

[Ron Natalie]

May I ask what the benefit of such linguistic purity is? Also, I think, the
term "compiler-generated copy constructor" is not better supported by the
standard than the term "default copy constructor".

The proper term is "implicitly defined" or "implicitly declared" copy
constructor (depending on what you are referring to).

The word "default" when used in conjuction with constructor means can
be called with NO arguments. In fact, you can have a constructor
that is both a copy constructor and a default constructor, although
the utility of it escapes me:

class X() {
X(int i); // non-default constructor
X(const X& that = X(0));
// default and copy constructor both.
};

Also note that the standard does not define the
term "default copy constructor" for any other meaning. So using it within
the C++ community as a name for the copy constructor with predefined
behavior (given by the standard) that will be generated by the
implementation unless there is a user-declared copy constructor will not
create any ambiguity.

Yes there is ambiguity. You might be referring to something above.

Further, you already have to distinguish between "Default" and
"implicitly defined" when you are talking about real default
constructors, so it would be extremely imprecise and confusing
to use the term "default" in one place for a meaning where it
is not useful another.

 

[Kai-Uwe Bux]

The proper term is "implicitly defined" or "implicitly declared" copy
constructor (depending on what you are referring to).

I like that term.

The word "default" when used in conjuction with constructor means can
be called with NO arguments. In fact, you can have a constructor
that is both a copy constructor and a default constructor, although
the utility of it escapes me:

class X() {
X(int i); // non-default constructor
X(const X& that = X(0));
// default and copy constructor both.
};

It's utility also escapes me. That is probably the reason that I was missing
this one.

Yes there is ambiguity. You might be referring to something above.

Really? That seems to be a classical paper doubt. I cannot think of a
natural context where the above would be a reasonable candidate to be the
intended reading.

Anyway, I concede that the standard does indeed provide definition that
allow us to deduce a meaning for "default copy constructor"; and I also
concede that this meaning is never intended when the phrase "default copy
constructor" comes up in real life. That sure is a defect of the
phrase "default copy constructor".

Further, you already have to distinguish between "Default" and
"implicitly defined" when you are talking about real default
constructors, so it would be extremely imprecise and confusing
to use the term "default" in one place for a meaning where it
is not useful another.

You are exaggerating: I read quite a few postings using "default copy
constructor", and there was not a single instance where it was "extremely
confusing".

Although I really like the term "implicitly defined copy constructor", I
still consider "default copy constructor" an acceptable shorthand --
however, that might change when I sleep on it. My current feeling is that
nobody thinks that a default copy constructor is a default constructor.


Thanks a lot

Kai-Uwe Bux

 

[Pete Becker]

May I ask what the benefit of such linguistic purity is? Also, I think, the
term "compiler-generated copy constructor" is not better supported by the
standard than the term "default copy constructor". For starters, there is
no requirement that the implementation be a compiler. Thus, at best there
is a "copy constructor with predefined behavior (given by the standard)
that will be generated by the implementation unless there is a
user-declared copy constructor". I think, this copy constructor can
justifiedly be referred to as a "default copy constructor" since it is
present unless the user overrides the default behavior by declaring a copy
constructor to replace it. Also note that the standard does not define the
term "default copy constructor" for any other meaning. So using it within
the C++ community as a name for the copy constructor with predefined
behavior (given by the standard) that will be generated by the
implementation unless there is a user-declared copy constructor will not
create any ambiguity.

The appropriate term from the standard would be "implicitly-defined copy
constructor." I think "default copy constructor" is confusing, because a
default constructor, unlike a copy constructor, takes no arguments.

--

-- Pete

Author of "The Standard C++ Library Extensions: a Tutorial and
Reference." For more information about this book, see
www.petebecker.com/tr1book.

 

[Rolf Magnus]

May I ask what the benefit of such linguistic purity is?

Mostly the fact that the term "default constructor" is already used in C++,
and the word "default" has a meaning that's completely different from that
in your "default copy constructor".

 

[Gavin Deane]

Although I really like the term "implicitly defined copy constructor", I
still consider "default copy constructor" an acceptable shorthand --
however, that might change when I sleep on it. My current feeling is that
nobody thinks that a default copy constructor is a default constructor.

As you relax this evening before going to sleep, consider that you
probably already understand well the differences between different
kinds of constructors and the circumstances in which the different
kinds might be used (by the programmer or the compiler) and which ones
the compiler might generate and when. Consequently, you are able to
think about and discuss the topic using relatively loose terminology
because you implicitly understand which form of constructor is being
talked about from the context.

Someone learning this part of C++ for the first time presumably does
not have all this background knowledge to aid their understanding.
Insisting on precise terminology can avoid introducing unnecessary
uncertainty and confusion. And if a precise terminology is to be used,
the terminology defined by the C++ standard is the right one to use.

Gavin Deane