Artyom Beilis wrote:
Hello!
Actually such utilities are and would be very useful.
The stateful manipulator is rather something simple
I agree, very simple but so easy to use :)
however the second part the "state saver" is something very important.
In fact today Boost.DateTime uses for example locale facet to provide such information which is wrong by design. If such state saver was around when it created it would be much better.
Yes, Boost.Chrono I/O V1 is using this design also. I'm creating a Boost.Chrono v2 design that stores information like duration style, timezone, time format in the ios state. The inconvenient is the thread safety and inter-module interferences. I think that the locale/facet approach doesn't suffer from these thread and inter-module issues. What do you think? Anyway the IOStream library is not thread safe, so the user can not use them without falling in undefined behavior. The inter-module issue is another history.
So my +1 and big one.
Few points. ------------
I had already implemented state saver for Boost.Locale but it is hidden in the sources, it has a little bit different approach but in general it is very similar.
https://svn.boost.org/svn/boost/trunk/libs/locale/src/shared/ios_prop.hpp
Glad to see others have taken the same approach. I will not call that a state saver, just a state.
I'd also suggest to add std::ios_base::imbue_event handing because it may be actually important. (Consider some caching withing object)
Yes, all the callback events shall be taken in account.
Now some important (extremely important) notes about this code: ---------------------------------------------------------------
static inline int index() { static const int v_ = std::ios_base::xalloc(); return v_; }
1. This code may be not thread safe and may create two different values for two different threads.
So I'd suggest to provide some global initialization option to at least illeminate somehow this problem or to use Boost.Thread's ones initialization.
I agree, the code is not thread safe.
2. This code can't be used on cross dll boundaries.
Consider you have function (non-linline) boost::foo::bar in libboost_foo.dll that updates manipulator in the exe other inline function boost::foo::baz uses it.
You'll be surprised what will happen: the "static const int v_" in the index() function would have two instances and would allocate two distinct indexes.
I know these issues. The final implementation would need a kind of thread safe and multi DLL singleton, maybe based on the holder included in Boost.Flyweight.
3. You should never use it with static linked runtime and dlls (of course) because there will be two instances of xalloc()'s counter.
But this is related to gcc 4.4 and below on Windows only.
So library should be very careful and not use such smart pointer in inline instances and this should be written with big red letters in the top of the library docs.
Well I see two alternatives here: either the library state that this can be used in a single threaded program and in a single module, or it is thread and intermodule safe.
That is why Boost.Locale's ios_prop.hpp is hidden in sources.
How the fact to hide it makes it more thread or module safe. Could you clarify this?
(Yep... dll platforms sucks... :-) or make our work a way much harder)
________________________________ From: Vicente J. Botet Escriba <vicente.botet@>
Hi,
I'm a beginner of the standard IOStream library. While restructuring Boost.Chrono I/O I have find some classes that could be of general use (if
Yes, and unfortunately this is something we need to live with :( Best, Vicente the design is correct, of course).
The first one is quite simple, is used to define manipulators with
parameters. Instead of defining a class and the correspondent stream inserters and extractors the manip template class do all this at once.
[snip]
Do you see a design flag on these classes? If not, do you think these kind of utilities could be added to boost? If yes, could these be merged with Boost.io_state_savers or Boost.IOStreams
to form a larger io utilities libraries? -- 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.