Artyom Beilis wrote:
From: Vicente Botet <vicente.botet@>
Artyom Beilis wrote:
----- Original Message ----- Also it can be extended with some new styles easily if needed like for example "duration" style.
So I'd suggest to use them.
I'll take a look, but I don't think that I will be able to use the Boost.Locale manipulators, as the intents is to make a proposal for the standard, so dependence on other libraries should be minimized at least at the interface level.
Actually I'm planning to do some proposals with Boost.Locale but I see your point.
For example xalloc is thread safe in both MSVC and GCC libraries.
I don't like this kind of design, which forces the user to initialize the library. I will expect we can do better.
Global constructor?
I don't see what you mean.
I don't know if chrono is header only library or not.
Just you need to make sure that such library can't be header only. As long as it is not header only there will be no such problem.
Well I spent some time to make Boost.Chrono header only. I will be a little bit disappointed if I can not make a library that uses standard I/O thread safe other than using some tricks that can not be used in a header only library.
The problem is rather inter module access rather then thread safety issue. And inter module access (cross dll) you can't do without library part under DLL platform...
And singleton can't be done in header only library under dll platform as well.
Isn't Boost.Flyweight a header only library?
So... It is problem. However it is not problem for standard submission as you always have library - standard c++ library which by no means can be header only.
Well for the standard submission there is thread or module issue if this state is included directly on the ios state and the default facet is already imbue with the associated facets ;-). Of course this is something I cannot do with Boost.Chorno, or I don't know how to do it :'(.
For example all locale ids and all xalloc ids are initialized once globally.
Beside the static data initialization, how do you ensure the access (R or W) to the ios state flags and locale facets are thread safe? Are you using a mutex?
Locale facets, once installed are immutable objects. So they become thread safe by immutability(*) as they either operate on constant data.
Yes I see. Only the facet id is concerned by multi-threading.
Now ios state flags should not be thread safe as they stream specific and I don't expect from user to alter iostream flags from different threads.
(*) With ICU not all facets are immutable so in some places I use TLS to improve performance as for example with collator.
Why do you need mutable facets? Isn't this against the locale/facet design? Best, Vicente -- View this message in context: http://boost.2283326.n4.nabble.com/iostreams-io-state-savers-Request-for-int... Sent from the Boost - Dev mailing list archive at Nabble.com.