[boost] [serialization] all wide tests were failing

From: Robert Ramey (ramey_at_[hidden])
Date: 2004-04-14 11:24:02

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

> In fact, I'm getting suspicious about changing codecvt at all. I suppose 
> that if somebody is using wide streams, he already deals with encoding 
> somehow, so why serialization library should try to second-guess the user?

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.

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.

Robert Ramey