Destructors and how to use them?

[hopesfall]

So I've made some pointers using the new keyword and I know that every time I use the new keyword I must use the delete keyword to deallocate that memory. My question is, if I've created a pointer like so:

myFunction(){
SomeType *newPtr = new SomeType;
}

Can I deallocate this memory in one step in the destructor?

[BlackSheep]

Just call:

delete newPtr;

When you want to delete it. If newPtr is a member of a class then yeah, stick the delete inside the destructor of the class:

class Foo
{
int *ptr;
public:
Foo(){ptr = new int;}
~Foo(){delete ptr;}
};

Remember that if you have a pointer to a class, calling delete on that pointer will call the destructor of the class it is pointing to, which gives you a chance to delete any dynamic memory that class itself may have allocated. So this:

Foo *fooPtr;
fooPtr = new Foo;
delete fooPtr; //Would call ~Foo, which deletes the int that Foo allocated. 

EDIT:
Destructor, not constructor...

[Cubbi]

If you made some pointers using the new keyword, you should make them std::unique_ptr, std::shared_ptr, or, on a legacy system, std::auto_ptr (or a suitable replacement), and not use delete at all.

myFunction() {
    std::unique_ptr<SomeType> newPtr(new SomeType);
} // destructor called here automatically 

[S6k9GNh0]

Cubbi, that's not what you "should" do, those things are both optional and situational. Also, auto_ptr isn't for a "legacy system" (whatever that is) and is still useful for various situations concerning exceptions. What if you don't want to delete the variable from the heap at the end and sometime during the middle? More brackets don't cut it in my opinion.

Also, I'd argue shared_ptr is one of the most abused types of pointer wrappers available. Being both slow and innefficient, it's often mistaken as an adequate method of memory management which is just plain false.

[Cubbi]

I haven't seen or used delete in the last 8 years across two C++ jobs. It's kind of bizarre to hear 'must use the delete keyword'

[S6k9GNh0]

That's bologna. new and delete is used in quite a few libraries and in quite a few applications, including real-time and large applications. For you to say you haven't seen or used it in the past 8 years makes me think you aren't using deterministic memory management.

[Cubbi]

It's like saying "for you to say you haven't seen or used goto makes me think you aren't using structured programming". Sure, in libraries, in the implementations of some allocators and some managed pointers, there is manual memory management. Regular, user code, shouldn't need to do that.

[S6k9GNh0]

auto_ptr, shared_ptr, and unique_ptr is manual memory management.

[cire]

computerquip wrote:

Also, auto_ptr isn't for a "legacy system" (whatever that is) and is still useful for various situations concerning exceptions.

Standard wrote:

D.10 auto_ptr [depr.auto.ptr]
The class template auto_ptr is deprecated. [ Note: The class template unique_ptr (20.7.1) provides a better solution. —end note ]

computerquip wrote:

Also, I'd argue shared_ptr is one of the most abused types of pointer wrappers available. Being both slow and innefficient, it's often mistaken as an adequate method of memory management which is just plain false.

There's nothing wrong with shared pointer if you don't pass them by value all over the place.

computerquip wrote:

auto_ptr, shared_ptr, and unique_ptr is manual memory management.

Why don't you toss std::vector in there?

Tell me, if you use a garbage collector in C++ and you ever manually allocate memory, are you not manually 'managing' that memory by your definition of manual memory management?

[S6k9GNh0]

That made no sense. Those facilities still deallocate memory from that scope at a deterministic moment. Garbage collection does not and you generally don't explicitly deallocate memory with a garbage collector. You have to request memory but it's possible you may not have to (explicitly) request it to be free'd.

Also, I wasn't aware of an official deprecation of auto_ptr.

EDIT: After re-reading your post, it does make sense. But "memory management" is a concept that controls both allocation and deallocation in a program (and very likely more such as pooling), not just allocation.

[Cubbi]

Memory management is a subset of resource management. In C++, resources are supposed to be released by the objects that own them, in their destructors. That's what makes it easy to manage deterministic programs.

[S6k9GNh0]

aka RAII