CODEWITHSUNDEEP
c++raii
Eric
Eric

Reputation: 19863

Can I run into problems when refactoring to RAII?

I have an application with tons of new that really don't seem to be needed, instantiated objects are deleted a few lines later after use, in the same context (function).

Is it safe to assume that I can change those new to stack allocations or are there special considerations I have to take?

Those objects are relatively light, no big buffers or anything such.

EDIT :

Another point I've discovered is that the object deletion order is harder to control. You have to be more careful how things are created.

Upvotes: 1

Views: 125

Answers (3)

Gorpik
Gorpik

Reputation: 11028

Unless you are creating objects of different types depending on runtime conditions, you should have no problems. I mean, if you have something like:

A* pA;
if (condition)
  pA = new B();
else
  pA = new C();

Then you must stick to pointers; otherwise, you would go into object slicing and missed virtual calls. But if your code is straightforward:

A* pA = new A();
// ...
delete pA;

Then you will be better using stack allocations. You will avoid problems if an exception is thrown between object creation and deletion, to name one of the most obvious advantages.

[EDIT: Another possibility is an overriden operator new, as Mark B says in his answer. The main use for overriding operator new is optimising memory allocations for specific classes; in your case, this would not probably affect you. But yes, there is a chance that your classes have an overriden operator new that does weird things and, in this case, you would change the program behaviour.]

A good rule of thumb is: don't use pointers unless you have to. The only one in a position to decide whether you really have to or not is, of course, you.

Upvotes: 3

Mark B
Mark B

Reputation: 96251

There are a couple considerations I can think of.

If the pointer is being used polymorphically (your question implies no) then you have to continue using pointers. In this case change it to use an appropriate smart pointer instead.

If any of your classes override operator new internally you may totally change the behavior of your program by no longer calling those methods.

Otherwise since the objects are lightweight changing to stack-based objects seems much cleaner.

Upvotes: 2

Mr.C64
Mr.C64

Reputation: 42964

It depends on your particular context; without seeing actual code it's hard to give specific advice.

However, you could at least consider using smart pointers instead of raw pointers assigned calling new (and consequently paying attention to properly call delete).

If your objects live only in the scope of a function, you may want to consider boost::scoped_ptr or C++11's std::unique_ptr.

e.g.

#include <memory>

void f()
{
  std::unique_ptr<SomeClass> p( new SomeClass );
  p->DoSomething();
  ....

  // No need to call delete.
  // This helps making code exception-safe, and it's useful if you return from the function 
  // from different points (so you don't have to make different delete calls to properly
  // release resources).
}

In general, in modern C++ code, owning raw pointers should be used rarely and in few places, e.g. inside class boundaries for classes that are direct resource managers (and even in these cases it is often possible to use std::unique_ptr), or when you implement your own special data structures, etc.

Upvotes: 1

Related Questions