Copy constructors and base Classes

Hi everyone,

For the past few days I've been attempting to answer this personal mystery through what C++ literature I have available with me, but none of it seems to really go into the level of detail I need for my current project. My question is pretty much theory, so I'll paraphrase without pasting a nagging piece of code.

I have:

Class X,
Class A,
Class B, derived of Class A and Class X
Cass C, derived of Class B.

These classes have some pretty normal members, explicit initialization constructors and destructors. All copy constructors are, for now, implicit. They all have some reporting capabilities when it comes to creation/destruction, so when I do:

C SomeObject = C();

Or similar, I see nothing out of the norm. My problem starts when copying to a function parameter. Let's call it void Foo(C copiedObject). Doing:

Foo(SomeObject);

..certainly engages a copy constructor. The problem is, I cannot determine how exactly this copy is constructed. I was expecting bitwise copies of members and calls to every base class' copy constructor in some orderly fashion, yet I'm seeing (through debug outputs) initializations mixed in the process. So what I'm asking is basically:

1) in what order what kind of constructors are called upon to resolve this sentence?
2) When are members, such as variables and internal data "duplicated" amidst these constructions, for each of the classes pertaining to this object?

As a sidenote, I have a couple of really important classes I must not, under any circumstance, accidentally copy or let go out of scope without my knowledge. In order to avoid mindless bug hunting later on, I deviced some pretty strong errors whenever either of these cases occur, but in streamlining the code to simply bestow any new class I create with this capabilities by making it derived of stuff such as "CopyBan" or "DeathBan", I stumbled upon this little enigma.

Any help would be greatly appreciated.

Quote:

---

As a sidenote, I have a couple of really important classes I must not, under any circumstance, accidentally copy or let go out of scope without my knowledge. In order to avoid mindless bug hunting later on, I deviced some pretty strong errors whenever either of these cases occur, but in streamlining the code to simply bestow any new class I create with this capabilities by making it derived of stuff such as "CopyBan" or "DeathBan", I stumbled upon this little enigma.

---

So what did you do exactly? Did you declare the copy constructor and assignment operator private for all of the classes in question? Declaring them private without providing an implementation of these functions is the best way to make a class non-copyable. Any copying of objects of those types will be caught at compile time if you do it that way.

Quote:

---

So what did you do exactly? Did you declare the copy constructor and assignment operator private for all of the classes in question? Declaring them private without providing an implementation of these functions is the best way to make a class non-copyable. Any copying of objects of those types will be caught at compile time if you do it that way.

---

That's a great idea actually, but seeing as how I may end up needing to temporarily allow either of these situations to happen for one of my xManager/xRegister classes, I simply tied these functions to my debug level/error reporting classes and made the appropriate flags/functions to allow/disallow the behaviour.

A good understanding of the copying behavior for a class of any branching, multiclass complexity would be ideal. My example is, I hope, just complex enough to get a good idea of how this is implemented.

Quote:

---

Originally Posted by ZaldronGG

That's a great idea actually, but seeing as how I may end up needing to temporarily allow either of these situations to happen for one of my xManager/xRegister classes, I simply tied these functions to my debug level/error reporting classes and made the appropriate flags/functions to allow/disallow the behaviour.

A good understanding of the copying behavior for a class of any branching, multiclass complexity would be ideal. My example is, I hope, just complex enough to get a good idea of how this is implemented.

---

I see. Well it sounds like you are seeing some strange run-time behavior. You should probably attempt to duplicate the problem with a small, compilable example and post it so that we can see the output ourselves. Copy constructors and assignment operators are fairly simple so you should easily be able to step into these functions and see what they are doing. Since you have this complex behavior to control allowing/disallowing these operations you must have defined them for each class. Instead of relying on debug/text logs you need to step into the code where a copy is happening and analyze the copy constructors and assignment operators at run-time.

Another important consideration is that the compiler may optimize copies out of existance....

This typically happens....

1) RVO [Return Value Optimization]. The return value may actually be created directly on the return stack, and there be NO copy performed.

2) Value Parameter Passing. If the compiler (or linker in some cases) has access to the implementation of a method taking an object by value, the copy of the object may be also avoided, provided it does not alter the functional semantics.

Quote:

---

Originally Posted by ZaldronGG

I was expecting bitwise copies of members...

---

Nope. Memberwise copies. For members of class type, it will call the appropriate copy constructor, for members of basic type (int, pointer, etc.) it's likely to be bitwise, but it's better to think of it as each member being copied separately.

As CPUWizard pointed out, some copy constuctor calls may be optimised away, so don't trust logging output to give you a complete picture of what sould be happening.

Quote:

---

Originally Posted by Graham

As CPUWizard pointed out, some copy constuctor calls may be optimised away, so don't trust logging output to give you a complete picture of what sould be happening.

---

And of course, adding logging to a previously empty or default copy constructor may mean that it is not optimised away any more.

Sort of a quantum thing; it only exists when you are measuring it :eek:

Quote:

---

Originally Posted by JohnW@Wessex

And of course, adding logging to a previously empty or default copy constructor may mean that it is not optimised away any more.

---

But the compiler is still free to optimize away the copy, regardless of what you have in there. It could be empty, or read records from a database, it could still get optimized out.

As you know, copy constructors should be written with only that in mind -- making a copy. If it's coded with side-effects or it only creates partial copies, you're asking for trouble. You have to code it so that you don't care if it gets called or not, just that if it's called, a valid copy is made.

Regards,

Paul McKenzie

Quote:

---

Originally Posted by Paul McKenzie

But the compiler is still free to optimize away the copy, regardless of what you have in there.

---

That's why I said 'may' :wave: