This is the mail archive of the
mailing list for the libstdc++ project.
- From: Loren James Rittle <rittle at latour dot rsch dot comm dot mot dot com>
- To: libstdc++ at gcc dot gnu dot org
- Date: Sat, 22 Feb 2003 02:10:43 -0600 (CST)
- Subject: generic locale
I have a request for the users of non-glibc ports and all library
developers. The current generic locale code ignores all locale()
objects created by users. I see why Benjamin did this based on the
C89/C99 API in this area. However, I think I see how to improve the
generic situation with various degrees of effort/risk/reward.
Here are the choices I would like user input on:
(a) keep the status quo; do not throw exceptions for e.g.:
locale loc_de("de_DE"); istringstream iss; iss.imbue(loc_de);
even though they have no effect on input handling, etc.
(b) At least throw an exception in generic for all user instantiations
of locale() objects unless they map to the "C" (or ""?) locale.
This, at least, better matches reality. (Optionally, modify all
22_locale test case per Martin's idea and/or catch the
generic-doesn't-handle-non-C-locale exception and accept that as
an OK run-time termination.)
(c) make generic work for single-threaded programs no matter how slow
it is; use my system's libc dammit (note: the status quo is already
broken w.r.t. threading since any unguarded call to setlocale()
are unsafe and we would have no idea what users might do outside
the library code)
(d) make generic work for multi-threaded programs (as long as all IO
is C++-style, see note in c) no matter how slow it is; use my
system's libc dammit
(e) make generic work for multi-threaded programs (a small race would
remain against user programs with threads of control that called
setlocale() directly but protect internal library use); use C89
locale calls only to fetch "struct lconv" from OS but otherwise
assume that IO conversions are now disconnected from libc
(f) do whatever you want Loren but put it in 'enhanced-generic' which
is cloned off generic to start
(z) lobby libc maintainers everywhere to add MT-safe API points that
match up with glibc
They are listed in the order of hardness with the exception of (f)
which I assume will operate under relaxed checkin requirements since
it can't possible break anyone else unless they manually request it.
That said, (f) probably wouldn't be checked in until it passed
all/many 22_locale tests on at least one port. I personally favor
doing (b) ASAP and then (f) [where f probably looks like c or e in
practice without the risk of breaking rarely tested ports].
Comments? Are people starting to care about C++ locale support? I
admit that I am one of those "one-language speaking" Americans that
knows little beyond the fact that the English actually speak a
different language than us. ;-)