Instantiate an object in method vs. make a class member - c++

Question

What are some reasons to instantiate an object needed in a method, vs. making the object a class member?
For example, in the example code below, I have a class ClassA that I want to use from another class, like USer1, which has pointer to object of classA as member variable and instantiates in its constructor, and on the other hand User2, which instantiates object of classA in a method just before using it. What are some reasons to do it one way vs the other?
class ClassA
{
public:
void doStuff(void){ }
};
//
// this class has ClassA as a member
//
class User1
{
public:
User1()
{
classA = new ClassA();
}
~User1()
{
delete classA;
}
void use(void)
{
classA->doStuff();
}
private:
ClassA *classA;
};
//
// this class uses ClassA only in a method
//
class User2
{
public:
void use(void)
{
ClassA *classA = new ClassA();
classA->doStuff();
delete classA;
}
};
int main(void)
{
User1 user1;
user1.use();
User2 user2;
user2.use();
return 0;
}

Answer 1

The advantages of making it a class member are:
You don't have to allocate the instance every time, which depending on the class could be very slow.
The member can store state (though some people would say that this is a bad idea)
less code
As a side note, if you are just instantiating and deleting with new and delete in the constructor and destructor, it should really not be a pointer, just a member instance and then get rid of the new and delete.
IE
class User1
{
public:
void use(void)
{
classA.doStuff();
}
private:
ClassA classA;
};
There are times that this isn't the case, for instance when the class being allocated on the stack is large, or you want the footprint of the holding class to be as small as possible. But these are the exception rather than the rule.
There are other thing to consider like memory fragmentation, the advantages of accessing contiguous memory blocks, and how memory is allocated on the target system. There are no silver bullets, only general advice, and for any particular program you need to measure and adjust to get the best performance or overcome the limitations of the particular program.
Memory fragmentation is when even though you have a lot of memory free, the size of the individual block is quite small and you will get memory errors when you try to allocate a large amount of memory. This is usually caused by creating and destroying a lot of different objects of various sizes, with some of them staying alive. If you have a system that suffers from memory fragmentation I would suggest a thorough analysis of how objects are created rather than worry about how having a member or not will affect the system. However, here is a breakdown of how the four different scenarios play out when you are suffering from memory fragmentation:
Instantiating the class on the stack is very helpful as it won't contribute to overall memory fragmentation.
Creating it as a value member might cause problems as it might increase the overall size of the object, so when you get to the fragmentation scenario, the object may be too large to be created.
Creating the object and storing a pointer to it may increase memory fragmentation
Allocating on the heap and deleting at the end of use may increase memory fragmentation if something else is allocated after it was.
The advantages of accessing contiguous memory is that cache misses are minimised, so my feeling is that having the object as a value member would be faster, but as with so many things depending lots of other variables this could be completely wrong. As always when it comes to performance, measure.
Memory is often aligned to a particular boundary, for instance 4 byte alignment, or power of 2 blocks. So depending on the size of your object when you allocate one of them it might take up more memory than you expect, if your allocated object contains any members it might significant change the memory footprint of the class if it is a value member, or if it doesn't it probably won't increase it at all, while having a pointer to it will definitely increase the footprint by the size of a pointer, and that may result in a significant increase. Either creating the class on the heap or the stack will not affect the size of the using class. As always if it is going to affect your program you need to measure on the target system to see what the effects are going to be.
If the constructor/destructor does something (for instance a file handle, opening the file, and closing the file) then you might want to only use it in the function. But yet again, the pointer isn't usually necessary.
void use(void)
{
ClassA classA;
classA.doStuff();
} //classA will be destructed at end of scope

Answer 2

First off there is no reason to have a pointer in either class. If we use value semantics in User1 then there is no need to have a constructor or destructor as the compiler generated ones will be sufficient. That changes User1 to:
class User1
{
public:
void use(void)
{
classA.doStuff();
}
private:
ClassA classA;
};
Likewise if we use value semantics in User2 then it would become:
class User2
{
public:
void use(void)
{
ClassA classA;
classA.doStuff();
}
};
Now as to whether you want to have ClassA as a member or if you should just use it in the function is a matter of design. If the class is going to be using and updating the ClassA then it should be a member. If you just need to to do something in a function the the second approach is okay.
If you are going to be calling the function that creates a ClassA a lot it might be beneficial to have it be a member as you only need to construct it once and you get to use it in the function. Conversely If you are going to have a lot objects but you hardly ever call that function it might be better to create the ClassA when you need it as you will save space.
Really though this is something that you would have to profile to determine which way would be better. We programmers are bad judges of what is faster and should let the profiler tell us if we need to change something. Some things like using value semantics over a pointer with heap allocation is generally faster. One example where we get this wrong is sorting. If N is small then using a bubble sort which is O(n^2) is faster than a quicksort which is O(n log n). Another example of this si presented in this Hurb Sutter talk starting at 46:00. He shows that using a std::vector is faster than a std::list at inserting and removing from the middle because a std::vector is very cache friendly where a std::list is not.