Re: [boost] [iostreams][io_state_savers] Request for interest in some ios_base basic utilities

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

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

Best,
Vicente

>________________________________
>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
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-interest-in-some-ios-base-basic-utilities-tp4020844p4022873.html
Sent from the Boost - Dev mailing list archive at Nabble.com.