$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
From: Vladimir Prus (ghost_at_[hidden])
Date: 2004-04-15 01:36:56
Robert Ramey wrote:
>> What this means is that destructor of archive *really should* call
>> 'flush' on the stream. After I've made basic_text_oprimitive's destructor
>> to flush stream:
> 
>>     template<class OStream>
>>     basic_text_oprimitive<OStream>::~basic_text_oprimitive(){
>>        os.flush();
>>     }
> 
>> The test_vector passed with wide stream. I'm rerunning other tests now.
> 
> Good call. I never would have guessed this.
BTW, the tests result I see this morning are much better -- only 5 failures.
> I have also started to have second thoughts about this. In the original
> version I didn't concern myself with codecvt .  This created problems
> however:
> 
> a) the i/o library silently used a codecvt facit that just narrowed the
> output characters - silently throwing away the high order bits on wide
> characters.  This behavior was surprising, confusing and hard to find.
Yea, that's true.
> b) even on char ouput, the default codecvt facet when through a large
> amount of code when all that was really necessary was to pass the
> characters through without change.
> 
> That is, the standard library implementation picks a facet which may not
> behave in the manner that we (the user) expects.  So I determined that I
> would "fix" this in the library.  The state-saver system worked in
> perfectly.
> 
> The possibility that it might not possible change the codecvt facet after
> the file is opened has made me wonder about this.  I'm still  undecided.
> The dinkumware library definitely works in this way and I believe that STL
> Port does also.  Removing "automatic" imbue/unimbue to for the library
> would
> simplify the library and remove some "hidden" behavior - which I like. 
> But it would also guarantee that many (or most) users would be getting
> something
> other than what they expect.  I'm still considering this.
I wonder if we should just provide boost::wofstream will will use the
'right' facet. Then, docs for serialization will include a big warning that
std::wofstream might fail, so user is advices to use boost::wofstream (or
provide his own facet)
- Volodya