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>
>> 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
> 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
> 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
> simplify the library and remove some "hidden" behavior - which I like.
> But it would also guarantee that many (or most) users would be getting
> 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)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk