Making C++ do C99 things (part 3/3)

So the code works in three stages.

First, the expressions ‍bit_gravity_ = ForgetGravity etc. are executed. Misleadingly, each of these returns a value of type ParameterSetter. ParameterSetter is itself an aggregate of POD type, so it can be used to initialize a value of type ParameterSetter in a C89-style structure initializer. Each ParameterSetter contains information on how to set a single member of the underlying structure, and what to set it to. (It's perfectly safe to store the latter data in an array of bytes: each member of a POD struct is POD, and POD data can be copied bytewise.)

Second, struct XSetWindowAttributes_ is also of POD type, and therefore can be initialized by a C89-style structure initializer. Furthermore, as a POD aggregate, all members of XSetWindowAttributes_ whose values are not specified are zero-initialized. The values in the initializer correctly match the first several members of the structure.

Third, the converting operators simply take the data and code-references in the ParameterSetters, and execute the latter on the former until an unspecified (and therefore zero-initialized) ParameterSetter is hit — at which point we're done!

The fun part is that a C++ compiler willing to go through enough levels of constant folding, function inlining, dead store elimination, and application of the return value optimization could actually take that code and turn it into the same assembly as the ISO C99 compiler would produce — everything is known at initialization time, and every step it would need to take is a small one that most commercial compilers already know how to take. We're not talking superoptimization here.

(It'd be a little harder, but not at all outside the realm of feasibility, to do something similar for at least simple nonconstant initalization values: e.g., bit_gravity_ = old_gravity and so forth.)

---

Edit 2009-04-30: grammar fixes (removed ghosts of edits past); some minor clarifications.