Why do you say writing auxiliary programs and tools to integrate the data is "standard practice", and a simple and straightforward language feature are "advanced compiler tricks"?

Because 'generate a table by having make run a simple program' is something people have done for decades with C, C++ and other languages, whereas constexpr is a new feature that's only just appeared in the C++ language spec and apparently silently degrades to "not actually at compile time".

> 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.

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.

Is there a C++ compiler that doesn't include 'make' and/or a 'make' replacement? There are linkage rules and even a few keywords just to allow linkage with code not generated by the compiler. It's very much part of the language.

'extern const int *table;'

Having a compile-time program create table would guarantee that it's created at compile time. Having a constexpr does not guarantee it would be done at compile-time, it silently degrades to run-time. If verifying requires an assembly listing, I see it less useful than the currently available tools.

> Is there a C++ compiler that doesn't include 'make' and/or a 'make' replacement?

Yes, all of them.

Because 'make' and/or 'make' replacements have absolutely zero to do with a compiler. It is a build automation tool that essentially determines which target needs to be built based on which preceding targets have been altered. This has zero to do with what a compiler does.

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

Both approaches have their problems, but resolving to compile-time constants with simple expressions is NOT "hard-to-debug" if done with care. As ever, tools can be abused, and real life can astonish.

Example: for the credit dept of a now-ex investment bank many moons ago we had a set of blessed (including with the correct correlations) random numbers pre-computed and baked in via code generation.

I discovered that I could actually generate numbers faster at run-time with highly-tuned code because of the high cost of paging in the large-precompiled numbers array across the network.

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 dependencies) and when you execute the final binary, you get "wrong file format" errors on the target (or worst, sizeof() mismatch at runtime)...

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.

Code generators at our place are most often written in java (xtext, xtend), rarely in other interpreted languages, almost never in C++. Of course, there are grey areas when the price of using another tool, integrating it into build system(which itself sometimes is non-trivial task, if done properly) has to be carefully considered against obtained pros.

The secret there, of course, is not to write the table generation program in C++. (-:

In such circumstances, I find myself writing the table generator in shell script, REXX, or some such convenient language on the host system.

Sounds like opening a can of worms ... some developers will definitely opt for using a language which has "convenient" properties -- since the generator code is not running on the target platform, it has different constraints. And then one day, another dev team will face the task of porting rexx/perl/python/ocaml/you-name-it on a platform which has no capacities for that, or has no required depenedencies available, or neither.

You are making the error of thinking that one can only use one language, or that using the right language for a job is a bad thing; and you are making the error of thinking that build platforms did or do lack the capacity for generating source like this. These are platforms that have the capacity to run a C++ compiler; they have more than enough capacity to run tools like (say) od and sed.