This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: [v3] Revised locale caches
>1) If someone specializes numpunct<sometype>, there probably won't be
> a cache. With the solution I had posted, we will still cache the
> values. The only way for that to work is to have it outside the
> facet itself - or perhaps in locale::facet, where everyone is
> forced to pick it up.
Let me think some more about this. I'm looking at examples, but I think
it is possible.
> If you think that this issue isn't important enough to keep the
> caches external to the facets, then I won't argue the point
> further.
I think it can be worked around by re-arranging the templates.
>1) There should probably be an accessor to the underlying cache data,
> rather than relying on numpunct == numpunct_cache*
Agreed.
>2) I'd rather see the __use_cache function in the tcc file as a
> template. Except then we run afoul of #1 :-(
>
> Moving the __use_cache function specializations here buys a 2-3%
> speedup on the int output test.
Agreed. This part is pretty flimsy.
>3) I don't think we need the allocated flag. The only time the data
> isn't allocated is for the posix locale, and the destructor will
> never run.
Vestigial data... you are right. I'll fix this.
>4) It's not safe to require the existence of ctype in setting up the
> numpunct cache. Some uses will not require it, and shouldn't blow
> up as a result. My posted solution suffers from a similar issue.
I think this is ok as long as the cache is used when both facets need to
be present. I'll look at this tomorrow.
>6) This can't be backported to 3.3 since it changes the ABI. So, can
> we keep the version I posted alive for that? I'm pretty confident
> I can make that work in 3.3 within the ABI. Including a cache per
> facet.
Sounds like a plan.
>It's too late tonight, but I'll do the minor changes above tomorrow
>night.
Alright then. I'll check this in, and we can both work from it.
> > Let me know what you think. I'd like to go through and do num_get
> > (painless now), as well as the other data facets (__timepunct,
> > __moneypuncts) in a similar style.
>
>Can we get this in first and then do the other facets? :-)
Agreed.
-benjamin