Boost logo

Boost :

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk