在C ++中使用同一类的另一个方法中的constexpr方法

Question

As expected, I can compile the sample below without any problems

// first_sample.cpp
struct sample_struct
{
    constexpr int 
    sample_method() 
    { return 5; }
};

int main() 
{
    sample_struct sample_object;
    constexpr int sample_variable = sample_object.sample_method();
    return 0;
}

But i cannot compile the following sample for the reason

'this' is not a constant expression

// second_sample.cpp
struct sample_struct
{
    constexpr int 
    sample_method_first() 
    { return 5; }

    void 
    sample_method_second() 
    {   constexpr int sample_variable = sample_method_first(); 
        /* Do something with sample_variable */ }
};

int main() 
{ return 0; }

I already know how to solve this "problem" so i am not asking for a solution. I am asking for a reasonable explanation why i am allowed to call a constexpr method from a non-constexpr object while i am not allowed to call the same constexpr method inside another method (from non-constexpr 'this').

Answer 1

In the C++ Standard, [dcl.constexpr]/9:

A constexpr specifier used in an object declaration declares the object as const. Such an object shall have literal type and shall be initialized. [...] Otherwise, or if a constexpr specifier is used in a reference declaration, every full-expression that appears in its initializer shall be a constant expression.

Now, the compiler implicitly adds a this-> to the member function call, as specified by [expr.call]/1

In the case of an implicit class member access, the implied object is the one pointed to by this. [Note: a member function call of the form f() is interpreted as (*this).f() (see 9.3.1). —end note ]

As jogojapan has pointed out (see chat discussion ), in the official C++11 Standard, this may occur as postfix-expression in a class member access as per [expr.const]/2, which is the case here. But the resolution of Issue 1369 disallowed any use of this in constant expressions; however function invocation substitution can allow using this within the context of a constexpr function by replacing it with a prvalue pointer.

The C++14 draft removes the sub-paragraph about function invocation substitution in favour of an exception to [expr.const]/2, explicitly allowing the use of this within the context of a constexpr function (in this case effectively the same as what function invocation substitution allowed).

---

Well, this isn't very "reasonable" as it doesn't provide the reason why it is specified in this way , it only provides the reason why the compiler rejects it.

Answer 2

A constexpr function may be called in any context, constant expression or not. (And your sample_method_second isn't even constexpr .) But a constexpr object must be evaluated at compile time.

So what sample_method_second does is ask the compiler to use this to get the result of sample_method_first at compile time. Clearly that's impossible.

The difference is that in the first example, the scope of main allows the compiler to call the method on sample_object . But being able to evaluate the value of one object does not extend to all potential objects in the program, which is what sample_method_second does.

The solution (well, aside from making sample_method_first independent of this using static ) is not to declare sample_variable as constexpr . If you're using it in a way that requires constexpr , then your design is flawed because the one member function would actually need multiple (potentially infinite) implementations in the final program.

Remember, each potential different value of a legitimately constexpr variable may produce a new template instantiation, a differently-organized switch , or halt compilation with a static_assert . Try doing that retroactively at runtime!

---

As for why the first case is allowed:

sample_struct sample_object;
constexpr int sample_variable = sample_object.sample_method();

What's happening here is constexpr function invocation, and the rule for that excludes

— an invocation of a function other than a constexpr constructor for a literal class, a constexpr function, or an implicit invocation of a trivial destructor (12.4)

There simply isn't a requirement that the object be constexpr because if something needs to be constant to evaluate the inside of the function, or use the result of the function, the evaluation will go awry according to one of the other rules such as lvalue-to-rvalue conversion. You won't be able to modify sample_method to actually access anything, and doing so will complain that sample_object is not declared constexpr , or that its address is not constant if you try to use the value of this directly.