Hi Robert,

It's hard to convey how much time and frustration is consumed in the tracking down of this stuff. Making a Boost library that is widely used is much, much harder than most people think.

Delivering for multiple platform/compiler/library versions is hard, and Boost library authors don't get enough thanks for doing so; so thank you. I'll try to help with rules of thumb for working with the sync and locale related functions though. At 27 October 2015 17:43, Robert Ramey wrote:

as far as I can tell, streambuf have (pub)sync() declared and defined in all of the libraries. So one would think that all he has to do is to apply the (pub)sync and (pub)imbue to the streambuf and be done with it it. Well, one would be wrong. Spelunking the library source code, it seems that at least in a) and c) the stream caches the locale as well as passing on to the the streambuf. This suggests that the locale should be changed at the stream level when the library implements it (contrary to the standard.) And in fact, if one fails to call sync() at the stream level in a) (at least on input) the program will crash in a particularly hard to detect manner.

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. 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. 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. Best of luck making the test matrix green! Gareth ************************************************************************ The information contained in this message or any of its attachments may be confidential and is intended for the exclusive use of the addressee(s). Any disclosure, reproduction, distribution or other dissemination or use of this communication is strictly prohibited without the express permission of the sender. The views expressed in this email are those of the individual and not necessarily those of Sony or Sony affiliated companies. Sony email is for business use only. This email and any response may be monitored by Sony to be in compliance with Sony's global policies and standards

Hi Robert, As you noted, I haven't followed this thread from the beginning so I've missed some context; I hope these comments are still useful. On 27 October 2015 19:34, Robert Ramey wrote:

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.

Libraries that work with iostreams can choose whether to be polite or not. One example is implementing op>> etc. with state savers. Nothing in iostreams forces you to do this, but it results in least surprise for the owner of the stream. I think using the stream interfaces for imbue, sync and others rather than going to the streambuf interfaces is another example of this practice. (Of course, where similar functionality is presented via the stream interfaces and the streambuf, the stream interfaces often have overhead, e.g. use of the sentry. When the op in question is something you're doing in a tight loop, it makes sense to call the streambuf directly, wrapping the whole loop in the necessary gubbins to meet an "as if" expectation.)

...

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.

I was describing the use of basic_ios::imbue(). N3797 - 27.5.5.3 [basic.ios.members] para 9.

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

Calling flush() on a basic_ostream results in pubsync() on its streambuf, just as calling sync() on a basic_istream does. N3797 - compare 27.7.3.7 [ostream.unformatted] para 3 with 27.7.2.3 [istream.unformatted] para 38. Best regards, Gareth ************************************************************************ The information contained in this message or any of its attachments may be confidential and is intended for the exclusive use of the addressee(s). Any disclosure, reproduction, distribution or other dissemination or use of this communication is strictly prohibited without the express permission of the sender. The views expressed in this email are those of the individual and not necessarily those of Sony or Sony affiliated companies. Sony email is for business use only. This email and any response may be monitored by Sony to be in compliance with Sony's global policies and standards