Re: [lmi] Parallel blues

[Greg Chicares]

On 2017-06-20 23:28, Vadim Zeitlin wrote:
> On Tue, 20 Jun 2017 23:10:03 +0000 Greg Chicares <address@hidden> wrote:
[...]
> GC> I really do want to preserve the possibility of writing "idiosyncrasyT"
> GC> in the "Comments" input field in order to see decimal_root()'s iterands.
> GC> But I don't want to pay this much for it. I'll find a way that doesn't
> GC> involve pointers.
> 
>  I'd be curious to see it. My favourite solution would be to use C++17
> std::optional<> but we don't have it yet -- while we already don't want to
> use boost::optional<> neither. And without it, passing a possibly null
> pointer seems to be the most concise way to indicate the absence of the
> stream.

The problem with pointers is that we must check whether they're null
before each use, or disaster occurs.

The problem with std::optional is the problem with pointers. Real pointers
have the magic value zero, and magic values are a code smell; but they also
have undefined behavior, which is catastrophic. The std::optional facility
solves the trifling problem, thereby making the catastrophic problem seem
safer, but std::optional::operator*() still has undefined behavior if bool()
doesn't return 'true'. Of course, you can use value() instead of *, and then
errors just throw bad_optional_access, so the failure is orderly instead of
disorderly; but this whole class of failures is avoidable, so it's far better
IMO to avoid std::optional altogether.

If we didn't already have the low-level concept of pointers, would we design
a language with objects that may or may not actually be valid, along with
operations that fail catastrophically when performed on objects that aren't
actually valid? Is DbC not a good idea, and is this not its antithesis?
Isn't it better to make safe usability a postcondition of construction?

> And we do need to be able to test for stream absence because
> otherwise we wouldn't be able to get rid of value_cast<> calls overhead
> which is probably more significant here than that of actually inserting
> into the stream. And to avoid it, we simply must make the calls to
> operator<<() conditional, hence we need something to test for.

Indeed. My first attempt was to set the null stream's 'badbit', which I
thought would block operator<<() because no sentry object is created;
but that didn't help, because in a '<<' chain like
  os << foo() << bar()
foo() and bar() are still called. (Setting the streambuf to nullptr
similarly didn't work.)

Then I considered whether we could just expunge the null_stream facility,
but we have code like this:

    std::streambuf* z = nullptr;
    case progress_meter::e_normal_display: z = std::cout.rdbuf(); break;
    case progress_meter::e_quiet_display:  z = &null_streambuf(); break;

where it really is useful.

Then I realized that I could implement
  bool is_null_stream(std::ostream&);
and use that to conditionalize stream output in 'zero.hpp', and its
effect on calendar_date_test's speed is the same as using #ifdef.