Re: [boost] [interest] underlying type library

Subject: Re: [boost] [interest] underlying type library
From: Julian Gonggrijp (j.gonggrijp_at_[hidden])
Date: 2011-08-21 15:23:24

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