Has-a relationship: reference, pointer or value? ( 1/2 )

You are going to implement an Has-a relationship between two classes. Which is the best way to model this relation: by reference, by pointer or by value?


By Value
In general this is the preferable way to implement an Has-a relationship, the main advantage is to have to complete ownership of the object. Let's have a look at this small chunk of code:

1. class Component
2. {
3.     public:
4.         /* some stuff */
5.     private:
6.         /* some other stuff */
7. };
9. class Owner
10. {
11.     public:
12.         Owner(const Component& component)
13.             :component_(component) {}
14.     private:
15.         Component component_;
16. };

So far so good, every time we create a relationship between two objects we bond the behaviour of one object to the interface of the other one. I will use this simple example to show how the Owner class will change based upon the Component interface.
The constructor of Owner takes a const reference of a component object. The keyword  const is important because we don't and we shouldn't change the object that we are going to copy and store on our class (the keyword explicit is to avoid undesired automatic conversion, have a look at Strongly Type post for more information).

The first drawback of storing the new component by value is performance, we are copying a value, so if Component object is big we spend a lot of time copying it. Please note that the object can be indefinitely big. For example a std::vector can be very-very-very big.

1. class Component
2. {
3.     private:
4.         /* some stuff */
5.         Component(const Component& other);
6.         Component& operator=(const Component& other);
7.     public:
8.         /* some other stuff */
9. };

The author of Component is a good developer and he knows that copying a very-very-very big object is bad, so he decided to disallow the copy semantic (as above).

Now we have the first trouble, the Owner class will not compile! So, the sad moral of the story is: we cannot implement has-a relationship by value if the component object has not copy semantic.


This is not the worst case scenario, let's take as example this Component interface:

1. class Component
2. {
3.     public:
4.         /* some stuff */
5.         Component(Component& other);
6.         Component& operator=(Component& other);
7.     private:
8.         /* some other stuff */
9. };

This time the copy semantic is allowed but the keywords const has been removed. Why? I don't know the people are different and the developers too. Removing the const keyword can give you a very small advantage in performance (do you really need it?) but it can spoil the day of another developer. How? This example explains it:

1. Component comp;
2. /* some calculation */
3. /* comp is very important! My whole program
4.    is based on it! */
6. Owner o(comp);
7.    
8. /* Arggggg.... Owner can change it! */

Changing an object that you take as an input parameter is like scratching the car of your friend. You shouldn't do that.
So: we can but we shouldn't implement an has-a relationship by value if the component object has non-const copy semantic.


Actually, we haven't finished yet with our analysis. There is another pitfall to avoid. It is a well known feature of C++, if you don't provide Constructor, Destructor, Copy-Constructor and Assignment Operator the compiler provide a version for you. You may think cool, less work. Actually there is huge drawback. The compiler is smart, but it is not a mind reader. Even the smartest compiler cannot reproduce the copy semantic that you think! You need to code it, otherwise the compiler will do the best and it can creating a bitwise copy. Bitwise copy is an exact copy of an existing object bit by bit. In order to show all the possible outcomes I have prepared a small program. Even though the program is completely meaningless the result output of it is exactly what we want:

1. #include <iostream>
2. #include <string>
3. using namespace std;
5. class Component
6. {
7.     public:
8.         /* some stuff */
9.         Component(int numberOfValue,string myString) :
10.             i_(new int[numberOfValue]),
11.             numberOfValue_(numberOfValue),
12.             myString_(myString)
13.         {
14.             changeValue(10);
15.         }
16.            
17.         ~Component() { delete[] i_; }    
18.        
19.         int getNumberOfValue() const { return numberOfValue_; }
20.        
21.         string getMyString() const { return myString_; }
22.        
23.         void printArray() const
24.         {
25.             for (int j=0; j < numberOfValue_; j++)
26.                 cout << i_[ j ] << " " ;
27.             cout << " Data stored by pointer" << endl;           
28.         }
29.        
30.         void modify(int newNumberOfValue,string anotherString)
31.         {
32.             delete[] i_;
33.             i_ = new int[newNumberOfValue];
34.             numberOfValue_ = newNumberOfValue;     
35.             myString_ = anotherString;
36.             changeValue(100);
37.         }
38.     private:
39.         void changeValue(int leverage)
40.         {
41.             for (int j=0; j < numberOfValue_; j++)
42.                 i_[ j ] = leverage*j;          
43.         }
44.         /* some other stuff */
45.         int* i_;
46.         int numberOfValue_;
47.         string myString_;
48. };
50. class Owner
51. {
52.     public:
53.         Owner(Component& component)
54.             :component_(component)
55.     {
56.         component_.modify(component_.getNumberOfValue(), "Bar");   
57.     }
58.    
59.     private:
60.         Component component_;
61. };
63. int main (int argc, char *argv[])
64. {
65.     //numberOfValue equal to 10
66.     Component comp(10,"Foo");
67.     cout << comp.getNumberOfValue() << " Built-in type "  << endl;
68.     cout << comp.getMyString() << " Object with deep-copy semantic" << endl;
69.     comp.printArray();
70.        
71.     //Make a copy of Component!
72.     //Using the compiler automatic
73.     //generated copy consturctor
74.     Owner o(comp);
75.     cout << comp.getNumberOfValue() << " Built-in type "  << endl;
76.     cout << comp.getMyString() << " Object with deep-copy semantic" << endl;
77.     comp.printArray();
78.     return 0;
79. }

