C++: delete object or delete members? - c++

Question

I would like to ask about the functional difference; maybe ask for an example scenario, where I should choose from one of the options in the main method below:
#include <iostream>
using namespace std;
class A{
private:
int x, y;
public:
A(int, int);
};
class B{
private:
int *x, *y;
public:
B(int, int);
~B();
};
A:: A(int x, int y){
this->x = x; this->y = y;
}
B:: B(int x, int y){
this->x = new int(x);
this->y = new int(y);
}
B:: ~B(){
delete this->x;
delete this->y;
}
int main(){
int x = 0, y = 0;
A* objA = new A(x, y); // line 1
B objB1(x, y); // line 2
B* objB2 = new B(x, y); // line 3
delete objA;
delete objB2;
return 0;
}
I understand that the second declaration in the main method B objB1(x, y) is obviously different from the other 2, but can someone please explain the functional difference between the constructors in lines labelled 1 and 3? Is there any bad practice in either of the declarations?
Thanks
NAX
UPDATE
First of all, I appreciate all of the answers that everyone is giving, I am really getting some good insight. I have edited the code above as a few of the answers pointed out that I haven't deleted the objects that I used, which is fair and all, but that was not the purpose of my question. I just wanted to gain some insight on the functional difference between the different approaches to creating the classes. And thanks to all that targeted that point. I am reading through the answers still.

Answer 1

