lazy facet instantiation

Martin Sebor sebor@roguewave.com
Tue Nov 15 20:49:00 GMT 2005


Howard Hinnant wrote:

[...]

FWIW, I find this topic interesting since I spent a good deal
of time implementing something similar to this in our library :)

> However if we instead of a locale default ctor that does nothing, and  
> instead wait to fill the locale on an as-needed basis under  
> use_facet<StandardFacet>(const locale&), then only those standard  
> facets which are actually retrieved via a use_facet get installed  into 
> the locale.  The standard facets not explicitly called via a  use_facet 
> are not only not intalled into a locale, they aren't even  instantiated 
> (assuming client code doesn't explicitly instantiate them).

But a few of them end up instantiated anyway as a result of
iostream classes getting instantiated (e.g., the deprecated
ones, but also the 8 iostream objects).

> 
> For example, HelloWorld might use just ctype and codecvt (that's just  
> off the cuff, I'd have to study more to get a precise list).  This  can 
> cut the code size of HelloWorld (linked statically) by 80%.

Yes, the savings can be huge. It's a lot of work structuring
the library sources to make sure that only what's needed gets
linked in and not more, but the payoff is worth it (if you
care about the sizes of statically linked executables and
compilation speed -- assuming you actually do instantiate
the templates in the library and use the extern template
extension or some such trick to declare the instantiations).

> 
> It also affords one other really nice extension:

We had this in an early version of our library but ended up
taking it out. IIRC, one problem was that for the trick to
work everything had to be a template or inline which would
tend to have unpleasant consequences for compilation times.
Another more serious issue with this had to do with the fact
that user-defined facets need not have any particular kind
of a constructor (default or otherwise), and use_facet can't
just make an assumption that it does.

Martin



More information about the Libstdc++ mailing list