The output is:
10 Built-in type
Foo Object with deep-copy semantic
0 10 20 30 40 50 60 70 80 90  Data stored by pointer
10 Built-in type
Foo Object with deep-copy semantic
0 100 200 300 400 500 600 700 800 900  Data stored by pointer



As you can see the Built-in type is copy correctly and also the string object. The array is doing something odd. The value of the array has been modified after the creation of Owner object. The reason is that the compiler makes a shallow copy of the pointer, it copies just the pointer and not all the data pointed by the pointer. So you will end up with two entities sharing the same data. Sometimes is what you want but very often is not.



So: we shouldn't implement an has-a relationship by value if the component object hasn't a deep copy semantic. If we really want to do that we need to carefully document our choice because it is not the behaviour that the client of our class will expect.

Using RAII idiom for profiling

The RAII is a well-known C++ idiom. The idea is simple and great at the same time. Two things in life are certain: birth and death. If you are wondering about taxes, please don't forget that I am Italian and in my country taxes are not mandatory.

In object oriented world birth means constructor. The constructor is the first function called when we create it, so it is a wonderful place to allocate a resource. Death means destructor, when a object goes out of scope the destructor is always called (of course if you leak the resource the destructor is not called). That's great, the destructor is the perfect place to release the memory.

Check this link for more information on RAII. What I am going to show you is a very simple class that implement this idiom to get profiling information.

Profiling

If you need to make your application go faster you need to know where your application is actually performing worst. DON'T SPECULATE! The developer are not good to guess where an application is going slow, if they were good the there wouldn't be slow applications.

Profiling is tedious, you need to put extra debug output everywhere, check the result and at the end remove them from the code (of course you can use a profiling tool, but sometimes the learning curve is so big that it is better using trivial way).

The RAII idiom will rescue us, have a look at this class:

1. #ifndef _PROFILER_H_
2. #define _PROFILER_H_
4. #include <string>
5. #include <iostream>
6. #include <sys/time.h>
8. using std::string;
9. using std::ostream;
11. namespace BitingCpp
12. {
13.     class Profiler
14.     {
15.         public:
16.             Profiler(string what,
17.                      ostream& out = std::cout,
18.                      bool verbose = false);
19.             ~Profiler(); /* throw() */
20.         private:
21.             Profiler(const Profiler& rhs);
22.             Profiler& operator=(const Profiler& rhs);
23.             string what_;
24.             timeval start_;
25.             timeval end_;
26.             ostream& out_;
27.             bool verbose_;
28.     };
29. } //namespace BitingCpp
31. #endif

As you can see the class provides only constructor and destructor. The copies are not allowed. There are some private member and this is the implementation file:

1. #include "Profiler.h"
2. using std::endl;
4. namespace BitingCpp
5. {
6.     Profiler::Profiler(string what,ostream& out,
7.                                 bool verbose) :
8.                                 what_(what), start_(),
9.                                 end_(),out_(out),verbose_(verbose)
10.     {
11.         gettimeofday(&start_,0);
12.         if (verbose_)
13.             out_ << "Begin of " << what_ << " at " << start_.tv_sec
14.                  << " s " << start_.tv_usec << " us" << endl;
15.     }
16.        
17.     Profiler::~Profiler() /* throw() */
18.     {
19.         try
20.         {
21.             gettimeofday(&end_,0);
22.             if (verbose_)
23.                 out_ << "End of " << what_ << " at " << end_.tv_sec
24.                      << " s " << end_.tv_usec << " us" << endl;
25.            
26.             double timems =
27.               ((static_cast<double>(end_.tv_sec - start_.tv_sec))
28.               *1000.0 + ((end_.tv_usec - start_.tv_usec)/1000.0));
29.             out_ << what_ << " running time: "
30.                  << timems  << " ms " << endl;
31.         }
32.         catch(...) {} // to avoid core dump during the stack unwind!
33.     }
34. } //namespace BitingCpp

The constructor stores the timestamp of creation (and print an optional statement) and the destructor makes a simple calculation and print the result.

This small program shows how to use this class:

1. #include <iostream>
2. #include "Profiler.h"
4. int main (int argc, char *argv[])
5. {
6.     BitingCpp::Profiler mainProfile(__FUNCTION__);
7.    
8.     BitingCpp::Profiler* justFirstLongLoop =
9.        new BitingCpp::Profiler("Just First Long Loop");
10.    
11.     int j = 0;
12.     for (int i=0; i < 10000000; i++)
13.         j += i*i;
14.        
15.     delete justFirstLongLoop; // trigger the deconstructor
17.     BitingCpp::Profiler anotherBigLoop("Another Big Loop");
18.     j = 0;
19.     for (int i=0; i < 10000000; i++)
20.         j += i*i;
21.    
22.    
23.     return 0; // anotherBigLoop goes out of
24. }             // scope first and then mainProfile

