[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: |
Wed, 21 Jun 2017 12:26:36 +0000 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 |
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.
- Re: [lmi] Parallel blues, Greg Chicares, 2017/06/20
- Re: [lmi] Parallel blues, Vadim Zeitlin, 2017/06/20
- Re: [lmi] Parallel blues, Greg Chicares, 2017/06/20
- Re: [lmi] Parallel blues, Vadim Zeitlin, 2017/06/20
- Re: [lmi] Parallel blues,
Greg Chicares <=
- Re: [lmi] Parallel blues, Vadim Zeitlin, 2017/06/21
- Re: [lmi] Parallel blues, Greg Chicares, 2017/06/22
- Re: [lmi] Parallel blues, Vadim Zeitlin, 2017/06/22
- Re: [lmi] Parallel blues, Greg Chicares, 2017/06/27
- Re: [lmi] Parallel blues, Vadim Zeitlin, 2017/06/27