I feel like my original email was highly generic, but in linux, for your
specific requirement, we do have kconfig files and kbuild files so each
time a user wants to add a new module (say for a type of multimedia
support), all he needs to do is to run the interactive editor and choose
that module, and then recompile (which in my gentoo system is just emerge
@module-rebuild).Either way, it isn't a language responsibility, unless the
language wants to expand the scope of metaprogramming to something that
allows you to inspect other compilation units, so basically modules but you
dont have to do linking yourself anymore and you have to define the file
paths for each module name. That will in of itself not do all of what you
want, but that would be the start.

On Sun, Oct 25, 2026 at 8:50 PM A Johnston <ajohnston54637_at_[hidden]> wrote:

> Thank you. I just spent the last 8 years writing a C++ runtime library
> that is intended to run in environments where there is no operating system.
> It is a little hard for me to now change course on that requirement. The
> target list I would offer you for this "soft requirement" I am floating is
> DSPs, FPGAs, ASICs and WebAssembly. Also, being able to debug on a
> workstation before cross-compiling makes command discovery useful on the
> host for compatibility. And these are the targets where code size still
> matters.
>
> Proposals are being worked on, so this looks like it may get labeled "has
> sailed" to me.
>
> On Sun, Oct 25, 2026 at 2:51 AM Muneem via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
>> 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_at_[hidden]> 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_at_[hidden]
>>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>>
>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>
>