How smart is a smart pointer?

Started by
29 comments, last by SiCrane 13 years, 7 months ago
think my question is stupid, but I can't find the solution for it by myself.

The thing is: Imagine I have this huge, bloated class called GAME_ENGINE.

if in my main.cpp I create a smart_ptr holding GAME_ENGINE, I know that its resources will be released after the main f() is finished.

The question is, just imagine that this huge class is implemented in term of raw ptrs (pointing to things in the 'heap' and in the 'stack') and instantiations of normal classes.

where would the GAME_ENGINE data be located? its implementation has things that normally would either be in the heap or in the stack, but i'm initializing it in the heap and holding it by a smart_ptr. When the smart_ptr is deallocated, the internal data that GAME_ENGINE points too will leak or it will be released?

I know that this scenario is stupid, bad designed, etc, etc. but what would happen in such situation?

Thanks!
Advertisement
smart_ptr isn't as smart as you are hoping. All that happens with a smart_ptr is that when it goes out of scope, it will automatically call delete on the pointer that it owns. So it will delete your GAME_ENGINE object. However, it is still your responsibility to clean up any resources owned by GAME_ENGINE. If GAME_ENGINE holds smart_ptrs to its resources, then they too will automatically be cleaned up by their smart_ptr containers. But if you are holding raw pointers and not calling delete, there is no magic that will cause those not to leak just because the GAME_ENGINE pointer is wrapped inside a smart_ptr.
"When you die, if you get a choice between going to regular heaven or pie heaven, choose pie heaven. It might be a trick, but if it's not, mmmmmmm, boy."
How to Ask Questions the Smart Way.
If the big game engine class has raw pointers and you are not releasing them with delete then they will leak, holding the game engine class with a shared_ptr doesn't released the memory allocated by it's members.

The shared_ptr is just a wrapper class around a raw pointer which calls the destructor when the shared_ptr falls out of scope.

To simplify a bit, a smart_ptr is just a raw pointer that knows when it can safely delete itself. A smart_ptr being released won't have any magical effects that simply deleteing a raw pointer wouldn't.
Quote:Original post by Shinkage
A smart_ptr being released won't have any magical effects that simply deleteing a raw pointer wouldn't.


There is no "smart_ptr". The term "smart pointer" is general; we should be clear about which one we're talking about.

But yes, in general, the net effect of using a smart pointer is, generally, that the pointed-at thing gets 'delete'd at the appropriate time, which in turn calls its destructor.

Some smart pointers will allow you to override this behaviour, but you still have to tell them what to do (i.e. supply a custom "do this when it's time to clean up" function).
I just assumed he was using one called smart_ptr. It's not like there's some Universal Law of Smart Pointers that says you can't name one that... I had assumed he was planning on rolling his own, calling it that, and wanted to know how they work?
Quote:Original post by Shinkage
I just assumed he was using one called smart_ptr. It's not like there's some Universal Law of Smart Pointers that says you can't name one that... I had assumed he was planning on rolling his own, calling it that, and wanted to know how they work?


:D
actually I'm planning to use the STL's one. But I can never remember its name. But I was thinking with smart_ptr generally, with the 'usual' characteristics a smart pointer should have. Note that I don't have (I think! I hope!) doubts about the smart pointer itself, but the data inside the classes it refers to.

The only smart pointer defined in the C++ standard library (please do not say "STL"; that has not been a meaningful term for many years) is std::auto_ptr. You almost certainly do not want to be using std::auto_ptr for whatever it is you think you want to use it for. Its applicability is quite limited. In particular, you may not store them in a standard library container such as std::vector.

You really should think about what smart pointer you want. Start by thinking about why you want a smart pointer.
in the specific case talked about here, these two (bare with me, haven't written c++ in years) are identical (except for exception safety, as pointed out below):

int main(){    GAME_ENGINE* engine = new GAME_ENGINE();    engine->run();    delete engine;}


and

int main(){    boost::smart_ptr<GAME_ENGINE> engine(new GAME_ENGINE())    engine-run();}


in this specific case, the std::auto_ptr would even work, but i normally tried to never touch it. it's like goto, something to better not use in general code (but in specific cases it can fit).

[Edited by - davepermen on September 3, 2010 7:04:51 AM]
If that's not the help you're after then you're going to have to explain the problem better than what you have. - joanusdmentia

My Page davepermen.net | My Music on Bandcamp and on Soundcloud

Quote:Original post by davepermen
in the specific case talked about here, these two (bare with me, haven't written c++ in years) is identical assuming no expections are being thrown
Elaborated that for you. Sorry to be nitpicky but exceptions fans beg me to no end...
Quote:Original post by davepermen
in this specific case, the std::auto_ptr would even work, but i normally tried to never touch it. it's like goto, something to better not use in general code (but in specific cases it can fit).
I don't understand your point. I think it's fine to use auto_ptr for scoped things like those. In general, everything that has ownership semantics will be fine with it as long as the semantics are respected. Lots of engineering details here.

Previously "Krohm"

This topic is closed to new replies.

Advertisement