Re: assignment, class with many members
On Jul 5, 10:17 pm, viki <viki...@gmail.com> wrote:
We had class X with many members, all of them assignable.
This class was natually assignable with default assign operator
without special treatment.
Then at some point, we added a non-assignable member.
This made a drastic change. We had to add explicit assignment op
with long list of member-by-member assignment. And special
treatment for new pointer member at end of it.
I didn't like this.
Is it possible to write the assignment operator in some shorthand way,
to invoke member-by-member copying with some one-liner trick, and then
single special treatmnt at end ?
Otherwise, it is really easy to forget to add line to assignment op
adding new member to the class... And compiler
won't warn you if it is missing...
Well, there is obviously nothing wrong with your thought process. :)
You're right: things are just as you say they are. There is no help to
be gained from the compiler. The best you can do is partition the
class into an assignable class and a non-assignable class, then use in
inheritance, writing code for the soon-to-be assignable class and
letting the compiler take care of the assignable class.
I regard the distruption of the non-assignable member as a penalty for
deviating from always-assignable principle. Some will disagree, but
striving for always-assignability is a virtue.
In my library of perhaps 120+ C++ utility classes that covers a
spectrum for distributed applications, perhaps 5 of them are
polymorphic, and therefore, fundamentally non-assignable. The rest are
all monomorphic, and no matter how complex the composition, because
the primitive classes are auto-assignable, the composite too is
assignable. I will not hesitate to use operator = against an object
built with a nesting of templates 5 levels deep, if that is what the
Since we're on the subject, the slicing you mention in your parellel
thread is not an option in any other field of engineering: if the
desgin calls for a 7mm bolt, you can use a 5mm bolt in its place
simply because they are both "bolts". There is no choice but to be
specific. It is only in software engineering, where the components are
massless, costless, and composable by indirection; where we are even
allowed to ponder the notion of virtual interchangeability. But I feel
that this is not sufficient reason to be any less specific about
-Le Chaud Lapin-
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]