"The functional difference..."
On Line 1 you allocate an object of type A on the heap through use of the new keyword. On the heap, space is allocated for the object to which objA points which means 2 ints are created on the heap, contiguously, in line with your ivar definitions.
On line 2 you create a new object of class B on the stack. It will have its destructor called automatically when it goes out of scope. However, when B is allocated, it will be allocated with space for two int pointers (not ints) which will in turn be allocated on the heap as you have specified in B's constructor. When objB1 goes out of scope, the pointers will be successfully deleted by the destructor.
On line 3 you create a new object of class B on the heap. Therefore, space is allocated on the heap for two int pointers (not ints), and then those ints, in turn, are allocated elsewhere on the heap through use of the new keyword. When you delete objB2, the destructor is called and therefore the two "elsewhere integers" are deallocated, and then your original object at objB2 is also deallocated from the heap.
In line with WhozCraig's comment, class A is the most definitely the preferred class definition of the two you have shown in your example.
EDIT (Comment response):
WhozCraig's link basically strongly discourages use of raw pointers. In light of this actually, yes, I agree, Line 2 would be preferred purely on the basis of memory management as B technically manages its own memory (though it still uses raw pointers).
However, I generally dislike (excessive) use of new inside classes as new is much slower than the equivalent stack (or non-new) allocation. I therefore prefer to new the entire class rather than the individual components as it only requires a single new call and all ivars are allocated in the heap anyway. (Better yet, placement new, but that is well beyond the scope of this question).
So in summing up:
Line 2 (class B) would be preferred on the basis of memory management, however even better than that would be:
A objAOnStack(x, y); // Avoids heap altogether
Line 1 is equal-best provided you wrap it in a smart pointer such as std::shared_ptr or std::unique_ptr or something similar.
Line 3 should not really be considered without a smart pointer wrapper (and it's generally better for performance to shy away from nested new anyway).

Answer 2

I usually prefer A-style objects unless there are compelling reasons to use the B pattern, merely because A-style objects are more efficient.
For example, when A objects are allocated, memory for 2 ints (probably 8 bytes on your machine) will be reserved and then initialized by the arguments passed to the constructor. When B objects are allocated, memory for 2 pointers to int will be reserved (also probably 8 bytes on your machine), but then when the B object is initialized in your constructor, each value that is passed will be copied to a newly created int (on the heap), thus using up 8 more bytes of memory total. So in this simple example, your B objects are taking up twice the memory as the A objects.
Furthermore, each time you want to access the values referred to by the x and y your B objects, it will require dereferencing the pointers, which adds a level of indirection and inefficiency (and, in many use cases, should also probably involve a NULL-check for safety, which adds a branch). And of course, there's the extra heap "cleanup" that has to be done whenever B objects are destroyed. (Which can gradually lead to heap fragmentation if lots of them are created and destroyed very frequently.)

Answer 3

Generally speaking, the way of class A is much preferable to class B. Unless you have a good reason, you should stick with designs similar to A. In simple cases and for simple data structures like these, the way class B is implemented can even be considered bad practice.
There are several reasons for this, and here they are in no particular order:
Class B does two more dynamic memory allocations than A. Allocating memory at runtime can be slow, and allocating and freeing a lot of blocks with various sizes can lead to what's called "memory fragmentation* (which is a bad thing.)
Instances of class B are larger than instances of class A. Instances of A are the size of two integers, which are commonly 32 bits each, which makes the whole instance to be 8 bytes. Instances of B require two pointers (which can be 32 or 64 bits each, depending whether your code is compiled for a 32 or 64 bit architecture) plus two actual integers (4 bytes each) plus some metadata that the heap allocator stores for each allocation, which might be anywhere from 0 to 32 bytes or more per allocation. So each instance of B is 8, 16 or (much) more bytes larger than each instance of A, while basically doing the same job.
Accessing the fields (x and y) inside instances of B are slower than the fields inside instances of A. When accessing members of an instance of B, all you have is the location of their pointers. So the CPU fetches the pointers, and then it can know the addresses of the actual integers that hold the values of x and y and that's when it can read or write their values.
In instances of A, you are sure that x and y are stored in consecutive memory addresses. This is the best case scenario to gain the most from CPU caches. In an instance of B, the addresses where the actual x and y are located can be far from each other and you'll get less benefit from the CPU cache.
In A, the lifetime of the members are exactly the same as the lifetime of the object containing them. For B, there is no such inherent guarantee. This is not the case in this simple example, but in more complex cases, specially in the presence of exceptions, this point becomes a clear and present danger. Programming errors (e.g. forgetting to delete one member in some rarely-executed path of the destructor) is also a problem in case of B.
Note that sometimes, decoupling the lifetime of objects from the member data are what you actually want, but this is not generally considered good design. Look up RAII pattern in C++ if you want to know more.
By the way, as is pointed in other comments, you must implement (or declare private) copy constructor and assignment operator for class B.
Due to the same reasons outlines above, you should try to avoid newing your data if you can, which means that among the lines labeled 1, 2 and 3, line 2 is actually the better method of making instances.

Answer 4

You should define a copy constructor and an assignment operator for your class B. Otherwise you will have serious problems with those pointers. Apart from this, there is no functional difference between lines 1 and 3. The only difference is in the implementation.
Having said this, there is no reason for using pointers inside B. If you need a fixed number of integers, use plain integers or plain arrays. If you need a variable number of integers, use std::vector. And if you really need to allocate dynamic memory, be very careful and consider using smart pointers.
If your class B contained only one [pointer to] integer, it could be something like:
class B
{
private:
int * x;
public:
B (int i) { x = new int(i); }
B (const B & b) { x = new int(*b.x); }
~B() { delete x; }
B & operator= (const B & b) // Corner cases:
{ //
int * p = x; // 1) b and *this might
x = new int(*b.x); // be the same object
delete p; //
return *this; // 2) new might throw
} // an exception
};
This code will do "The Right Thing (TM)" even in the corner cases commented.
Another option is:
#include <utility> // std::swap
class B
{
private:
int * x;
public:
B (int i) { x = new int(i); }
B (const B & b) { x = new int(*b.x); }
~B() { delete x; }
void swap (B & b)
{
using std::swap;
swap (x, b.x);
}
B & operator= (const B & b) // Corner cases:
{ //
B tmp(b); // 1) b and *this might
swap (tmp); // be the same object
return *this; //
} // 2) new might throw
}; // an exception
Though, if there are two pointers ---like in your example---, you have to call new twice. If the second new failed throwing an exception, you would want to automatically delete the memory reserved by the first new...
#include <utility> // std::swap
class B
{
private:
int * x;
int * y;
void init (int i, int j)
{
x = new int(i);
try
{
y = new int(j);
}
catch (...) // first new was OK but
{ // second failed, so undo
delete x; // first allocation and
throw; // continue the exception
}
}
public:
B (int i, int j) { init (i, j); }
B (const B & b) { init (*b.x, *b.y); }
~B() { delete x; delete y; }
void swap (B & b)
{
using std::swap;
swap (x, b.x);
swap (y, b.y);
}
B & operator= (const B & b) // Corner cases:
{ //
B tmp(b); // 1) b and *this might
swap (tmp); // be the same object
return *this; //
} // 2) new might throw
}; // an exception
If you had three or four [pointers to] ints... the code would get even uglier! That's where smart pointers and RAII (Resource Acquisition Is Initialization) really help:
#include <utility> // std::swap
#include <memory> // std::unique_ptr (or std::auto_ptr)
class B
{
private:
std::auto_ptr<int> x; // If your compiler supports
std::auto_ptr<int> y; // C++11, use unique_ptr instead
public:
B (int i, int j) : x(new int(i)), // If 2nd new
y(new int(j)) {} // fails, 1st is
// undone
B (const B & b) : x(new int(*b.x)),
y(new int(*b.y)) {}
// No destructor is required
void swap (B & b)
{
using std::swap;
swap (x, b.x);
swap (y, b.y);
}
B & operator= (const B & b) // Corner cases:
{ //
B tmp(b); // 1) b and *this might
swap (tmp); // be the same object
return *this; //
} // 2) new might throw
}; // an exception

Answer 5

Line 1 creates objA and leaves a memory leak because objA is not deleted. If it was deleted, members x and y would be deleted too. Also objA supports copy constructors and assignment operator. There will be no issues with these calls:
func1(*objA)
A objB = *objA.
If you do the same lines with objB2, you will get memory access violation because the same memory pointed by x and y will be deleted twice. You need to create private copy constructor and assignment operator to prevent that.
Regarding scenarios:
Line1 and 3 are good for returning the object to a calling function.
The calling function will need to take responsibility for deleting
it. In class B x and y can be pointers to a base class. So they can
be polymorphic.
Line2 is good for passing this object to a called function below the
call stack. The object will be deleted when the current function
exits.