constexpr address of base class

Question

Using clang 3.4 (trunk), is there any way to calculate the displacement of a base class with a constant expression?

struct A { int a; };
struct B { int b; };

struct C: A, B {};

// cannot access base class of null pointer:
constexpr auto c_b_address = /*(size_t)*/ &(B&) *(C*)nullptr; 

Answer 1

Yes, it's possible to calculate the displacement of a base class with a constant expression, but it's not at all portable. You can use a little-known but documented gcc extension that is also supported by clang. It involves the use of __builtin_constant_p when used with the operator ?::

#define CB (&(B&)*(C*)nullptr)
constexpr auto c_b_address = __builtin_constant_p CB ? CB : CB;

Note that I've just used the macro CB to make it clear what was happening. This could also, of course, be done by repeating the expression multiple times. Incidentally, I first learned of this trick in this question which contains useful background information.

The basic problem, as you probably already understand, is that neither a reinterpret_cast nor the equivalent C-style cast are allowed in constexpr expressions. Curiously, the C-style cast (as above) is accepted, but a reinterpret_cast (which would generate no code) is not. I also experimented with the obscure but seemingly appropriate ->* operator but with mixed results:

#define CB1 (&(B&)*(C*)nullptr)
#define CB2 (&((reinterpret_cast<C*>(nullptr))->*(&C::b)))
#define CB3 (&(((C*)(nullptr))->*(&C::b)))
#define CB4 (&(B&)*reinterpret_cast<C*>(nullptr))
#define CB CB1

Results with g++ 4.8.3 and clang++ 3.4:

     g++             clang++
--- ------------    --------
CB1  OK              OK
CB2  compile error   compile error
CB3  OK              compiles but gives answer = 0
CB4  compile error   compile error

On my 64-bit machine running Linux, only CB1 yields the correct answer of 4 with both compilers. With gcc, both CB1 and CB2 work with or without __builtin_constant_p. Using clang the only version that worked was CB1 with __builtin_constant_p.

Why should we believe this is intentional behavior?

As @ShafikYaghmour quite reasonably asks in a comment, "do you have a gcc or clang reference that says that they support this behavior?" I'm going to broaden this to ask "what documentation exists that indicates this is intentional and not just an odd side effect?" After all, if someone is actually going to use this, it would be nice to have some indication that it might actually continue to exist in the future. This section attempts to address that concern.

For clang, the reference is the source code itself in which a comment in the VisitConditionalOperator function which says:

// If the condition (ignoring parens) is a __builtin_constant_p call,
// the result is a constant expression if it can be folded without
// side-effects. This is an important GNU extension. See GCC PR38377
// for discussion.

This in turn, points to gcc's Bugzilla bug 38377 which discusses this issue. Specifically, in 2008 this bug was reported as "__builtin_constant_p(t) ? t : 1 is not considered a constant integer expression". In the discussion, it's noted that for the conditional operator (?:),

Yes, this is a (documented) special case required to be compatible with existing GNU C code.

And further,

If you get this wrong for C then GCC will fail to bootstrap, as it's part of the GNU C semantics GCC relies on when being built with GCC.

Given that, it seems that the behavior is both specific and deliberate, and because gcc itself relies on it, probably a fairly stable behavior.

Still, all the usual caveats about using non-standard implementation details apply. If you can perform this at runtime instead, it becomes acceptable to both gcc and clang:

ptrdiff_t cb = (char *)(&(B&)*(C*)nullptr) - (char *)nullptr;