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: Sylvester-Bradley, Gareth (Gareth.Sylvester-Bradley_at_[hidden])
Date: 2015-10-28 05:26:09

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