Shouldn't a constexpr function be evaluated at compile time?

[JUAN DENT]

Hi,

shouldn't the following constexpr function get() be evaluated at compile time? Why can I step into it at runtime?

template< typename Dimension >
struct extract_value
{
	typedef Dimension type;	
				
     template<size_t N>
     static int constexpr get()	// shouldn't this be executed at compile time??
      {
	return mpl::at_c<Dimension, N>::type::value;
      }
};

Regards,
Juan Dent

[jonnin]

when it can be, which is determined by your compiler if it thinks it can or not. Being in a debug compile may affect this also.

const is relative.

I can do this, with old school code:

int x;..
x = 3;
x = 5;

const int foo = x; //foo is 5, ok. But it could have been input by the user.

[JLBorges]

With Visual Studio 2015 (IIRC, that is what you have been using), during a debugging session, we can step into constexpr functions which were already evaluated at compile-time.

This functionality appears to have been removed in Visual Studio 2017 (even in a debug build, no code is generated for the constexpr function, if all its evaluations were at compile-time).

#include <iostream>
#include <type_traits>

struct A
{
    static constexpr int foo() { return 5 ; }
    static constexpr int bar() noexcept { return 3 ; }
};

int main()
{
    constexpr int a = A::foo() ; // debug in VS 2015: we can step into A::foo()
                                 // even if it was already evaluated at compile time
    constexpr int b = A::bar() ;

    constexpr std::integral_constant< int, (a+b) * (a-b) > iconst {} ;
    static_assert( iconst == 16, "expected a compile-time evaluation" ) ;

    std::cout << "ok\n" ;
}

[JUAN DENT]

Thank you once again JLBorges for your unmistakable speed and depth at which you answer any and every question one may have !! :-)