I'm pretty sure the default deleter does a delete on array unique_ptr's. The template is specialized for array types.
Anyway, transferring ownership is pretty easy with a vector too. If you return a vector created in the same function, it'll actually trigger the move semantics, resulting in only the pointer to the contents being moved to the new vector "copy" outside the function. That means the move takes constant time no matter how big a vector.
To force move semantics, you use the std::move function. This effectively transfers ownership the same way.
Only difference is that the unique_ptr enforces the ownership a bit more by not being implicitly copyable.
Very few occations call for a C array (with or without unique_ptr), and if you actually need a constant sized container, use the new std::array rather than a C-array. The std::array can be entirely stack allocated as well since it's constant sized, which is pretty handy at times.
I do programming because I love programming.. and I happen to love games too, so I program games! If you don't have the passion for game programming and you're going about it yourself, it will be really difficult.
I'm also quite artistic, good with sketching and painting, music and so on.. I went down that track first because I thought that was my passion. After a year in art school, it turned out I did more programming in my own time than I spent time on those creative skills. Go figure?
Are you sure you're the programmer type? You got to love solving lots and lots of logical (or somethings not so logical) problems. That has to be a passion, next to the passion for making a game.
There's other ways of coordinating a game project for the ambitious. Realizing what your skills are and what skills you can recruit is essential for any project to reach completion. Do some proper soul searching. Are you really a jack of all trades, passionate for each facet of game development?
I know I'm most focused on the programming. That's why I'm now hiring a friend to make the music, even though I could do it myself. I'll probably get someone to make the art assets too, which I'd also be capable of, but don't really want to spend my time on.
I wouldn't completely crack down on "game dev" collage. It's a chance to do serious networking. Get to know people! Maybe you'll find your game development soul mate. I am chosing CS at university though, because I really want to do programming in depth. Collage is just as much about learning as it is about meeting similarly minded people.
The map is sorted with an RB tree, containing nodes swimming in memory.
I can't give you exact performance comparisons (you'd really have to do that yourself), but there's a few things to say about vector and map (or list).
A vector gives a consistent memory block, which helps a lot with the speed of fetching if it's used much. Maps and lists have an extra pointer, which means the node is anywhere in memory and most likely not already in cache unless its very recently used.
A priority queue got to maintain the heap however, but once sorted the first time, this is a fairly small operation. Usually faster than the cycles required to fetch a map node on a cache miss!
But as earlier posters say.. they are for different purposes and you should simply chose what's right for the job.
1heap in this case is not the 'free memory'. It's a form of sorting structure within an array.
If the committee really feels like unique_ptr should take the place of new/delete why not implement it in the language?
The main reason I see is because the std pointer templates are very generic implementations. They are made with the general case in mind, but far from every case. People will still find needs for new & delete. You may need your own memory manager and then you'll still need the "lower level" stuff. Having the template rather than a language feature also allows people to actually review the code for it, and perhaps build their own using the std version as a guide.
C++ fundamental types are all very simple structurally. A smart pointer with additional memory allocations, ref counting and destructors are miles away from a raw pointer which is only a memory address requiring no initialization or destruction, only assignment. I think this is one of the reason why it's simply a library implementation. C++ isn't a managed language and doesn't aim to be. It's the programmer that should make the choices without being too inclined by the language features.
Arbitrary typedef? Alright, say you've got an object which you've at first used a unique_ptr<MyObject> (or MyObject*, what ever). This works well for a while in your design. A while later you've come to use this plain object declaration in a lot of places, but now require to exchange it with a shared_ptr<> or ^. If you had just used a typedef MyObject_ptr it'd be a one line change instead of having to change every single line. This use for typedef goes for a lot of things, like container types. My point being, you should probably be using a typedef anyway so a preference for a symbol ^ instead of a template makes no difference.
[...] to me, they feel too much as an afterthought and totally extraneous to the language.
I would agree if it was a higher level language than C++. The code generated from the smart pointers is just as optimized as if they were a "primitive" type of the C++ language. Creating a smart pointer in a language that runs on a VM layer, then absolutely yes. Then you'd want the language to cut away the extra layer of the interpretation and just get down to business. But that's not C++.
Actually Stoustrup himself suggests to use smart pointers as "last resort", expecially shared_ptr .
It depends on what you mean with smart pointers. On the Going Native conference earlier this year they discussed the new smart pointers, that is both the unique_ptr and shared_ptr.
B. Stroustrup did say shared_ptr should be a last resort, but the unique_ptr should absolutely be used instead of any new/delete case. It was clearly stated that this should be the new way of handling heap objects in C++. "You should never have to call delete on your own."
Raw pointers still has its uses though, as also discussed at the conference, but they should always be perceived as non-owning pointers that you must guarantee never outlives the object it points to. This is usually the case when a child object has to point back to its parent, where the parent holds an owning pointer of the child. You could use a weak_ptr here, but it's pointless and creates unnecessary overhead. - The intention of this is however only clear if you always use the new smart pointers in the other cases, which is a small theoretical change in code style, but a very large practical change.
When ever I have a class that I put on heap, I usually put in a public typedef for a unique_ptr of that class. Simply MyClass::uptr_t, which honestly isn't that more straining to write that MyClass*. Or declare it outside the class as MyClass_uptr. The added syntax by unique_ptr<> is a poor excuse not to use them. Who can't say they should use typedef a bit more anyway?