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