40

Can virtual functions like X::f() in the following code

struct X 
{
    constexpr virtual int f() const 
    {
        return 0;
    }
};

be constexpr?

Ralph Tandetzky
  • 22,780
  • 11
  • 73
  • 120
  • 3
    Think about it a minute. It would completely defeat the `constexpr` purpose. – πάντα ῥεῖ Jan 16 '16 at 14:37
  • Such a hypothetical function could be used as a constant expression only if the complete type of the calling instance is known to be `X`. This would essentially require the language to specify "devirtualization rules". – Kerrek SB Jan 16 '16 at 14:40
  • 2
    @πάνταῥεῖ In D you can do compile time function evaluation with virtual functions. So it's not unthinkable. – Ralph Tandetzky Jan 16 '16 at 14:47
  • 2
    Well, I think it would make sense at least for `final` functions to be able to be `constexpr`. – JohnB Oct 22 '16 at 13:35
  • 1
    Not just for final methods. It could be useful for a compile time unit test. You instantiate a derived class on the stack and use a static_assert on the result of a virtual method. At that point the whole function body could be visible to the compiler. – QBziZ Jan 31 '19 at 09:35

3 Answers3

37

This answer is no longer correct as of C++20.

No. From [dcl.constexpr]/3 (7.1.5, "The constexpr specifier"):

The definition of a constexpr function shall satisfy the following requirements:

— it shall not be virtual

Community
  • 1
  • 1
Kerrek SB
  • 464,522
  • 92
  • 875
  • 1,084
32

Up through C++17, virtual functions could not be declared constexpr. The general reason being that, in constexpr code, everything happen can at compile time. So there really isn't much point to having a function which takes a reference to a base class and calls virtual functions on it; you may as well make it a template function and pass the real type, since you know the real type.

Of course, this thinking doesn't really work as constexpr code becomes more complex, or if you want to share interfaces between compile-time and runtime code. In both cases, losing track of the original type is easy to do. It would also allow std::error_code to be more constexpr-friendly.

Also, the fact that C++20 will allow us to do (limited) dynamic allocation of objects means that it is very easy to lose track of the original type. You can now create a vector<Base*> in constexpr code, insert some Derived class instances into it, and pass that to a constexpr function to operate on.

So C++20 allows virtual functions to be declared constexpr.

S.S. Anne
  • 15,171
  • 8
  • 38
  • 76
Nicol Bolas
  • 449,505
  • 63
  • 781
  • 982
  • Ooh, interesting; I actually just ran into a case where compile-time polymorphism would be _really_ useful yesterday, while attempting to set up a compile-time tag list of potentially variable length to aid with other compile-time tasks. Using a `const` reference to an empty base to allow array size to be a NTTP on the actual tag list was a relatively clean way to solve one of the issues, but introduced its own problems due to the lack of `constexpr virtual`. Glad to see this'll be available soon! – Justin Time - Reinstate Monica Sep 18 '19 at 16:40
  • @JustinTime NTTP? – curiousguy Sep 24 '19 at 02:03
  • 1
    @curiousguy: Non-type template parameter. – Nicol Bolas Sep 24 '19 at 02:31
16

Can virtual functions be constexpr?

Yes. Only since C++20, virtual functions can be constexpr.

Ajay
  • 18,086
  • 12
  • 59
  • 105
Nawaz
  • 353,942
  • 115
  • 666
  • 851