I''m beginner in game progamming, and I''m just wondering next thing. Do you use auto_ptr in game programming or do you prefer to use delete? If so, then why? IMO auto_ptr solves common C++ design and coding problems.

I''m not really familiar with the auto_ptr but I guess it is a smart pointer. A pointer that increments or decrements the reference count of the object it points to.

I used it in my engine (heavily inspired by the enginuity articles). I find it very useful. The reasons are obvious I think: I don''t have to worry about deleting my objects. That really speeds up programming and prevents a lot of nasty bugs like you said.

Such a memory allocation/deallocation scheme also gives other advantages, like custom memory management and keeping track of the amount of memory used by your game.

auto_ptr ISNT a smart pointer, its a pointer wrapper, when you assign from one auto_ptr to another the orignal loses its value, which is VERY bad when used with the rest of the STL.

If you want a sane smart pointer then boost::shared_ptr is the answer

Autoptr is to provide simple lifetime maangement of dynamic object (makes it look more like stack object) ... but I don''t use it in game programming, i use other, more advanced wrapper around pointers...

quote:Original post by _the_phantom_
auto_ptr ISNT a smart pointer

According to this it is.


[edited by - constans on January 7, 2004 1:51:30 PM]

well, ok, i could be classed as a kinda smart-pointer however some of it is a bit dumb when used with the STL (releasing on copy for example isnt handy) and its not reference counting, thats for certain.

auto_ptr is NOT compatible with the STL containers AT ALL ...

and it says so many places ...

and it is not ref-counted, and isn''t supposed to be.

There are many many types of lifetime management schemes (stack, dynamic alloc and delete, ref couted dynamic, auto_ptr style, wrapped / hidden ref counting, etc ...) just like sorting ... and there really is a use for just about all of them ... the most important thing is just understanding the behavior of the ones you have available and choosing right ...

My set of C++ libraries makes use of many of them, singleton objects, singleton-like objects, a virtual-destructor base class that i use for all "game" objects, a ref-counted base class i use for many "internal" objects, 2 wrapper classes which make ref-counting happen automatic behind a virtual destructor version and virtual destructor version get called when ref counting goes to zero ... so all of the pieces of my puzzle can be wrapped to acomplish whatever is needed.