CppCon 2015: Scott Schurr “constexpr: Introduction”

CppCon · 53K views · 2015 · 1:04:07

Open on YouTube

C, C++, Rust, Go & systems languagesCompilers, interpreters & program analysistalk

Why Stack Overflow recommends it

Stack Overflow users cite it when asking about constexpr details the talk raises, such as poisoning a function, floating-point differences at compile time, and forcing compile-time-only evaluation.

Recommended by 0 people across 0 different months, 2015 to 2019.

What it is

A one-hour CppCon 2015 talk by Scott Schurr that introduces constexpr for newcomers. It covers C++11 constexpr, the relaxations added in C++14, ways to think about constexpr code, and practical tips such as 'poisoning' a function to force compile-time use.

What people said

Cites sudo make install · 2015-11 · Stack Overflow · on “What does it mean to "poison a function" in C++?”

At the very end of Scott Schurr's talk "Introducing constexpr" at CppCon [this video] , he asks "Is there a way to poison a function"? He then explains that this can be done (albeit in a non-standard way) by: Putting a throw in a constexpr function Declaring an unresolved extern const char* Referencing the unresolved extern in the throw I sense that I'm a bit out of my depth here, but I'm curious: What does it mean to "poison a function"? What is the significance/usefulness of the technique he outlines?

Cites Nan Xiao · 2018-06 · Stack Overflow · on “Why compile-time floating point calculations might not have the same results as run-time calculations?”

In constexpr: Introduction [this video] , the speaker mentioned "Compile-time floating point calculations might not have the same results as runtime calculations": [LINK] And the reason is related to "cross-compiling". Honestly, I can't get the idea clearly. IMHO, different platforms may also have different implementation of integers. Why does it only affect floating points? Or I miss something?

Cites Justin Time - Reinstate Monica · 2019-07 · Stack Overflow · on “Is there a non-indirection, non-hack way to guarantee that a constexpr function only be callable at compile time?”

At the moment, we have two primary options for compile-time evaluation: template metaprogramming (generally using template structs and/or variables), and constexpr operations 1 . template<int l, int r> struct sum_ { enum { value = l + r }; }; // With struct. template<int l, int r> const int sum = sum_<l, r>::value; // With struct & var. template<int l, int r> const int sub = l - r; // With var. constexpr int mul(int l, int r) { return l * r; } // With constexpr. Of these, we are guaranteed that all four can be evaluated at compile time. template<int> struct CompileTimeEvaluable {}; CompileTimeEvaluable<sum_<2, 2>::value> template_struct; // Valid. CompileTimeEvaluable<sum<2, 2>> template_str