Strides Interactive

The Big Three or Big Four?Filed Under: Weekly Tuesday Dose of goodness

Happy Lunar New Year to all!

Why lunar and not chinese? Reason is simple, it’s not just the Chinese that celebrates Lunar New Year. (well, yeah I’m a Chinese too).

Anyway, I must apologise since my article came late this week. Please understand that I have a lot of relatives and therefore a lot of visiting.

This week, we’re going to talk about C++’s Rule Of Three. (also known as the Big Three). In this article, I’m going to coin the fourth rule as well.  Why?

Check it out….

Introduction

First of all, this article is based on the previous 2 articles - Deep/Shallow Copy. So let’s take a look at what’s in the Rule of Three.

1) Destructor
2) Copy Constructor
3) Copy Assignment Operator

These are all important and must be carefully declared and defined in order to safeguard the workability of the class.

That aside, the need for shallow and deep copy depends entirely on what your class is supposed to do. There’s no hard and fast rule as to whether you should always perform a deep or shallow copy.

The Big Four(th)?

So where’s the Big Four coming from?

The fourth rule comes from the constructors themselves. Now, apart from the copy constructor(s), there’re 2 more types of constructors we normally implement.

1) Default constructor
2) Parameterized Constructor

We all know what’s a default constructor. A parameterized constructor is simply passing values that matters as parameters into a constructor that is specially implemented to handle them.

So why are they so important?

As much as it’s important to properly handle the copy operation in the Copy Constructor, it’s also important to handle the initialization operations in the rest of the constructors.

Why?

By standards, most compilers will not initialize memory for you. In that sense, when we instantiate an object, the memory buffer that holds the vtable and the rest of the attributes are not directly instantiated. While the vtable is done for you, you’ll still need to initialize the rest of the attributes manually.

What happens if you do not?

Well… at the very minimum, there’ll be logical errors from the time of object construction till the first assignment of your attributes.

Otherwise, if it’s a pointer, well.. you’re risking the aspects of accessing a wild pointer. A wild pointer is a type of pointer that points at a random location due to lack of initialization. Access it and you’ll almost certainly get an Access Violation at a certain memory location. That is if you’re lucky.

However, even if you’re lucky enough to get away from blue screens or system crashes, you’ll have a hard time figuring out the weird access violation message that prints out a random memory address such as:

Access Violation at memory 0xCCCCCCFF (for Visual Studio 2005 for example)

You’ll probably wonder where on earth did that crash come from.

Conclusion

So in short, we must always ensure not only our deep/shallow copy are well-managed, but also the initialization of the object itself.

This has to be done across all other non-copying constructors and therefore they should be, in my humble opinion be the Big Four (th).

If I need to instantiate an object and then call an init() - that’ll be stupid because that object has had 2 opportunities to initialize itself.

1) The initialization list (make a comment if you wanna know how it’s being done)
2) Assignment operations in the constructor body itself

So why do I even need an init() function?

Well, to be honest, I do have one or two such stupid functions as well. My justifications for them are:

1) It’s a singleton
2) There’s indeed a specific order of initialization that needs to be done

As much as possible, I’d initialize all the member attributes in the constructors to avoid mystifying errors mentioned above. So please, define your constructors carefully and responsibly.

Anyway, it has been quite a long week for me and I’m getting really tired really easy lately.

Signing off,
Jeremy