Passing local string parameter as reference to const into a constexpr function? Why is that legal?

Question

A constexpr function accepts only parameters, which are of a literal type. An object of the class string is not a literal type itself, but a pointer (which is a scalar type) or a reference is a literal type. And therefore a reference to string is a literal type.

Furthermore a constexpr function returns only a constant expression, if it's arguments are also constant expressions.

"The scale* function will return a constant expression if its argument is a constant expression but not otherwise:"
Source: The C++ Primer, 5th edition

scale is in this case is_shorter()

Now I'm passing here two references to string to a constexpr function, which doesn't remain at a fixed address (global or static) but at a variable address (local). Therefore both arguments shouldn't be constant expressions.
The result of the constexpr function is assigned to a constexpr bool.

#include <iostream>
#include <string>
#include <type_traits>
using namespace std;

/*
 * it isn't possible to define is_shorter as constexpr function
 * 1. string is not a literal type, but can be passed as pointer or reference,
 *    which are literal types.
 * 2. the member function size() is not a constexpr function
 *
 */

// compare the length of two strings
constexpr bool is_shorter(const string& s1, const string& s2) {
    // compiler message from gcc: 'error: call to non-constexpr function'
    // return s1.size() < s2.size();

    // compare addresses of pointers, which is legal or illegal but useless, because
    // both parameters are local objects and not stored at fixed addresses.
    return &s1 != &s2;
}

int main() {
    string shrt = "short";
    string longer = "longer";

    cout << "address of shrt " << &shrt << "\n";
    cout << "address of longer " << &longer << "\n";

    constexpr bool state = is_shorter(shrt, longer);
    if (state) {
        cout << "shrt is shorter\n";
    } else {
        cout << "longer is longer\n";
    }

    cout << "string " << is_literal_type<string>::value << "\n";
    cout << "string& " << is_literal_type<string&>::value << "\n";
    cout << "string* " << is_literal_type<string*>::value << "\n";
    return 0;
}   

Compile:

$ g++ -o ex646 ex646.cpp -std=gnu++11 -Wall -Wpedantic

Run:

$ ./ex646
address of shrt 0x7ffd39e41a50 # every time different
address of longer 0x7ffd39e41a40 # every time different, always 0x10 more than &shrt
shrt is shorter
string 0
string& 1
string* 1

How is the compiler able to compare the addresses of both strings? They are during every run-time of the program different, whereas their relative position remains constant. Is the key to this usage, that at least their relative position to each other remains constant?

Update 2015-08-12
As time of writing this looks like in 'a bug in the constant evaluation rules' of the ISO-Standard (correct me if I'm wrong). See this discussion on an isocpp.org list. And therefore this shouldn't be a compiler bug inside GCC and CLANG.

Thanks dyp!

Answer 1

So as far as I can tell this looks like some sort of compiler extension or a bug. C++11 was adjusted via a defect report to allow references to be considered literal types regardless if the variable it references is a literal type. But, a reference constant expression should refer to an object of static storage duration and similar for a address constant expression.

The draft C++11 standard tell us what cases pointers can be considered equal:

Two pointers of the same type compare equal if and only if they are both null, both point to the same function, or both represent the same address (3.9.2).

so in the your case the compiler can trivially deduce which case the != falls under but I don't see a carve out that it would let it avoid the constant expressions requirements for this case.

For reference section 5.19 [expr.const] tell us:

an id-expression that refers to a variable or data member of reference type unless the reference has a preceding initialization, initialized with a constant expression

this was modified by defect report 1454 which changes to read as follows:

an id-expression that refers to a variable or data member of reference type unless the reference has a preceding initialization and either

• it is initialized with a constant expression or
• it is a non-static data member of an object whose lifetime began within the evaluation of e

but in either case that should be sufficient to make this case not a constant expression.

A reference constant expression is an lvalue core constant expression that designates an object with static storage duration or a function. An address constant expression is a prvalue core constant expression of pointer type that evaluates to the address of an object with static storage duration, to the address of a function, or to a null pointer value, or a prvalue core constant expression of type std::nullptr_t.

none of which applies to the automatic variables in your case.

References were initially not literals but defect report 1195 which says:

7.1.5 [dcl.constexpr] paragraph 3 is overly restrictive in requiring that reference parameter and return types of a constexpr function or constructor must refer to a literal type. 5.20 [expr.const] paragraph 2 already prevents any problematic uses of lvalues of non-literal types, and it permits use of pointers to non-literal types as address constants. The same should be permitted via reference parameters and return types of constexpr functions.

and changes section 3.9 [basic.types] which said in the N3337 the draft C++11 standard:

A type is a literal type if it is:

[...]

• a reference type referring to a literal type; or

to:

• a reference type; or

Answer 2

The address of the string is the address of the stack object and not the underlying pointer that the string is wrapping. The address might be different on each run but the compiler will load the variables into memory the same way each time so the comparison will always yield the same results.

Note: Different compilers might order the variables in a different way so this code is not portable.

Note 2: comparing pointers for equality (==, !=) is defined behavior for pointers of the same type. trying to compare with relational operators (<,>,<=,>=) is unspecified if:

two pointers p and q of the same type point to different objects that are not members of the same object or elements of the same array or to different functions, or if only one of them is null