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.
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.
> 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.
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
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
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.