11

This question is a followup question to C++17: still using enums as constants?.

Legacy constants come in several forms, notably:

  • #define CONSTANT x
  • enum { CONSTANT = x };
  • const /*int/unsigned/whatever*/ CONSTANT = x;

A comment about static constexpr and inline constexpr constants as a replacement got me thinking on the subject of updating our many, many legacy constants (particularly #define constants).

As I understand, an inline constexpr value is basically just substituted in place, like an inlined function (which I've been shown to be wrong about). Conversely, a static constexpr value is stored as part of the binary in a separate area. Assuming I understand correctly, when should one be preferred over the other? My hunch is that, for integral constants, inline constexpr will generally be preferred.

jonspaceharper
  • 4,207
  • 2
  • 22
  • 42
  • Are `inline constexpr` suitable for header files? Also the `constexpr int* z = nullptr;` is more akin to `int* const z = nullptr;`, which may be a surprise if a person expected it to be like `int const* z = nullptr;`. – Eljay Jan 31 '19 at 18:03
  • *As I understand, an inline constexpr value is basically just substituted in place, like an inlined function* You have how `inline` works wrong. `inline` does not mean substitute the thing in the call site (although it does act as a suggestion). `inline` is used for ODR purposes. see: https://en.cppreference.com/w/cpp/language/inline – NathanOliver Jan 31 '19 at 18:15
  • Sorry for the confusion, I realize that `constexpr` is automatically inline. I was quoting the comment that got this started. I've updated the question to reflect that I'm really asking about `constexpr` vs `static constexpr` values, typically integral ones. – jonspaceharper Jan 31 '19 at 18:20
  • 1
    @Eljay They are not only suitable, they are required if you want to avoid ODR issues. See https://stackoverflow.com/q/53794625/9305398 – Acorn Jan 31 '19 at 18:22
  • 1
    @MatthieuBrucher No, `constexpr` does *not* imply `inline`. – Acorn Jan 31 '19 at 18:23

2 Answers2

12

Your go-to for global constants in C++17 should just be:

inline constexpr int CONSTANT = 42;

This gets you a nice, first-class variable that you can use in constant expressions and that won't have ODR-issues. You can take references to it.

Macros bring in the problem of... being macros. Enums are limited to integral types. With constexpr variables, you can have them of any literal type. In C++20, you'll very likely be able to just go wild and write:

inline constexpr std::vector<int> small_primes = {2, 3, 5, 7, 11};
inline constexpr std::string cool_name = "Barry";

It is the only option that allows this.

Barry
  • 286,269
  • 29
  • 621
  • 977
7

In C++17, the proper way to replace those old idioms (e.g. #define) in headers in namespace scope is to use constexpr inline variables -- and not static (which is implied: they already have internal linkage).

While typically you won't encounter ODR issues (because integer compile-time constants such as those you describe are rarely ODR-used and there is a provision for their typical usage within inline functions), it is best to mark them as inline now that we have the feature in the language and avoid all problems.

See Should `const` and `constexpr` variables in headers be `inline` to prevent ODR violations? for the technical details about it.

Acorn
  • 24,970
  • 5
  • 40
  • 69
  • Since exapnded `#define`s end up as "pure" source code, they are essentially text, while inline variables are proper variables (for example, you can take the address of them). I'd love to know what the standard says about code generation. In simple examples, the same assembly for both is produced, but are there any guarantees for that? – flowit Aug 29 '21 at 16:07