Quote:Original post by all_names_taken Is it realistic to expect that C++Ox, along with supporting compilers (VC and GCC), will be available before the end of 2009, though?
No. The next version of MSVC will be 2010, though gcc already has quite a bit of C++0x functionality implemented.
Now you got me all excited, thinking that Boost has released some cool new features specifically for us graphics programmers, or maybe even a brand new 3D API !
auto_ptr is already bad NOW. It leads to dangerous code. Either use scoped_ptr, unique_ptr, or shared_ptr. (well, personally, I'd avoid shared_ptr like the plague, but it is extremely popular for the reason it allows a loosy and easy style of programming).
You can perfectly use unique_ptr in C++03, there are 100% conforming implementations for that language. However you won't be able to put it in standard containers since they're not move-aware (it simply won't compile). You can use it in standard containers that have been modified to be move-aware, however. Boost.Interprocess should have some, for example.
Also, MSVC 10, which should be released soon, has support for rvalue references. GCC has had it for a while, but its standard library doesn't exploit it I believe.
Quote:Original post by loufoque auto_ptr is already bad NOW. It leads to dangerous code.
This can be said about so much in regards to C++ that to say it about one particular aspect of STL hardly seems correct. Though if there really is another solution that brings the same functionality but more robustly then it should indeed be used.
I'm not advocating the mass use of auto_ptr, but if you are aware of its functionality, no matter how unintuitive in regards to a programmers previous prejudice, I can't see the problem.
Innovation not reiterationIf at any point I look as if I know what I'm doing don't worry it was probably an accident.
Just a follow-up to this. Sure, enough, today, I found a good use of auto_ptr<> in conjunction with boost::ptr_vector<>. I use the auto_ptr<> to avoid leaking (in case of an exception) while I manipulate the dynamic object before I insert it into the container and then use the release() method to transfer ownership when inserting. I think this is definitely simpler than what I've done before which was using shared_ptr<> and vector<shared_ptr<> > to avoid leakage.
