5

I just read the answer to

const vs constexpr on variables

and am watching this Google Tech Talk about C++11/14 features , in which it is said that, well, constexpr might not be necessary in the future when it comes to functions, since compilers will evolve to figure it out on their own. Finally, I know that Java compilers and JVMs work hard to figure out that classes (or any variable maybe) are immutable after construction - without you explicitly saying so - and doing all sorts of wicked optimization based on this fact.

So, here's the question: Is the fate of const and constexpr to eventually be the same thing? That is, even though a compiler is not guaranteed to do runtime initialization etc., will it not eventually do so whenever possible (basically)? And when that happens, won't one of the keywords be redundant? (Just like inline is becoming, maybe)?

einpoklum
  • 118,144
  • 57
  • 340
  • 684
  • 2
    I, for one, am using constexpr a lot to get a clean and hard error if the compiler can't do what I want it to do at compile-time. I'd rather know when there's a problem rather than have it silently "fixed". – tux3 Jan 08 '15 at 22:20
  • 1
    don't think so - it's perfectly valid to take the address of a `const` variable, but not a `constexpr` one – Red Alert Jan 08 '15 at 22:20
  • 1
    @RedAlert, can do without any problem `constexpr int i = 10; cout << &i << endl;`. The variable has an address. Compiled with g++/clang++ -pedantic – vsoftco Jan 08 '15 at 22:21
  • 5
    I'm not sure about this. constexpr is an expression whose value is known at compile-time, not a variable that's initialized at runtime. They're two different concepts. – mbgda Jan 08 '15 at 22:22
  • inline is obsolete. Only it isn't (lets ignore the linkage issue and focus only on the actual inlining). Andrei Alexandrescu showed at CPPCon that they obtained a performance increase in their code by manually fine tuning which function gets inlined and which not (force). So while it is true that compilers get smarter and smarter I don't see in the near future compilers completely replacing humans at optimization tasks. In the case of constexpr: there will be times when you will want to compute at run-time even if you could do it at compile time (e.g. compile time considerations) – bolov Jan 08 '15 at 22:28
  • @bolov: There's also still a use for `inline` in its vestigal form: Nowadays its just for the ODR-rule. Of course, you are right that it's former use of requesting/forcing inlining can still have an impact. – Deduplicator Jan 08 '15 at 22:30
  • @Deduplicator I said "ignoring the linkage issue". I was referring to the ODR. Maybe bad choice of words on my part. – bolov Jan 08 '15 at 22:32
  • You may find [Is a constexpr more “constant” than const?](http://stackoverflow.com/q/27221883/1708801) helpful, they do different things and so I doubt either one will go away. – Shafik Yaghmour Jan 08 '15 at 22:39
  • 3
    This seems to assume that `const` and `constexpr` is (only) about optimizations. It is not. Especially `constexpr`, which is a portability help: The specification ensures *every* conforming C++ compiler must be able to compute the value at compile-time. (From a programmer's perspective: you can use those values where a constant expression is required.) That's probably also why we started with relatively restricted constant expressions and getting more relaxations. – dyp Jan 08 '15 at 22:43

1 Answers1

7

No, neither one will replace the other, they have different roles. Bjarne Stroustrup tells us in his C++ FAQ that constexpr is not a replacement for const and outlines the different roles of each feature:

Please note that constexpr is not a general purpose replacement for const (or vise versa):

  • const's primary function is to express the idea that an object is not modified through an interface (even though the object may very well be modified through other interfaces). It just so happens that declaring an object const provides excellent optimization opportunities for the compiler. In particular, if an object is declared const and its address isn't taken, a compiler is often able to evaluate its initializer at compile time (though that's not guaranteed) and keep that object in its tables rather than emitting it into the generated code.
  • constexpr's primary function is to extend the range of what can be computed at compile time, making such computation type safe. Objects declared constexpr have their initializer evaluated at compile time; they are basically values kept in the compiler's tables and only emitted into the generated code if needed.
Shafik Yaghmour
  • 154,301
  • 39
  • 440
  • 740