Ion Gaztañaga wrote:

...

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

People are used to the standard containers, so I think it's important to provide that same interface. Feel free to extend it however, or even to differ when there is peculiar reason to. From my personal experience, the find function of sets is fairly limited for certain semi-intrusive scenarios. I seem to recall boost.intrusive allows for a find with any key type, maybe that could be added to your containers too.

Forget this post, I have found it in move/boost/container Vicente ----- Original Message ----- From: "vicente.botet" <vicente.botet@wanadoo.fr> To: <boost@lists.boost.org> Sent: Monday, April 13, 2009 12:23 PM Subject: Re: [boost] [move] New version with move-aware containers library ----- Original Message ----- From: "Ion Gaztañaga" <igaztanaga@gmail.com> To: <boost@lists.boost.org> Sent: Monday, April 13, 2009 1:21 AM Subject: [boost] [move] New version with move-aware containers library

-> I've extracted all the containers from Boost.Interprocess, put them in boost/container and they only depend on official Boost SVN code (I haven't tested it, but it should be also nice with Boost 1.38). There is no documentation for these containers.

Hi, I don't find boost/container, please could you give the address where you have put boost/container? Vicente _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 15 April 2009, Steven Watanabe wrote:

AMDG

David Abrahams wrote:

...

Here's one thing I don't love:

Derived(BOOST_RV_REF(Derived) x) // Move ctor

: Base(boost::move(static_cast<Base&>(x))),

mem_(boost::move(x.mem_)) { }

is there a way to get rid of the static_cast and make

Derived(BOOST_RV_REF(Derived) x) // Move ctor

: Base(boost::move(x)),

mem_(boost::move(x.mem_)) { }

work?

FWIW, I always write copy constructors using the cast, after having been bitten by templated base class constructors a few times.

What about a boost::forward<Base>(x) instead of boost::move(static_cast<Base&>(x)) Isn't forward supposed to be some kind of safe and movable-friendly static_cast? I admit I'm a bit hazy on exactly what std::forward is supposed to accomplish. I see it used in perfect forwarding examples, but they seem to work just as well without it. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAknoei4ACgkQ5vihyNWuA4X4MwCgloI4NsYcHsS47CP3rkPaZq8D FtcAoLtj0KvXdc+AvSkZQRqB3N86Gh34 =YPu0 -----END PGP SIGNATURE-----

David Abrahams wrote:

Here's one thing I don't love:

Derived(BOOST_RV_REF(Derived) x) // Move ctor : Base(boost::move(static_cast<Base&>(x))), mem_(boost::move(x.mem_)) { }

is there a way to get rid of the static_cast and make

Derived(BOOST_RV_REF(Derived) x) // Move ctor : Base(boost::move(x)), mem_(boost::move(x.mem_)) { }

work?

I tried but the second form ends calling the copy constructor because rv<Derived> & is upcasted to Derived & and then to Base &. Maybe we could enable some additional conversion operator to a base class.

If these were originally just implementation details of another library, then they would go in a detail/ directory until they are reviewed and accepted. On the other hand, since *these* are simply evolutionary modifications of the containers in Interprocess, which /were/ reviewed and accepted.

So this really becomes a question of how to go about breaking an existing, accepted library into multiple libraries. And I don't really know the answer to that one. I'm open to suggestions.

So am I ;-)

...

If move emulation is considered mature enough, we should also plan when could we port all custom move-emulations present in several boost libraries to the "official" move library.

Yep.

I think porting should be quite fast. One option is to set a Boost release as a milestone (Boost 1.40, Boost 1.41?) and fill a bug for every library with move semantics. Best, Ion

on Thu Apr 30 2009, Sebastian Redl <sebastian.redl-AT-getdesigned.at> wrote:

David Abrahams wrote:

...

Hi Ion,

are you familiar with http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2855.html ?

