This is the mail archive of the libstdc++@sourceware.cygnus.com mailing list for the libstdc++ project. See the libstdc++ home page for more information.
Nathan Myers <ncm@cygnus.com> wrote:
> > Third of all, -Weffc++ will complain that we have a pointer
> > data member, but do not define our own copy constructor and
> > copy assignment. I am afraid, currently we have no choice but to
> > define them, if we want to have any hope to ever have our headers be
> > -Weffc++ clean. Amen. I am afraid though that this might lead
> > to a performance penalty of some sort. Comments anyone?
>
> I don't give a rip about -Weffc++ cleanliness. Those rules are not
> generally-applicable enough to apply it uniformly to the standard
> library. I don't mind running things past it to see what happens,
> but I refuse to be bound by it. Scott Meyers conflates "OO design"
> with "C++ coding", but they are different processes with different
> rules. When you're not coding an OO design, OO rules don't
> necessarily apply.
I don't think this is really fair to Scott. If I'm understanding you
correctly, the rule in question is "Define a copy constructor and an
assignment operator for classes with dynamically allocated memory," which
is exactly right. He does say at one point in the text that you should
define them "if you have any pointers in your class" but context makes it
clear the issue is pointers to dynamically allocated memory. It has
nothing to do with "OO design" and everything to do with "C++ coding".
If -Weffc++ complains about the case in question, it is a short-coming in
-Weffc++, the sort of thing that happens when you turn simple guidelines
into hard rules.
--
Sol Foster: colomon@ralf.org
Dragons, perhaps the most awesome creatures of all legend, ancient and
thunderous, glide through the atmosphere of stories, flowing like liquid
across the great consciousness to places where dragons do not even
exist, penetrating the very deepest chasms, the most minute cracks of
human culture and there lie, brooding.
-M'Oak