61–70 of 120 posts
Earlier quoted context omitted.
After 3 months of development all I have to do is make release and ...
If you guys are going three days without testing a release build (let alone three months), then you probably have bigger issues to work through than what constexpr is doing...
Man, meanwhile, D has compile-time function evaluation. D's compiler is really awesome. Most of the time, no special syntax is to evaluate things at compile time (perhaps just a "static" keyword here or there) and the rules are much simpler than C++'s. https://tour.dlang.org/tour/en/gems/compile-time-function-ev...
If you like this you should check out Nim. Its CTFE is arguably even better. :)
C++ is never just C++. The build system for any C++ program includes both macro language and some form of make and/or make replacement. Explicitly generating tables at compile time and linking is bog standard at this point. Write a table generator program, have output create a table, splice in the order into make and/or make replacement. Sure it's three extra steps, but it's small steps that can be debugged. It also…
Your comment makes no sense, and shows some confusion. C++ is a programming language. That's what's being discussed here. You, on the other hand, are talking about build systems and how sofrware projects may be configured by some people. That is besides the point and actually completely misses the very topic being discussed. It's entirely irrelevant if you can fill a whole header with #define or write a convoluted macro with m4 to write it for you. That's not how a programming language like C++ implements compile-time constant expressions. That's acvomplished with C++'s support for constexpr.
>In conclusion, at the time of this writing, you need to inspect the generated code of your compiler, if you want to be sure that something is really calculated at compile time. I don't get this. Why? Doesn't making a variable constexpr ensure it is a compile time value, or it will fail to compile?
For integral values you can use a little hack to ensure compile-time evaluation: namespace detail { template constexpr T eval() { return val; } }; #define FORCE_COMPILE_TIME(x) detail::eval ()
BTW, you can also enforce compile time evaluation like this:
enum { aux1 = X };
use(aux1);
>In conclusion, at the time of this writing, you need to inspect the generated code of your compiler, if you want to be sure that something is really calculated at compile time. I don't get this. Why? Doesn't making a variable constexpr ensure it is a compile time value, or it will fail to compile?
Here's a better idea, if you really need a compile time value in your program you calculate it yourself (or just run it at program startup and cache the value).
Earlier quoted context omitted.
For integral values you can use a little hack to ensure compile-time evaluation: namespace detail { template constexpr T eval() { return val; } }; #define FORCE_COMPILE_TIME(x) detail::eval ()
This is exactly why I don't like C++: it is just too complicated, and it encourages to write complicated code, usually opaque boilerplate template hacks for what would seem a simple concept. This is difficult to read, review, understand, and hence error-prone. No, not only error-prone, but bug-encouraging. BTW, you can also enforce compile time evaluation like this: enum { aux1 = X }; use(aux1); But that's two lines,…
enum aux1 = X;Earlier quoted context omitted.
You should watch the talk that's mentioned in the article. They demo a constexpr json parser and a constexpr regex engine.
I tried to watch the more interesting parts, it just doesn't seem like a useful approach to me to try to get the compiler to do this work at every compilation instead of the traditional approach of doing it once by generating C(++) code/structures from text/json data in my build. Especially with the "cognitive cost" and debugging issues involved.
Yet another C++ innovation that solves a problem that no one actually has.
What about debugging? If the code to generate the data is large and complex, how do you debug it when it only runs at compile time? Is the solution to start with two programs like the author and then merge them? That still seems like a maintainability issue.
In D which has CTFE support since ages, you'd debug such functions by invoking them at runtime. https://tour.dlang.org/tour/en/gems/compile-time-function-ev... There are also tools to print values at compile time. A compile time debugger for the CTFE interpreter is on our extended feature list for the current interpreter rewrite, but it's less of a priority atm.
>In conclusion, at the time of this writing, you need to inspect the generated code of your compiler, if you want to be sure that something is really calculated at compile time. I don't get this. Why? Doesn't making a variable constexpr ensure it is a compile time value, or it will fail to compile?
Oh look another flag that has several caveats and corner cases and works only half the times you think it works, while increasing compiler complexity Here's a better idea, if you really need a compile time value in your program you calculate it yourself (or just run it at program startup and cache the value).