Question

I have a C++ class(inside a dll project) whose member variables are boost::shared_ptrs to objects of other classes. Is it better to assign them inside the class constructor or have a separate init() function which does that.

I am assuming the default value of pointer to T inside boost::shared_ptr is NULL. So if I do nothing inside the constructor will boost::shared_ptr’s get() return NULL before calling Init() function.

Also, what happens when there is a memory allocation problem with new in one of the assignment statement should I catch the exception(in Init) or is it good to tell the caller of this Init() to catch that exception?
boost::shared_ptr a( new T);

Are there standard approaches to simulate the memory allocation exceptions inside unit tests? and see all the objects are properly de-allocated

Answer 1

I have a C++ class(inside a dll project) whose member variables are boost::shared_ptrs to objects of other classes. Is it better to assign them inside the class constructor or have a separate init() function which does that.

It is usally better to do everything in the constructor.
Having an init() function that is called afterwords implies that the object is not valid after construction, so you then need to keep a state flag to indicate if init() has been called and check that flag whenever any public method are called and do somthing appropriate for an uninitialized object

I am assuming the default value of pointer to T inside boost::shared_ptr is NULL. So if I do nothing inside the constructor will boost::shared_ptr’s get() return NULL before calling Init() function.

Yes: The default constructor for shared_ptr will initialize it to NULL.

Also, what happens when there is a memory allocation problem with new in one of the assignment statement should I catch the exception(in Init) or is it good to tell the caller of this Init() to catch that exception? boost::shared_ptr a( new T);

If you have a constructor: Then all members that had been constructed will be destroyed correctly (via destructor), while unitialised objects will not be touched, and the memory for the current object will be release as if never allocated (Another good reason to use the initialiser list).

If you use an init(): Then you must catch the exception clean up the object correctly and release the memory. Depending on how complex the object you may be able to do this inside the init (but it is hard to do correctly) or the caller must do it. After that you should do the same as if an exception had been thrown from the constructor (so that depends on usage).

Are there standard approaches to simulate the memory allocation exceptions inside unit tests? and see all the objects are properly de-allocated

You can use a factory object to allocate the objects.
You pass the factory object to the constructor. When you want to simulate an exception during construction just pass a mock factory that generates that appropriate exception.