This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[c++0x] unique_ptr


PAOLO.CARLINI@ORACLE.COM escreveu:
Sure, note, however, that, strictly speaking, here we are not talking about bugs, we are talking about work in progress. In general, when the relevant documents are clear enough we don't debate much the implementation, in the mailing lists, unless someone posts a patch, of course ;) Of course, I don't want to turn down your help, sorry if that was not clear in my previous messages, but really, when we are talking about new, experimental, features, we are really looking for implementors, at this point: imagine what would happen if each user of the experimental C++0x switch (both the C++ front-end and the library bits) starts posting about his favored missing / incomplete item vs the current draft, that would be completely unmanageable!

Well, let's say I've used the term 'bugs' in its wider sense possible :)


Speaking of experimental c++0x, I've been using Chris Fairles' implementation of std::unique_ptr with success so far. I've not used all specializations (the array and static array ones), but for the simple pointer specialization is fine enough. I've just needed to add a conversion operator to std::shared_ptr<T> because of the lack of shared_ptr'z ctor from unique_ptr. Is there anything missing in unique_ptr that is postponing its committing into trunk?
Its weird that auto_ptr was declared deprecated in gcc-4.3 and there's nothing to substitute it (which unique_ptr would).


Regards,
rod

PS: link to the implementation: http://gcc.gnu.org/ml/libstdc++/2007-08/msg00006.html


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]