Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Constexpr pointer value

I am trying to declare a constexpr pointer initialized to some constant integer value, but clang is foiling all my attempts:

Attempt 1:

constexpr int* x = reinterpret_cast<int*>(0xFF);  test.cpp:1:20: note: reinterpret_cast is not allowed in a constant expression 

Attempt 2:

constexpr int* x = (int*)0xFF;  test.cpp:1:20: note: cast which performs the conversions of a reinterpret_cast is not allowed in a constant expression 

Attempt 3:

constexpr int* x = (int*)0 + 0xFF;  test.cpp:1:28: note: cannot perform pointer arithmetic on null pointer 

Is what I'm trying to do not allowed by design? If so, why? If not, how can I do it?

Note: gcc accepts all of these.

like image 837
HighCommander4 Avatar asked Apr 29 '12 04:04

HighCommander4


People also ask

Can pointers be constexpr?

C++'s constexpr brings another new dimension to the problem too! It behaves like const in the sense that it makes all pointers constant pointers. But because it occurs at the start of your statement (rather than after the '*') its not immediately obvious.

What does constexpr const mean?

constexpr creates a compile-time constant; const simply means that value cannot be changed.

What is the benefit of constexpr?

A constexpr integral value can be used wherever a const integer is required, such as in template arguments and array declarations. And when a value is computed at compile time instead of run time, it helps your program run faster and use less memory.


2 Answers

As Luc Danton notes, your attempts are blocked by the rules in [expr.const]/2 which say that various expressions are not allowed in core constant expressions, including:

-- a reinterpret_cast
-- an operation that would have undefined behavior [Note: including [...] certain pointer arithmetic [...] -- end note]

The first bullet rules out your first example. The second example is ruled out by the first bullet above, plus the rule from [expr.cast]/4 that:

The conversions performed by [...] a reinterpret_cast [...] can be performed using the cast notation of explicit type conversion. The same semantic restrictions and behaviors apply.

The second bullet was added by WG21 core issue 1313, and clarifies that pointer arithmetic on a null pointer is not permitted in a constant expression. This rules out your third example.

Even if these restrictions did not apply to core constant expressions, it would still not be possible to initialize a constexpr pointer with a value produced by casting an integer, since a constexpr pointer variable must be initialized by an address constant expression, which, by [expr.const]/3, must evaluate to

the address of an object with static storage duration, the address of a function, or a null pointer value.

An integer cast to pointer type is none of these.

g++ does not yet strictly enforce these rules, but its recent releases have been getting closer to them, so we should assume that it will eventually fully implement them.

If your goal is to declare a variable for which static initialization is performed, you can simply drop the constexpr -- both clang and g++ will emit a static initializer for this expression. If you need this expression to be part of a constant expression for some reason, you have two choices:

  • Restructure your code so that an intptr_t is passed around instead of a pointer, and cast it to pointer type when you need to (outside of a constant expression), or
  • Use __builtin_constant_p((int*)0xFF) ? (int*)0xFF : (int*)0xFF. This exact form of expression (with __builtin_constant_p on the left-hand-side of a conditional operator) disables strict constant expression checking in the arms of the conditional operator, and is a little-known, but documented, non-portable GNU extension supported by both gcc and clang.
like image 62
Richard Smith Avatar answered Oct 22 '22 10:10

Richard Smith


The reason is the one given by the (for once, very helpful) error message: reinterpret_cast is not allowed in a constant expression. It's listed as one of the explicit exception in 5.19 (paragraph 2).

Changing the reinterpret_cast into a C-style cast still ends up with the semantical equivalent of a reinterpret_cast, so that doesn't help (and again the message is very explicit).

If you had a way to obtain a pointer with value 0 you could indeed use p + 0xff but I can't think of a way to obtain such a pointer with a constant expression. You could have relied on the null pointer value (0 in a pointer context like you did, or nullptr) having a value of 0 on your implementation but as you've seen yourself your implementation refuses to do that. I think it's allowed to do that. (E.g. implementations are allowed to bail out for most constant expressions.)

like image 28
Luc Danton Avatar answered Oct 22 '22 12:10

Luc Danton