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