|
Boost : |
Subject: Re: [boost] [serialization] Massive failures in develop?
From: Robert Ramey (ramey_at_[hidden])
Date: 2015-10-17 16:15:27
On 10/17/15 11:07 AM, John Maddock wrote:
>
>> a) refinement of codecvt facet lifetime issue.
>>
>
> I think this is the issue, you:
>
> * Create the facet as a data member of the archive.
> * Imbue it in a locale and then install that locale in the iostream.
>
> Now on destruction:
>
> * The archive is destroyed first, this destructs the locale facet
> *that's still in the iostream*.
> * The iostream then calls the destructor on an object that's already
> been destroyed.
>
> Depending on the virtual function / destructor implementation, you may
> or may not see this as an error at runtime.
>
> So I think you need to back up the iostream's locale and restore it in
> the archive destructor if you want to go this way.
>
> Apologies if I've misread your code,
This sound correct - as far as it goes.
Previously, I used stream_buffer_saver - which is now not in there.
This saved the current locale when created and restored upon termination
of the archive. The motivation was to permit a user to have his ostream
settings unchanged if the serization i/o was introduced in the middle of
the stream.
This worked as advertised - accept on some gcc configurations. I
tracked the problem (in my mind anyway) to the standard system where by
one creates a new codecvt facet on the heap and passes it to the
streambuffer that manages the life time of this object. I spent a lot
of time trying to make this work but couldn't get to the bottom of it.
Thinking about it, I built the facet into the archive class so that the
lifetime managements issues would be resolved. In the course of making
this work, I dropped the streambuffer_saver. My intention is to put
that back in now that I think I've got everything else sorted out.
It's sounds simple now - but the original problem I was trying solve
only appeared when using the utf8_codecvt facet to convert strings with
russian characters in it. Somewhere it seems there is a coupling that
is hard to discern. But anyway, I think I've got it almost where I want
it to be.
>
> HTH, John.
>
> Update: I think I have a fix, testing now...
Thanks, I'll take a look at it.
Robert Ramey
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk