51–60 of 120 posts
All of this is easy in Common Lisp, which includes interactive compile-time debugging. You can use #., EVAL-WHEN, LOAD-TIME-VALUE, and other things to control evaluation time, and use the same, usual, interactive debugger that you use for runtime code, without any extra infrastructure or scaffolding. In C++, to debug failed constexpr’s, often, you have to make it a non-constexpr and debug at runtime.
If you use a general meta layer preprocessor such as MyDef, you may be able to construct macros that comes from evaluations of code in any languages (instead of restricted in eg. C++ with rather complicated compiler mechanics) A constexpr is a constant that is evaluated from a code at compile time, which is essentially just macros. Right? A general preprocessor that just do language agnostic code manipulations are no…
I did not even know such a thing existed. Thank you!
I am already a big fan of constexpr-ing everything that doesn't run away or make the compiler cry for our embedded application. Yes, we are building a substantial embedded system with (a constrained subset of; no heap, but some templates for example) C++ 11. Heretical, I understand.
I personally do not understand the buzz around constexpr etc. All the real buziness is happening at runtime anyway and compilers already optimize code quite decently. The extra maintenance burden just doesn't pays off.
https://tour.dlang.org/tour/en/gems/compile-time-function-ev...
Earlier quoted context omitted.
And have all embedded engineers raging because you just made cross compilation an order of magnitude harder.
Embedded engineer here. Care to explain why ? Code generation is widely used, at least in automotive. Comparison of hard-to-read and hard-to-debug advanced template/constexpr machinery vs code generated by standalone tool that is easy to read and easy to debug would not be taken seriously
I am not saying there is no solution to these problem, of course there is. All I said is that it makes bootstrapping a system much harder than it would otherwise have been with constexpr. Many devs avoid those issues because dependencies rarely change and once you fixed all issues, it will most likely stay stable.
Mature and "made for embedded" projects tend to be better since cross compiling have been taken into account in each steps of the pipeline. But if you start pulling random code from the internet, expect the worst.
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...
All of this is easy in Common Lisp, which includes interactive compile-time debugging. You can use #., EVAL-WHEN, LOAD-TIME-VALUE, and other things to control evaluation time, and use the same, usual, interactive debugger that you use for runtime code, without any extra infrastructure or scaffolding. In C++, to debug failed constexpr’s, often, you have to make it a non-constexpr and debug at runtime.
Is there anything not easy in Common Lisp?
Earlier quoted context omitted.
Embedded engineer here. Care to explain why ? Code generation is widely used, at least in automotive. Comparison of hard-to-read and hard-to-debug advanced template/constexpr machinery vs code generated by standalone tool that is easy to read and easy to debug would not be taken seriously
If the generator is itself in C++, then it requires to have 2 full toolchains to bootstrap it. Then if the developer have a great idea such as "hey, I got access to all my code! Let's reuse it" then you have to build the package twice. Since everytime you do that you increase the number of packages to be built on the host toolchain, after a while they start to bleed into each other (due to buggy build systems in the…