lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] Parallel blues


From: Greg Chicares
Subject: Re: [lmi] Parallel blues
Date: Tue, 27 Jun 2017 21:26:39 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0

On 2017-06-22 13:42, Vadim Zeitlin wrote:
> On Thu, 22 Jun 2017 13:32:53 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> On 2017-06-21 12:50, Vadim Zeitlin wrote:
> GC> > On Wed, 21 Jun 2017 12:26:36 +0000 Greg Chicares <address@hidden> wrote:
> GC> [...]
> GC> > GC> Then I realized that I could implement
> GC> > GC>   bool is_null_stream(std::ostream&);
> GC> > GC> and use that to conditionalize stream output in 'zero.hpp', and its
> GC> > GC> effect on calendar_date_test's speed is the same as using #ifdef.

Setting 'badbit' automatically for null streams means that no such
function is necessary: it suffices to test the stream state (see below).

>  Compare with:
> 
>       if(iteration_stream)
>           {
>           iteration_stream
>               << "iteration " << number_of_iterations++
>               << " iterand "  << value_cast<std::string>(a)
>               << " value "    << value_cast<std::string>(fa)
>               << std::endl
>               ;
>           }

That's what I've done, except with a slightly different test:

- if(iteration_stream)
+ if(iteration_stream.good())

IOW, the optional<> nature is already embedded in the stream state.

>  It's still not Rust level of safety, but not far from it and seems
> definitely better than hacks with setting bad bit to me.

OTOH, the natural state of a null stream would have 'badbit' set.
This way, if we don't remember to use a "safe" accessor, end users
don't see an exception--they don't see anything at all, which is
exactly what we want.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]