Google C++ style guide

[Sean Kelly]

== Quote from Don (nospam at nospam.com)'s article
> Jeremie Pelletier wrote:
> > Christopher Wright wrote:
> >> Jeremie Pelletier wrote:
> >>> Me neither, in fact I would *love* to see a -nrtti switch in DMD to
> >>> disable the generation of all ClassInfo and TypeInfo instances, along
> >>> with a version identifier, maybe "version = RTTI_Disabled;" to let
> >>> code handle it.
> >>>
> >>> I use RTTI a lot for simple debugging like printing the name of a
> >>> class or type in generic code or meta programming, but not at all in
> >>> production code. Most of the time I can rely on .stringof and a
> >>> message pragma to do the same.
> >>
> >> You use RTTI for dynamic casts, variadic functions, and the default
> >> implementation of toString. You could safely eliminate some fields
> >> from ClassInfo and TypeInfo,  but you can't get rid of them entirely.
> >>
> >> The best you can do is make TypeInfo entirely opaque (no fields) and
> >> only include the base class, interfaces, and name for ClassInfo.
> >
> > Yeah something like "don't generate type names" and other extra
> > informations would be a definive plus, that makes reverse engineering
> > too easy :)
> I've often thought that a pragma for a module to "don't generate module
> info" would be very useful for executable size. I'm particularly
> thinking of bindings like the Win32 headers, where there are a hundred
> modules, and the module info isn't actually useful. There could be a
> default ModuleInfo instance, with module name "ModuleInfoUnavailable",
> which all such modules would point to.

One thing that can trip this up is structs containing floating point numbers
or static arrays, since they have custom initializers.  I've taken to declaring
structs from C headers with an "= void" to eliminate the link dependency,
but maybe the initializer could be eliminated by declaring the struct as:

struct S
{
    char c      = 0;
    float[2] f = 0.0[];
}

Or something like that.