Rule of Thumb:Copy ctor,assingment opr

[utab]

Dear all,

How do experienced programmers using this group use the rule of
thumb,namely copy ctor, assignment operator, and dtor.

example

if the class does not need them dont use and define them

use them but dont define them (for future revisions of the class as
placeholders)

or...

One more resource question on default and value iniliatization, I am
still looking references to read on these topics.

Regards,

 

[red floyd]

Dear all,

How do experienced programmers using this group use the rule of
thumb,namely copy ctor, assignment operator, and dtor.

That's the Rule of *THREE*, not the Rule of thumb.

example

if the class does not need them dont use and define them

use them but dont define them (for future revisions of the class as
placeholders)

If I use them, I define them, even if they're trivial. That way I know
exactly what's happening, rather than relying on compiler magic.
Otherwise, I explicitly hide them.

 

[Richard Herring]

That's the Rule of *THREE*, not the Rule of thumb.


If I use them, I define them, even if they're trivial. That way I know
exactly what's happening, rather than relying on compiler magic.
Otherwise, I explicitly hide them.

The compiler is more reliable than I am at keeping track of every single
data member of a large class. If they are trivial, I already know what
the "compiler magic" is, so why add clutter to the definition and risk
getting it wrong?

If the OP really does need to define them, he should consider defining a
swap function as well, and then defining the assignment operator in
terms of the copy constructor using the copy-and-swap idiom.

 

[Gavin Deane]

That's the Rule of *THREE*, not the Rule of thumb.



If I use them, I define them, even if they're trivial. That way I know
exactly what's happening, rather than relying on compiler magic.

That makes no more sense to me than "If I use a string class I define
one, rather than relying on <string> magic".

If the compiler "magic", which is no more magic than any other correct
compiler behaviour, does the right thing then let it. That's what it's
there for. If you write them yourself, you add nothing but risk
introducing bugs and confusing other programmers. Not to mention the
loss of your own time.

Gavin Deane

 

[Jim Langston]

Dear all,

How do experienced programmers using this group use the rule of
thumb,namely copy ctor, assignment operator, and dtor.

example

if the class does not need them dont use and define them

use them but dont define them (for future revisions of the class as
placeholders)

or...

One more resource question on default and value iniliatization, I am
still looking references to read on these topics.

Regards,

As soon as I declare any pointer or reference in a struct/class I hide the
copy and assigment operators by declaring them private. I usually find it
non trivial to create the copy and assignemnt operators as I'm usually
loading some resource into a pointer that is not easy to duplicate. By
hiding them if I try to use them I'll get a compilation error.

Personally, I find it easier to use just pointers for these types of classes
when I stick them in vectors. It would probably be easier for me to use
smart pointers, but for some unknown reason I just don't trust smart
pointers to be smart enough, so do them manually.

What I normally do is start out any class as a struct if it is POD. As soon
as I need to create an initialization list, I change it to a class and
create a dtor.

 

[Dervish]

if the class does not need them dont use and define them

use them but dont define them (for future revisions of the class as
placeholders)

IMHO good rules are:
1. If class should not be copied by application logic - declare copy
ctor and operator =() as private and do not provide any implementation.
2. copy ctor and operator=() should be both either defined or not
defined.

 

[utab]

Dear all,

How do experienced programmers using this group use the rule of
thumb,namely copy ctor, assignment operator, and dtor.

example

if the class does not need them dont use and define them

use them but dont define them (for future revisions of the class as
placeholders)

or...

One more resource question on default and value iniliatization, I am
still looking references to read on these topics.

Regards,

I see that thereis still no compromise on this issue. I asked this
question after reading related parts from effective C++. I think that
if no dynamic allocation takes place then it is not wise to use these
because the compiler synthesizes them for you but even then maybe there
could be problems concerning memberwise and bitwise copy.

Still not an exact clarification, are there others to comment on the
subject?

Regards,

 

[Roland Pibinger]

As soon as I declare any pointer or reference in a struct/class I hide the
copy and assigment operators by declaring them private. I usually find it
non trivial to create the copy and assignemnt operators as I'm usually
loading some resource into a pointer that is not easy to duplicate. By
hiding them if I try to use them I'll get a compilation error.

This is a good rule of thumb. From the conceptual point of view you
implement object types (as opposed to value types) that way. For
object types copying makes no sense.

Personally, I find it easier to use just pointers for these types of classes
when I stick them in vectors. It would probably be easier for me to use
smart pointers, but for some unknown reason I just don't trust smart
pointers to be smart enough, so do them manually.

Trust you instincts. 'Smart' pointers create more problems than they
solve.

What I normally do is start out any class as a struct if it is POD. As soon
as I need to create an initialization list, I change it to a class and
create a dtor.

In C++ you hardly ever need to implement a copy constructor and an
assignment operator. Both are usually either trivial for value types
or you make them private and leave them unimplemented for object
types.

Best wishes,
Roland Pibinger

 

[Howard Hinnant]

The compiler is more reliable than I am at keeping track of every single
data member of a large class. If they are trivial, I already know what
the "compiler magic" is, so why add clutter to the definition and risk
getting it wrong?

It can be even worse than that. Defining what would otherwise be
trivial members (copy, assignment or destructor) can lead to a
performance loss. Generic code (such as std::vector) can make
significant optimizations if it knows that its value_type has trivial
special members (which it can detect through the new <type_traits>
library. As soon as you define these special members, they are no
longer trivial (even if they do the same thing as the compiler generated
variant), and generic code must use larger and slower code to ensure
that everything works correctly.

-Howard

 

[Richard Herring]

I see that thereis still no compromise on this issue. I asked this
question after reading related parts from effective C++. I think that
if no dynamic allocation takes place then it is not wise to use these
because the compiler synthesizes them for you but even then maybe there
could be problems concerning memberwise and bitwise copy.

The problems are usually related to resource ownership: it's not so much
how the low-level copy takes place, but what it means.

Still not an exact clarification, are there others to comment on the
subject?

Another comment: if your class must be copied, but has members whose
semantics mean that you _can't_ use the compiler-generated functions,
consider delegating the problem: either add to the member's class
appropriate copy/assign functions or wrap it in a new class that has the
same effect. Apply the same technique recursively to the members'
members until the non-standard copy semantics are isolated in the
smallest possible space.