Dear all, Thank you for your reactions. I'm glad that so many of you took the effort to think about my proposal. I think the set of types with which bitwise move_raw will yield undefined behaviour can be sharply defined: those types for which the validity of the value depends on the memory address of the object. This is a much more important problem than I thought at first and I stand corrected. Sebastian Redl rightly pointed out that it is dangerous to make the bitwise approach easily accessible from the Boost library. This is especially true if the technique is presented as a 'catch-all', like I did in my first email. However, as Vicente Botet (and Alexander Stepanov) pointed out, there are still valid use cases for the bitwise move_raw mechanism. In fact, that a technique may yield undefined behaviour is not a reason to omit the technique per se; we all know that deleting a pointer twice is unwise. While some of our tools are very safe, it's not unreasonable (or uncommon) to have a tool with known pitfalls. There is a solution for the set of types for which the bitwise mechanism doesn't work: their implementers can override underlying_type_traits and move_raw. In that case there is still an advantage to using the underlying type approach; versions of algorithms other than swap such as rotate, partition and random_permute which are also implemented with move_raw will automatically benefit from the overridden templates. In the current situation the same effect could only be achieved by overriding each of these algorithms for each expensively-copyable type (not to mention the noncopyable types). Another reason to still encapsulate this technique into a library is that it is already used, presumably at least in some cases for valid reasons. Therefore I would like to ask you to reconsider the potential value of this library, under the condition that the following be changed: 1. the library is presented with a big warning sign which indicates its pitfalls; 2. the claims about the library's generality are more modest; 3. (optionally) the library is shipped with more implentations of value-permuting algorithms which take advantage of move_raw, such as rotate, partition and random_permute. Mathias Gaunard wrote:
There is no such thing as an underlying type.
It's impossible to realise in current C++, but conceptually it exists. To be honest I think a built-in underlying type function (and real type functions in general) would make a very interesting addition to C++.
Also I assume move_raw here is memcpy. If it isn't, you have strict aliasing problems as well.
In my current implementation move_raw is the compiler_generated POD assignment (the 'overlying type' is reinterpret_cast to the underlying type to enable this). This might or might not be the same as memcpy (I have no idea about this). I might want to change the implementation to memcpy; could you give me a quick explanation of strict aliasing problems and how they come into being if I don't use memcpy? Best wishes, -Julian