Is reinterpret_cast mostly useless?

Question

I\'ve read various previous questions about the use of reinterpret_cast, and I\'ve also read the relevant wording in the C++ standard. Essentially, what it comes down to is

Answer 1

There are some guarantees elsewhere in the standard (see the section on type representation which, IIRC, mandates that corresponding unsigned and signed types share the representation for the common values, still IIRC, there is also some text guaranteeing that you can read anything as characters). But note also that there are some places which lessen even the section you are reading (which states that things are implementation defined and unspecified): some forms of type punning are undefined behavior.

Answer 2

the result of a pointer-to-pointer reinterpret_cast operation can't safely be used for anything other than being cast back to the original pointer type.

That does not sound right. Assuming sizeof(void *) > sizeof(int *), void *foo; reinterpret_cast<void *>(reinterpret_cast<int *>(foo)) could leave you with a truncated pointer value.

Is it not that reinterpret_cast is — in practice — simply the equivalent to C's default cast?

Answer 3

there's no guarantee that a reinterpret_cast from char* to unsigned char* won't crash your program when you try to dereference the unsigned char* pointer.

You can't do such a cast in any other way, so you have to have to trust what your compiler does with this completely reasonable cast.

Since reinterpret_cast doesn't seem to guarantee this actually works, are C-style casts the only safe option here?

The C-style cast will just map to reinterpret_cast so it will be exactly the same. At some point you have to trust your compiler. The Standard has a limit on which it simply says "no. read your compiler's manual". When it comes to cross-casting pointers, this is such a point. It allows you to read a char using an unsigned char lvalue. A compiler that cannot cast a char* to a usable unsigned char* to do such is just about unusable and doesn't exist for that reason.

Answer 4

Essentially, what it comes down to is that the result of a pointer-to-pointer reinterpret_cast operation can't safely be used for anything other than being cast back to the original pointer type.

You are right, the standard was broken, but N3242 tries to fix that:

Definition of the value of reinterpret_cast<T*>

N3242, [expr.reinterpret.cast]:

When a prvalue v of type “pointer to T1” is converted to the type “pointer to cv T2”, the result is static_cast<cv T2*>(static_cast<cv void*>(v)) if both T1 and T2 are standard-layout types (3.9) and the alignment requirements of T2 are no stricter than those of T1.

This still defines nothing; for fun, the less irrelevant text about static_cast:

A prvalue of type “pointer to cv1 void” can be converted to a prvalue of type “pointer to cv2 T,” where T is an object type and cv2 is the same cv-qualification as, or greater cv-qualification than, cv1. The null pointer value is converted to the null pointer value of the destination type. A value of type pointer to object converted to “pointer to cv void” and back, possibly with different cv-qualification, shall have its original value.

"Suitably converted"

N3242, [class.mem]:

A pointer to a standard-layout struct object, suitably converted using a reinterpret_cast, points to its initial member (or if that member is a bit-field, then to the unit in which it resides) and vice versa.

What kind of style is that? "suitably"? lol

Clearly, these guys don't know how to write a specification.

C-style casts the only safe option here?

It doesn't help.

The standard is broken, broken, broken.

But everybody understands what it really means. The subtext of the standard says:

When a prvalue v of type “pointer to T1” is converted to the type “pointer to cv T2”, the result is static_cast<cv T2*>(static_cast<cv void*>(v))points to the memory address as v if both T1 and T2 are standard-layout types (3.9) and the alignment requirements of T2 are no stricter than those of T1.

That's certainly not perfect (but not worse than many others parts of the standard), but in 2 mn I wrote a better spec than the committee did in a decade.

Answer 5

The standard specifies what has to happen on all platforms, you don't have to do that. If you limit your portability requirements to platforms where your reinterpret_cast actually works, that's fine.

On platforms that actually support a uint16_t, the cast is likely to work. On platforms where char16_t is 18, 24, 32, or 36 bits wide, it might not do the right thing. The question is, do you have to support such platforms? The language standard wants to.