By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
445,778 Members | 1,957 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 445,778 IT Pros & Developers. It's quick & easy.

Why hiding copy-constructorin polymorphic classes?

P: n/a
Hi all,

I'm reading (sloooowly, time permitting) "Modern C++ Design" by
Alexandrescu.

In chapter 2.4 "Mapping Integral Constants to Types" (but this is not
directly related to my question) the author writes:
"... T has disabled its copy constructor (by making it private) as a
well-behaved polymorphic class should."

I'm trying to grasp all the possible implications involved in this
design choice, but I need an expert's direction.

Could you explain the problem(s) involved?

TIA

--
Roal Zanazzi
Jun 24 '06 #1
Share this Question
Share on Google+
1 Reply


P: n/a
Roal Zanazzi wrote:
I'm reading (sloooowly, time permitting) "Modern C++ Design" by
Alexandrescu.

In chapter 2.4 "Mapping Integral Constants to Types" (but this is not
directly related to my question) the author writes:
"... T has disabled its copy constructor (by making it private) as a
well-behaved polymorphic class should."

I'm trying to grasp all the possible implications involved in this
design choice, but I need an expert's direction.

Could you explain the problem(s) involved?


Not sure what author means. I never thought [before] that a "well-
behaved polymorphic class" "should" disable its copy-constructor.
Perhaps it's a reference to the fact that any "well-behaved" class
of that nature should only be constructed by a special "factory",
and as such it should definitely prohibit inadvertent copying. All
copying should probably be done using its "clone" method or some
such.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
Jun 26 '06 #2

This discussion thread is closed

Replies have been disabled for this discussion.