2 ms·
It's not the same. e.g. const int x = readInput(); cannot be constexpr. Consider constexpr as a compile time assertion that a given symbol is available at
by zarzavat 5y ago
It's not the same. e.g.
const int x = readInput();
cannot be constexpr. Consider constexpr as a compile time assertion that a given symbol is available at compile time. If you didn't have the constexpr keyword then you would have have to inspect the definition to determine that every subexpression is constexpr.
- AlexanderDhoore 5y ago"inspect the definition" Yes, that's what I meant with "the compiler can do it".
- zabzonk 5y agoNot given C and C++ separate file compilation.
- zarzavat 5y agoThat might be OK in an IDE driven language such as Java, but I doubt the neckbeards writing C in a plain text editor would go for that level of implicitness. In C++ it might be more acceptable since you practically need an IDE since C++11 to resolve all the auto type inference.
- foxfluff 5y agoC neckbeard here. I do fully hope and expect and assume the compiler to fold constants and figure out as much at compile time as it can. This is the kind of optimization that doesn't make the code harder to reason about, even when coding with ed, since the logic and ultimate result of these expressions does not change. Heavy type inference, overloading, and inheritance are a completely different beast and they make the code a lot more opaque.
- deleted 5y ago[deleted]
- nine_k 5y agoWhy not const int x = const foo(bar(y)); ?
- mpyne 5y agoThe compile can (and will) do that at run time, it just won't let the code alter x afterwards (either at compile time or run time)
- SuchAnonMuchWow 5y agoYou should check Zig comptime keyword, which does exactly that. Its the feature from zig I miss the most in C.
- User23 5y agoThat sounds like a subset of EVAL-WHEN[1]. [1] http://clhs.lisp.se/Body/s_eval_w.htm http://clhs.lisp.se/Body/s_eval_w.htm