Re: [lmi] Parallel blues

[Vadim Zeitlin]

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.
GC> > 
GC> > [...] OTOH, forgetting to use is_null_stream() will almost
GC> > certainly go unnoticed and just result in much poorer performance during
GC> > run-time, even in production code. This doesn't seem like a good trade off
GC> > to me.
GC> 
GC> Yes, we can do better.
...
GC> But we don't really need value_cast<>() here

 Sorry but I still don't think this is better than just using an ad hoc
optional_stream class. Now we need to remember to not call value_cast<> or
any other expensive function instead of having to call is_null_stream()
which is even less discoverable and more likely to be forgotten. And even
if we do remember to do this, we still get a noticeable performance
pessimization. To me this really looks like almost the worst of the two
approaches.

 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
                ;
            }

which requires fewer changes (not counting writing optional_stream, but it
or, especially, optional<>, would be useful to have in other places too),
has 0% overhead when debugging is not used and is perfectly safe in the
sense of avoiding undefined behaviour (I assume that implicit
conversion/accessor of optional_stream would throw if it's null).

 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.

 Regards,
VZ