Re: [boost] [serialization]cannot build libboost_serialization.so.1.60.0 with Oracle Solaris Studio

Subject: Re: [boost] [serialization]cannot build libboost_serialization.so.1.60.0 with Oracle Solaris Studio
From: Robert Ramey (ramey_at_[hidden])
Date: 2015-10-27 15:34:23

On 10/27/15 11:36 AM, Sylvester-Bradley, Gareth wrote:
> Sync is a function that only applies to input streams, not output. (Flush is more-or-less the equivalent for output streams.)
> If our library code is handed a stream to work with, not a streambuf, it makes sense for the library to call sync() rather than rdbuf()->pubsync() so the caller sees the stream state (badbit, etc.) updated as expected.

Who is "our" in this context?   Some particular library?  Surely one 
can't speak for all implementations.

> Locales affect formatted input functions, which is why the stream (in its ios_base) caches the locale.
> But the streambuf needs it too for the codecvt facet.
> Again, as you suggest, if our caller hands us a stream to work with, it makes sense to imbue the stream which (via its basic_ios)
 > makes sure both ios_base and its streambuf have the same locale. I 
think the standard indicates this too.

Hmm - I don't think so - that's exactly my problem - ios_base for libc++ 
doesn't include a sync() function on ouput - does for input though.  on 
gcc I HAVE to call it or the program crashes.  The standard only 
mentions it on
>
> Standard libraries from before templated iostreams are, one hopes, long out of scope, but Boost.Iostreams still has the necessary configuration macros if they're not.
>
>
> That's based on my experience with similar suite of platforms/std-libs/docs as you're knocking into shape,
 > and it may all have been obvious to you after all your research, 
sorry if so.

LOL - now I'm thinking it would have been better if stlport failed 
sooner to get you sucked in that much sooner.

Robert Ramey