0

You definetely know that macros are somewhat evil. With the relatively new keyword constexpr we can do a few good stuff we couldn't with const. E.g:

constexpr int GetVal()
{
    return 40;
}
int arr[GetVal()];

And yeah...there are also many other usages for constexpr, like in constructors..etc.

Now the question is, is there any benefit of using it over #define macros?

edit

I know what can and what cannot be done with constexpr over macros which is what most of that question and its answers are all about. Here I'm explicitly asking what are the benefits of using constexpr over #define when BOTH can be used.

Vinícius
  • 15,498
  • 3
  • 29
  • 53
  • 1
    Short answer: Type safety (`0` will be an `int`, not potentially `NULL` pointer). And more useful errors (because the information survives long enough for the compiler to see it, rather than performing text replacement in the preprocessor and leaving the compiler with less to work with). – ShadowRanger Jan 06 '16 at 00:20
  • 1
    Wow I edited as fast as I could, but you guys are hasty in decisions eh – Vinícius Jan 06 '16 at 00:24
  • At the highest level... syntax. A simple example is a recursive function like factorial. – Jason Jan 06 '16 at 00:25
  • 1
    Unless you need a PP-time result, all of the usual macro evils apply. They ignore scope and types. Text replacement means things like multiple evaluation. You can't recursively call macros. They're always inlined into the code, regardless of whether that's the best option. Larger definitions require multiple lines with awkward \ endings that are hopefully aligned with each other. Besides that, with C++14, `constexpr` can have loops, etc. to produce a compile-time result, which is not easy with macros, though still "possible" (at least for rudimentary control flow, giving you a PP-time result). – chris Jan 06 '16 at 00:54

0 Answers0