[lmi] save() vs. save() && [Was: PATCH: use std::uncaught_exceptions()]

[Greg Chicares]

On 2018-04-02 13:21, Vadim Zeitlin wrote:
> On Mon, 2 Apr 2018 00:52:46 +0000 Greg Chicares <address@hidden> wrote:
[...]
> GC> There's something else I don't understand: why use move semantics here?
> 
>  Solely to make it clear in the code calling save() that it's the last
> thing that can be done on the object and to prevent it from being called
> twice accidentally. The idea is that if you see
> 
>       std::move(pdf).save();
>       pdf.output_xxx(...);
> 
> in the code, you would immediately realize that something is wrong here
> because the object is not supposed to be used after being moved from (and,
> hopefully, in the future clang-tidy might detect it automatically).

You might immediately realize that. I wouldn't. I'd just wonder why
move semantics were applied where nothing was moved. And if those
two hypothetical lines were separated by a few dozen other lines, or
if they occurred in different files, I wouldn't even imagine that
the second line wasn't okay--but the first line would still look like
a strange mistake.

> GC> Or did you ref-qualify save() only to prevent any other member function
> GC> (other than the dtor) from being called after save()?
> 
>  Yes.
[...]
> GC> and is there no other way to achieve it?
> 
>  I don't know of any.

But you already did achieve it in a different way: with assertions.
There was only one member function (aside from the dtor and the
trivial const accessors for page metrics) that didn't have an
assertion on its first line to prevent it from being called after
save(), and I plugged that last hole here:
  f5651d19 Prevent save() from being called twice
so now there's no need for the '&&' qualifier. I understand that
a future compiler might have given a compile-time warning, while
assertions fail only at run time. I understand that you're trying
to achieve every possible advantage of implementing save() in the
dtor, and that this '&&' would achieve something kind of like that.
But it's just too obscure for me.