The output of this program is something like that:

Just First Long Loop running time: 52.852 ms
Another Big Loop running time: 52.435 ms
main running time: 105.829 ms

Now it is clear why the copies are not allowed, what does copying a Profiler object mean? The Profiler keeps track of its date of birth (actually a timeval structure). If I copy a Profiler object which date of birth should the new object have? The same of the first one or the time stamp of the copy operation? Too many question and furthermore I cannot see the point to make a copy of a Profiler object in the first place.

Note: the code is working on UNIX platform. You can easily change the implementation file to use Windows functions. __FUNCTION__ macro should be pretty much cross platform, I don't think it is already in the standard, but I am sure is widely supported.

Strongly Type

Is this program compiling?

1. #include <iostream>
2. #include <string>
4. //in a dusty corner of your library
5. #define false 1
6. #define true 0
8. using std::string;
9. using std::endl;
10. using std::cout;
12. void foo(bool aBool,bool bBool,const string& aString,const string& bString)
13. {
14.     cout << "aBool ="   << aBool << endl;
15.     cout << "bBool ="   << bBool << endl;
16.     cout << "aString =" << aString << endl;    
17.     cout << "bString =" << bString << endl;
18. }
20. int main (int argc, char *argv[])
21. {
22.     foo(false,true,"A string","B string");
23.     foo(false,"A string",true,"B string");
24.     foo("A String",false,true,"B string");
25.     return 0;
26. }

I have tried on different compilers and I haven't get any error or warning.  As you can see a function that gets two bools and two const references to string can be fed with the parameters in any order and the compiler will never complain.


If you run it you will get an output like this:

aBool =1
bBool =0
aString =A string
bString =B string
terminate called after throwing an instance of 'std::logic_error'
  what():  basic_string::_S_construct NULL not valid

Are you surprised? I was when I bumped in this error few days ago. Let's try to understand what is going on and why this meaningless code is compiling fine.
Let's start with bool. A literal string is constant at compile time and it is stored using a char*, in other words we type "A string" and the compiler stores in the constant memory a pointer (integer).
The bool type participates in integral promotions. An r-value of type bool can be converted to an r-value of type int, with false becoming zero and true becoming one. So, it is not surprising that  a literal string can be automatically converted to a bool type.


Let's face the hard bit now. The std::string class has got this available constructors:

1. string ( );
2. string ( const string& str );
3. string ( const string& str, size_t pos, size_t n = npos );
4. string ( const char * s, size_t n );
5. string ( const char * s );
6. string ( size_t n, char c );

Let's exclude the n. 1, 3, 4, 6 because they are using more than one parameter, so they are not suitable candidates for the implicit conversion. We need to choose between the copy constructor  (const reference of string) and the overload of the constructor that takes const char*. 


Who is guilty? At this point we still don't know, but we can do some speculation and try to perform a test that can give us an answer. The standard says that a reference CANNOT be null, must always pointing to something. If you have sharp eyes, you have already noticed that we substituted the string parameter with 0 (remember #define true 0). So it cannot be the copy constructor because a reference CANNOT be null. If we write:

1. foo(false,"A string",false,"B string");

The compiler will spot the error:

StronglyType/main.cpp(0,0): Error: invalid conversion from ‘int’ to ‘const char*’ (StronglyType)

The same problem will occur if the function foo has different signature (accepting string by value instead of by reference).


The moral of the story is: don't feed a function with literal string or constant, but define the variable before calling the function.



This code doesn't compile as we want:

1. int main (int argc, char *argv[])
2. {
3.     bool false_(false);
4.     bool true_(true);
5.     string aString("A string");
6.     string bString("B string");
8.     foo(false_,aString,true_,bString);
9.     return 0;
10. }

I know, you are thinking: hang on, you are telling me that I need to type 5 lines of code instead of one!


Well writing 4 lines of code will take 30 seconds of your life. Loosing the type safe checking that the compiler guarantee can cost you hours of nasty debug. Your choice.



Last but not least, the big question. Is it happening just with string or also with other objects?

1. class Bar
2. {
3.     public:
4.         explicit Bar(const char* value) : value_(value) {}
5.         Bar(const Bar& other) : value_(other.getValue()) {}
6.         string getValue() const;
7.     private:
8.         string value_;
9. };
11. void foo(bool aBool,bool bBool,const Bar& aBar,const Bar& bBar)
12. {
13.   // some clever stuff
14. }
16. int main (int argc, char *argv[])
17. {
18.     foo(false, "A Bar", true, "B Bar");
19.     return 0;
20. }

This code is not compiling. The keyword explicit in front of the one-parameter constructor causes a compilation error. If you remove the keyword we have the same behaviour of the std::string.


For more information about the explicit keyword I recommend this link: http://msdn.microsoft.com/en-us/library/h1y7x448.aspx


Note: In order to compile it using gcc version 4.4.3 I added the two #define lines at the top. Other compilers are not so smart and the code will compile even without the two macros (by the way a good reason to not use macros to define constant). If you run the example with a different compiler let me know if the program will compile also without the two #define.