Boost logo

Boost :

From: Howard Hinnant (howard.hinnant_at_[hidden])
Date: 2006-03-13 10:40:26

On Mar 13, 2006, at 8:42 AM, Vaclav Vesely wrote:

> Hi,
> draft of the is_movable trait is attached.
> Notes:
> - Implicit implementation is based on the has_trivial_copy trait.
> - For STL configurations, which defines BOOST_HAS_MOVABLE_STL,
> is_movable.hpp declares STL containers (and their const versions)
> as movable. Partial template specialization is required (!defined
> Open issues:
> - I'm not sure with volatiles. has_trivial_copy declares volatile
> types explicitly as not has_trivial_copy. I don't know why but
> is_movable should probably follow this.
> - I have tested MSVC (6, 7.1 and 8) and GCC (3.2.3 - MinGW)
> compilers. MSVC is fine but GCC complains with specializations for
> STL types. It seems to be related to a different macro expansion
> strategy of preprocessor. I'm not able to use BOOST_PP_COMMA macro
> correctly. I will appreciate any help.

"is_movable" is an overly vague name for what you're attempting to

Given a type T, a non-initialized x, and an initialized y, here is
the sequence of statements you're optimizing.

::new(&x) T(move(y));

In the current nomenclature (the move proposal before the committee),
there are terms such as "move constructor" and "move assignment". In
both of these cases the source is left in a constructed state. It
would be very easy to confuse the meaning of "is_movable" with these
existing definitions.

I don't know what a good name would be, but I tend to think that the
following would be getting closer:




BOOST_HAS_MOVABLE_STL seems overly simplistic, and perhaps even

Overly simplistic in that for some implementations (e.g. gcc 4.x)
some of the containers will have a trivial destructive move
constructor and some containers won't. Additionally, for containers
that store an Allocator, Comparator, or other policy class, their
eligibility (if potentially eligible in the first place), should
depend upon the eligibility of the Allocator and/or Comparator (and
because of this std::comparators need to be treated - std::less,
etc.). And in at least one implementation I'm aware of, eligibility
for even something as simple as vector<char> depends on whether
you're using the debugging version of the STL. In the debugging
version the vector holds a list of outstanding iterators which in
turn point back to the vector, making it ineligible.

The last point highlights the danger aspect. As currently set up,
you can silently get a false positive for eligibility just by
switching into debug mode (on at least one implementation). The
other danger is that vendors have been known to change the
eligibility of some containers from release to release (examples
include gcc node-based containers). Since this trait can't be auto-
detected for things as complicated as containers, I recommend the
trait only be turned on for specific version numbers of a std::lib,
and that a true response not be forward compatible (later versions
need to be specifically set to true).

If this trait is to exist, you can't go wrong with including pair,
and perhaps even tuple. At the very least their implementation is
entertaining (at least tuple's). :-)


Boost list run by bdawes at, gregod at, cpdaniel at, john at