I don't disagree with your view. I simply don't do what you do, but do something entirely different, both in substance and in style. You're certainly right in that what I'm doing is to generate my own sort of compiler with predefined macros. The fact that I glue them together as I do is a product of experience, just as the fact you use a specific compiler to do your work is a product of your own experience. I certainly don't believe you are doing anything wrong or otherwise misguided.

Once I have macros that function as I need, within a given architecture, I like to save myself the effort of regenerating, reproving, and reintegrating them. Often the reintegration is still necessary, but once proven and timed, they seldom require any serious effort for reuse. I've not found that to be the case with HLL's.

Compilers "have a mind of their own" and that's not even necessarily a bad thing. However, they create issues of their own, and I seldom know in advance what they'll be. When I use my own proven macros, as a compiler is also likely to do, though those are macros written by someone else, I know what they do, and recognize their effects. Once you've used those provided in the compiler library, you're in a similar situation, where I supposed I'd be, too, if I use a given compiler long enough. If I were to do that, however, my clients would be "stuck" with the choice of that same compiler. I don't wish to impose that on anyone. If they already have the compiler in house, that would be a different matter.

My stuff is generally proof of concept for someone else to productize and mass-produce. I don't produce things in 100's, generally, though I am sometimes involved in projects that end up with quantities ranging from 100 per year to 100 per day. Most of my own work is limited to fewer than a dozen units, as they're either one-off's or small quantity for my own reuse.

As I've often said, "Where you sit determines what you see."

RE