vicente.botet wrote:
Hi Ion,
I think the first thing to do is purpose the Boost.Move library for review. And then ask for a mini review of the move-aware Boost.Containers. I'm sure you will find quicky a review manager.
Yes, but I would like to reach a consensus because usually boost reviews require a lot of time and effort and my intention was to provide a very simple and basic support for move semantics. I sincerely don't have time to add more features to the library (I want to work again Interprocess & Intrusive) so that it might be disappointing to many (e.g.: we don't have move-aware algorithms). Any help on this issue (anyone wants to contribute move-aware algorithms?) would be appreciated. An informal discussion between boosters interested in move semantics to reach a consensus about the minimum features of the library would be a good way to focus on those minimum features and introduce as soon as possible move-semantics into boost.
BTW, how far are the interface of these move-aware containers from the C++0x STL ones?
I'm not sure but they should be quite similar. They don't have concepts or initializer lists but I've tried to follow the C++0x draft(e.g. they include placement insertion, resize() no longer require copy-constructible, just default constructible, ...). I would need to review all of them to see how far they are. They also don't include support for scoped allocators (...yet). boost/container currently contains more containers than C++0x: we have the ordered vector flat_xxx family, the good old slist (not forward_list), the shared-memory compatible string and and the move-aware, shared-memory compatible and largely undocumented version of Joaquín's stable_vector. list, set-map are based on Boost.Intrusive. I don't want to push all of them to the official containers library, but I've put them there so that people can play a bit. But the final version would have just the containers boosters consider essential.
Best, Vicente
Best, Ion