Re: lazy facet instantiation

[Howard Hinnant <hhinnant at apple dot com>]

On Nov 15, 2005, at 8:32 PM, Martin Sebor wrote:

> Howard Hinnant wrote:
> [...]
> > Here I think we have a minor misunderstanding.  I'm only  
> > proposing  special treatment for standard facets instantiated on  
> > "reasonable  types".  For example, the same restriction on  
> > character types as  basic_string imposes for charT.  Likewise for  
> > iterators.  No special  treatment for user-defined facets.
>
> Isn't the problem the same? ctype<C> can be a user-defined explicit
> specialization of the facet (in fact, I don't think it could exist
> otherwise given the restriction on explicitly specializing member
> functions of standard class templates), so it need not have the
> expected ctor. Or am I missing a requirement that members of all
> specializations of the standard facets must have the same signatures
> as those of the required instantiations (i.e., those specified in
> the synopses)?

Oh, I see, thanks.  You always come up with the most evil situations!  
(which is of course very good).  So let me back off a little.  I  
don't want to propose that we support  
standard_facet<any_type_you_want>, including specializations.  I  
merely suggest to support standard_facet<scalar> or perhaps even  
standard_facet<pod>.  It is an extension, not a standards suggestion  
(at this point).  If the user specializes  
standard_facet<user_defined_type>, then he can rightly miss the  
private triggering mechanism and get the generic use_facet behavior.   
That is, the triggering mechanism could be that facets we know about  
contain a nested __type we check for.  The user's specialization  
wouldn't legally be able to contain the nested __type, and thus can't  
trigger the special treatment.

Not many people want to fool around with facets.  But a surprising  
number want to instantiate streams on scalars other than char and  
wchar_t.  And this requires standard_facet<scalar>.  Thus the  
motivation.

> Also, I wonder how use_facet<ctype<C> >(some_named_locale) decides
> whether it should construct ctype_byname<C> or just ctype<C>? What
> if there is no ctype_byname<C>? Fun stuff! :)

My suggestion would be to just construct ctype<C>, or perhaps more  
exactly - to execute whatever code would have otherwise been done at  
locale default construction.  The basic idea is to spread the work of  
the locale construction out over the use_facet calls.  The gamble is  
that most of that work will never need to be done.  In my experience  
the gamble pays off handsomely most of the time.  When it doesn't pay  
off (say the client uses every standard facet), you really haven't  
lost anything.

-Howard