Non-constant constant-expressions in C++(b.atch.se) |
Non-constant constant-expressions in C++(b.atch.se) |
If someone writes a "here is a cool thing" article for another language involving arbitrary obscure details they are praised with "cool hack". If the language is C++ then out comes all the rants about how C++ is inherently unmaintainable because of "this kind of thing".
Why do people react to C++ this way and not other languages?
The reason this happens is because the only thing all the other comments in this thread are really saying is "Preconceptions about C++ confirmed!". It's easy to reap the karma with such comments.
Probably because stuff like boost::mpl (and so many awful half-implementations of it) exists.
Sadly, if there's a perceived use for a C++ feature, it will be used, no matter how convoluted it is. This is a specific case of a general method for adding state to constexpr, which might be considered useful... I wouldn't be shocked to see this used in the future.
Too much syntax and cleverness is bad for the industry as usually it attracts a lot of smart people who end up writing C++ (or Scala) -- but the problem is that they use a set of patterns+language subset that is unique to the team/company. Therefore knowing C++ does not mean you can just start at a company using C++, you have to learn their way.
Notable exceptions are Java and C#. Java is so simple and verbose that you can't write unreadable code unless you're really evil, it's a shame that the complexity and cleverness is moved to the frameworks (there aren't many "Java programmers", most of them are Spring, etc. specialists). C# works well because MS dictates the patterns (and those patters are usually quite good) while the language itself is very readable and intuitive, without crazy rules.
And there's Lisp/Clojure where there are only a handful simple rules, and cleverness is usually local, e.g. macros or tricky 'functional' data manipulation stuff; but for me that 'local' cleverness is the most understandable.
#include <iostream>
constexpr int f(int line)
{
return line;
}
#define f() f(__LINE__)
int main(int argc, const char * argv[]) {
constexpr int x = f();
constexpr int y = f();
std::cout << "x = " << x << "; y = " << y;
return EXIT_SUCCESS;
}
"This lack of dependency must inherently mean that it will yield the same value upon each invocation having the same set of arguments"
to be true. http://en.cppreference.com/w/cpp/language/constexpr only states:
"The constexpr specifier declares that it is possible to evaluate the value of the function or variable at compile time."
The draft of the C++ standard on my system states that as follows:
"Certain contexts require expressions that satisfy additional requirements as detailed in this sub-clause. Such expressions are called constant expressions. [ Note: Those expressions can be evaluated during translation. — end note ]"
That quote was written in a "this is what most of us used to think" sort of way, it was never intended to be read literally - though maybe I should clearify the intent.
I certainly agree with your post, and your little hack is very cute; +1! :-)
This is not a good advertisement for C++. It would have been much healthier to not have had such a powerful and under-researched template instantiation mechanism, and instead have a genuine compile-time macro language. It's hard to see a way back though. Everything added - like constexpr functions - to make compile-time execution more sane, can be put back into the mix to complect things even further.
...any why I profess nobody knows C++ well, even those on the standards committee ;)
Yep. Jesus christ why didn't they do this. Going further, D (or more recently, JAI) style CTFE would have been great.
But no such luck.
It intimidates a lot of newcomers and leaves a bad taste. And then we wonder why so many people hate the language.
But thats obviously too much, at the very least, I'd want the language designers to understand the implications of the features you add when you add them. You'd think the C++ standards committee would have learned their lesson, after accidentally making templates turing complete.
Even if templates are a great feature (and this is far from a universal opinion), that just means they got lucky.
If so, this is quite big news, similar to when people realised the extent to which SFINAE could be abused. Not exactly sure this is a good thing though.
Ironically, I think some of Stroustrup's goals for c++11/14 were to lower the need for complex template wizardry... Well, now we will have it complex AND stateful !