Add to_raw_pointer helper functions

[glenfe]

We have more than one implementation of this in Boost now, and I plan to use it in one more library. It seems generally useful for Boost library authors supporting Allocators with fancy pointers.

[Lastique]

Isn't get_pointer (boost/get_pointer.hpp) supposed to do that? I know it doesn't currently support arbitrary types but it's been there for decades and it could be extended.

Also, the standard solution to this is &*ptr. If we do need such function, I think the generic version should follow that.

[glenfe]

@Lastique The reason this is used instead of addressof(*p) is because that isn't well defined if there is no object constructed in p. Hinnant switched libc++ to use this technique, and I observe that in the cases where libstdc++ support fancy pointers from allocators, that Wakely does the same thing.

[glenfe]

I like the idea of updating get_pointer if Peter is also in agreement.

[pdimov]

How would the specification of to_raw_pointer look like?

[glenfe]

Something like: The argument must be an object of a pointer-like type T (such that pointer_traits<T>::pointer is valid) that is not a null pointer. The result is a pointer to the element_type (that is pointer_traits<T>::element_type*) that is suitable for construction with placement new, or allocator_traits::construct()?

[pdimov]

Something like that, yes. Could mention that the result references the same location as the argument, and that the opposite operation is pointer_to.

[glenfe]

Instead we will now have a pointer_traits implementation that provides to_address.