Boost logo

Boost :

Subject: Re: [boost] [iostreams][io_state_savers] Request for interest in some ios_base basic utilities
From: Vicente Botet (vicente.botet_at_[hidden])
Date: 2011-11-10 03:59:31

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.

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

> 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)

Yes, and unfortunately this is something we need to live with :(


>From: Vicente J. Botet Escriba <vicente.botet@>
>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
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:
Sent from the Boost - Dev mailing list archive at

Boost list run by bdawes at, gregod at, cpdaniel at, john at