auto_ptr vs shared_ptr ?

Hey guys,

I'm working with a custom C++ library(C++98 , so no move semantics) where I have a std like auto_ptr and shared_ptr, so there is no unique_ptr.

I really would like to use unique_ptr but I only got these 2 options (and raw owning pointers, but I won't use them :P).

Right now i'm using a shared_ptr because I heard auto_ptrs are bad?!
What do you recommend, when there is no unique_ptr available?
Last edited on
What's the problem with using a modern compiler?
Last edited on
I don't know about the OP's situation, but there could be any number of reasons why an older compiler must be used.

Sometimes developers are stuck maintaining legacy code, and a change to a new compiler would present more risk than management is willing to take.

It's also possible that tools for specific target environments have not caught up to the new standard.

I am in a situation where vetting and upgrading an OS is a protracted exercise. I am currently using Ubuntu 10.4, and that only supports an old version of g++, so I can only go to -std=c++0x. It's not practical (and probably not allowed) for me to download the g++ source code (and all of its dependencies) and build my own tools. (I hope we approve a newer version of Ubuntu soon.)

So, there are a number of reasons why a modern compiler might not be an option.
Thanks very much for the general chit-chat. I'll rephrase to avoid confusion.

In this case, what's the problem with using a modern compiler?
Last edited on
yeah there might be reasons to use an old compiler.
But in my case there is no reason, the majority of the developers in my company are too scared of C++11 or don't even know about it :P (and i actually don't care)

Even with c++11 the library doesn't support unique pointers, and we don't use the STL (i'm working in the game industry ,where this is quite common).

Maybe I'm misunderstanding. If you have a library, it doesn't matter what's inside it. The library doesn't have to "support unique pointers". The library is a lump of binary, providing you with some functions to call.

Anyway, you can make your own unique_pointer class. It's a template class, containing a pointer. The copy and assignment operators set the pointer to null in the "from" unique_pointer.
Last edited on
i don't get what you're saying x.x
I'm saying that if you need the functionality of unique pointer, you can make one yourself.
> i'm using a shared_ptr because I heard auto_ptrs are bad?!
>> we don't use the STL

Use std::autoptr<>; since you are not using the standard containers library, that std::autoptr<> can't be placed in standard containers becomes a non-issue.
ok.. never used auto_ptr, I've always used unique_ptr and they are great, but not sure about those auto_ptrs :P


does this cause memory leaks with autp_ptr?

MyContainer.Add(autp_ptr<MyObject>(new MyObject()));
Last edited on
Since this is in the gaming industry, performance is probably critical so I'd try to avoid shared_ptr if possible. shared_ptr updates a reference count for each shared_ptr that accesses the object. If there is conceptually only one owner of the object (i.e., only one pointer that should delete the object when the pointer is deleted) then you don't need the overhead of shared_ptr.

Working with raw pointers isn't impossible, so if all else fails, go for it. The key is being very clear in your head (AND in the documentation) about who owns the pointer. The owner is responsible for deleting it. A good rule of thumb is that the thing that allocates the pointer should be the one that deletes it.
I'd try to avoid shared_ptr if possible. shared_ptr updates a reference count for each shared_ptr that accesses the object


yeah thats true.
I used shared_ptr, because I never worked with AutoPtrs, and want to avoid raw pointers, especially for gameplay programming.

Not sure about the performance for auto_ptr, but unique_ptr should have no to nearly no overhead as far as i know, so it should be even ok to use them performance critical parts
Last edited on
> unique_ptr should have no to nearly no overhead as far as i know

Yes, near-zero extra overhead when instantiated with the default deleter.


> Not sure about the performance for auto_ptr

At least as efficient as std::unique_ptr with the default deleter.
ok good to know :)

just want to be sure again, because nobody answered it yet:
does this cause problems with auto_ptr
 
MyContainer.Add(autp_ptr<MyObject>(new MyObject()));
> does this cause problems with auto_ptr

Yes, it does (assuming that MyContainer is a standard container).

Copying an auto_ptr copies the pointer and transfers ownership to the destination: both copy construction and copy assignment of auto_ptr modify their right hand arguments, and the "copy" is not equal to the original. Because of these unusual copy semantics, auto_ptr may not be placed in standard containers. std::unique_ptr is preferred for this and other uses. (since C++11)
http://en.cppreference.com/w/cpp/memory/auto_ptr


More information: http://www.devx.com/cplus/10MinuteSolution/39071
well its no standard, its a custom one similar to the std container.
so that means the auto_ptr would leak?

i've tested it and doesn't seem to leak when the auto_ptr gets removed from the container.
(btw: somehow your last link doesn't work for me)


Last edited on
> somehow your last link doesn't work for me

From http://www.devx.com/cplus/10MinuteSolution/39071
Presenting the Problem

Suppose your program calls std::sort() to sort a sequence of auto_ptr objects:
1
2
3
vector<auto_ptr<int> > vi;
//..populate vi
sort(vi.begin(), vi.end(), indirect_less());

Depending on the underlying implementation of sort(), the above call could work perfectly—or it might cause a runtime crash. The problem is that some implementations of sort() pick an element out of the sequence, storing a local copy thereof:
value_type pivot_elem = *midpoint;//not a copy operation!

sort() assumes that pivot_elem and *midpoint are equivalent. However when value_type is an auto_ptr, this assumption fails because what appears to be a copy operation is in fact a move operation. Consequently, the algorithm fails. There's nothing amiss with the implementation of sort(). Rather, auto_ptr is the culprit.


With legacy C++, if auto_ptr objects are to be placed into containers, (or if we want the container to manage the life-time of dynamically allocated objects), consider using Boost's Pointer Container Library.
http://www.boost.org/doc/libs/1_60_0/libs/ptr_container/doc/tutorial.html
Topic archived. No new replies allowed.