I feel like you are blaming your own design blunders on the language. Your design pattern is not something that is considered problematic at its very core since the standard does not guarantee any order of such constructors. At some you have to follow the UNIX Philosophy of developing small tools and then gluing them together, like ever imagine if all UNIX utilities were a single program and were subsequently also a part of Borne Shell, how would that be for most use-cases, except the few where you just so happen to need it all. If your project is so large and complex that it requires you to literally control what init projects should run based on what command line arguments, then maybe its time to break them into pieces, and join them using pipes or bash code. Even for games, bash and scripts aren't always slow because they wont run the whole time, their job is to connect software together. If pipes are too big of a overhead, then you should start dynamically linking code at runtime or you use shared memory. Again, adding all functionality in a binary is never a good idea, even Linux loads modules at run time (even though its performance conscious) instead of just using what you want to use, and doing so helps with performance by eliminating death code, Like what you are doing is making the binary huge just to avoid IPC overhead, which again when you think about the previous UNIX utilities example, is a bad choice. What you are trying to achieve warrants abstract interface and is what abstract interfaces are made for, so that you can dynamically link code behind it or use pipes behind it based on what the user asked for. Doing so will in the long term make code more modular. 



On Sun, Oct 25, 2026 at 1:07 AM A Johnston via Std-Proposals <std-proposals@lists.isocpp.org> wrote:

Hello all,


A few years ago, I posted here about adding support for bindings generation, and was left thinking that wasn't an area the standard should be responsible for. Now we have function attributes, attribute reflection, and sophisticated compile time code generation. Suddenly, modern C++ bindings generation is starting to look like it is on the way to some new era.


Please allow me to provide a quick case study that still motivates me, as a way of describing requirements that I would like to see addressed.


In my opinion, the embedded command processor is one of the most overlooked design patterns in C++. The default implementation is to map a utf-8 line to a command by splitting it into tokens using something like ::isspace(), treating arg[0] as a command key, and then forwarding the remaining args. As type information has become easier to manipulate in C++, and more of this can be generated at compile time, this construct has become even more accessible.


The embedded command processor pattern I am describing allows functions to be registered from within individual translation units before main(). Then it enables those functions to be called from the command line on the very first line of main() in order to configure the entire program before it runs. Or they can be called from a settings file during program initialization, or they can be used interactively from a debug shell. And all of these ways can use automatic parsing generated from the function's type info. I'll elide a description of a 10KiB interpreter implemented using this strategy and modern C++ but would be happy to unpack that.


I only have one major complaint that is unresolved in the online discussions around attributes proposals that I have read:


At least until I hear back from this list, the path of least resistance for me to locate a global function for use in an embedded command processor is still to hook the global variable initialization array. Because I can do that in one line, with a macro using a template to declare a global variable. E.g. using this single line: "declare_fn(some_fn);" in global scope. ("Hi, I'm from games.")


That is my primary reservation. That the actual registration hook still has to exist at all, and the later it runs the less useful it is. Could everyone, please take this design pattern into consideration when designing "bindings" attributes. Arguably its implementation provides a minimum set of requirements to target for solving in a clean way. Something the standard should be good at.



Thanks for reading this far,


Adrian


--
Std-Proposals mailing list
Std-Proposals@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals