operators and constructor

Question

I have a class that that where I implemented my own constructor, destructor, copy constructor and copy assignment operator.

The class has a core set of members that I have in all of the the above and a set of "state variables" that I added as helpers for some of the methods.

These state variables are never (just because I didn't bother doing it) initialized in the constructor but are initialized before being used.

As such the copy constructor and copy assignment do nothing with them. They just copy the members that I explicitly want.

• Can this be a problem?
• What happens to members that aren't explicitly copied (btw, no pointers in these members)?
  • they are also not initialized in the constructor
• Can this lead to any "hidden" problems?

Cheers André

Answer 1

If those variables are part of the state of the object, then they should be copied. If the variables are not part of the state of the object, they should not be members. A variable is part of the state of the object if the outcome of any function in the interface depends on the value of that variable before the operation starts.

There are few exceptions to the general rule above, in particular there are a few member variables that do not take part on the state of the object (they are usually marked as mutable) as synchronization mechanisms or caches for results from complex operations.

Going back to your problem, from the description it seems that you might be using those members only as a communication mechanism between different member functions. One function in the interface sets the values and then calls other functions that read/modify them. If that is the case, consider passing the variables to the functions as arguments. By using members you are effectively hiding the dependency of the functions towards those values, and at the same time adding a dependency to the class.

This will be much worse if any of the functions in the interface access those members, in which case after the assignment (or copy construction) the source and destination will behave differently, which breaks the assumption that after copy-initialization/assignment the source and destination objects are equivalent.

Basically, from a practical point of view, if those members are not part of the state of the object, you might get away with your current approach, but I would really reconsider the design. If they do take part in the state of the object, you should not by any means avoid copying them.

Answer 2

Can this be a problem?

-if you initilize them before usage and don't forget to release (in case of pointers) i don't see any problems.

What happens to members that aren't explicitly copied (btw, no pointers in these members)? they are also not initialized in the constructor

-they hold garbage

Can this lead to any "hidden" problems?

-no, if you are carefull

But I would suggest you to initilized them in constructor in any case because it will be easier to catch errors that way and that makes you objects always stay in a complete state. For example It is much easier to catch a nullptr pointer then a garbage pointer or a pointer to a deallocated object. Since in first case the program will just crash (dereferencing null pointer is UB, but usually it's just a crash)

Also I would prefere creating local variables for storing intermediate results if possible. If it's not a single method intermediate result - then it's potentially a pit where you might fall if using this variable in other method before it's initialized. In that case it's much better to store zero initialized variable - so you can assert it is in a valid state before making computation on it

Answer 3

From the c++ point of view there is nothing wrong here, but c++ does not protect you from shooting yourself in the foot. In a few months you might be debugging an error that happens only in release builds, and then you will spend few days on finding out why this happens. There are lots of questions why my app works in Release but not in Debug, one of the cause is that debug heap initializes allocated memory.