Until the committee decides exactly how to handle it and compilers catch up with the feature they add, we need a workaround for that problem, both for C++03 and C++0x. The simplest approach requires a trait called has_nothrow_move<T> which can be used to SFINAE-out pair's move constructor unless its members all have a nonthrowing move constructor. It would be reasonable to say

template <class T> struct has_nothrow_move : has_move_constructor {};

as a default, since move constructors shouldn't throw. But still, we need an implementation of has_move_constructor. Obviously, that will require compiler support to be optimal, but in the meantime it can be specialized.

What if we say

template <class T> struct move_is_nothrow : mpl::true_type {};

and have it defined whether there actually is a move constructor or not? Would that work? Or would it interact badly with copy-only types?

The latter. We can probably count on users not to write throwing move ctors, but we can't count on nonthrowing copy ctors. It needs to be conservative, i.e. something like: template <class T> struct has_nothrow_move : mpl::or_< has_nothrow_copy<T> // handles all builtins , has_move_constructor<T> // handle UDTs > {}; template <class T> struct has_move_constructor // Must assume UDTs don't have a move ctor : mpl::false_ {}; template <class T> struct has_nothrow_copy // Must assume UDTs have a copy ctor : has_trivial_copy<T> {}; otherwise, pair<movable_type, type_with_throwing_copy_and_no_move_ctor> has a throwing move constructor. -- Dave Abrahams BoostPro Computing http://www.boostpro.com

on Thu Apr 30 2009, Ion Gaztañaga <igaztanaga-AT-gmail.com> wrote:

David Abrahams wrote:

...

are you familiar with http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2855.html ?

I've just skimmed part of the discussion, just to see what the problem was and to think that noexcept is a great idea that can also help performance and code size.

...

Until the committee decides exactly how to handle it and compilers catch up with the feature they add, we need a workaround for that problem, both for C++03 and C++0x. The simplest approach requires a trait called has_nothrow_move<T> which can be used to SFINAE-out pair's move constructor unless its members all have a nonthrowing move constructor. It would be reasonable to say

template <class T> struct has_nothrow_move : has_move_constructor {};

What does has_nothrow_move exactly mean? It means that type has a nothrow T(T &&x) overload or that conversion from rvalue ref to a type does not throw (including copy constructor if the type has not overloaded the constructor with both const & and &&)?

It means that construction from an rvalue of the same type doesn't throw.

In the working draft there are some "move" traits that are confusing to me regarding this issue (MoveConstructible requires RvalueOf<T> && Constructible<T, RvalueOf<T>::type> which I think is true for C++03 types).

Yes, anything that is CopyConstructible is MoveConstructible. It's not great terminology, but you have to think of the T(move(x)) (where x is of type T) as "the move operation" regardless of whether it actually moves or copies. Then MoveConstructible means you can perform the move operation, not (necessarily) that T has a move constructor.

I think has_move_constructor could be just "is_movable" (in the emulation library "is_movable" means "this type has activated move emulation", the T(rv<T> &) overload).

I expected something like that to be the case for emulated move.

For compilers with rvalue references, I'm not a language expert so I need someone that could write such a trait (can we easily detect if a type has the T(T&&t) constructor?).

There's no known way to do it (even with C++0x as currently defined). Unless someone comes up with an amazing hack, we need a new language feature.

For compilers with rvalue reference, if all types in the course are going to use the portable syntax (that is, they are going to define BOOST_HAS_MOVE_EMULATION macro) BOOST_HAS_MOVE_EMULATION can be used to put a typedef that will mark those types as having a move constructor.

Yep, that sounds like a great idea. And, failing that, the trait can be specialized.

Do you also want me to tweak container/detail/pair.hpp implementation and apply SFINAE for move constructors?

If possible. I suspect it applies not just to pair, but a bunch of others, too. Consider containers, which contain allocators.

I can do some work tomorrow (the trait), and commit it to sandbox.

Anything you can do would be much appreciated! -- Dave Abrahams BoostPro Computing http://www.boostpro.com