Re: [boost] Re: formatting manipulator for UTF-8

From: Karl Nelson (kenelson_at_[hidden])
Date: 2000-08-22 10:31:33

> Karl Nelson wrote:
> 
> > This isn't a dark place, but rather just a bit of ambiguity.
> > My current implementation used two formats in a row to mean
> > "dump current and use this one".  However, that functionality
> > could be dumped in place of the other meaning.   Also one would have
> > to ask is the current behavior that extra arguments are placed
> > in the stream appropriate as well.
> >
> >   cout << format("%d %d") << i << j << format("%d %d") << k << l;
> >
> > (is the second format bad because the first one forgot the endf
> > or should the second flow to the first?)

Perhaps if I write it as the streams will see it that will answer your
question....

     format_stream(cout,"%d %d"),  
       (strstream << decimal << i),
       (strstream << decimal << j),
     cout << string() << string("1") << string(" ") << string("2") << string(),
     format_stream::new_format
       (strstream << decimal << k),
       (strstream << decimal << l),
     cout << string() << string("3") << string(" ") << string("4") << string(),
     
In other words all the strings are being spooled up in the 
a local variable via strstreams and then pushed to cout when
all arguments are done.

Since each format spooler its own local variable no globals
are needed nor does it actually change the state of the 
stream until after it has all of its arguments. 

> I just got scared with this method.  The biggest problem I'm seeing here is a
> global state.  What if I'm in a multithreaded situation?  I realize I'm going
>  to
> have problems writing to the same stream from two different threads, but woul
> d
> this maintain a different state for each stream?  

Since the manipulators are never applied to the cout stream directly
but instead to a buffer you should never get any changes of state
on your output.  (Nothing done in a format should be sticky)
You should still lock the stream as having 2 threads dink with the same
stream is asking for trouble.

>I didn't look at the code s
> o my
> concern may be unfounded.

Did that answer your question?