Re: [boost] [operators] A modern SFINAE-based version of boost::operators?

Subject: Re: [boost] [operators] A modern SFINAE-based version of boost::operators?
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2017-11-15 00:35:45

> If you pass in an rvalue reference, you *do* expect it to be modified and you do not expect it to be accessible afterwards.

That's only an until-so-far STL convention.

In my own code I treat rvalue references as "this may or may not be
consumed" parameter. So the function may consume the input wholly,
leaving it in some zombie state. Or it may leave it as is. Obviously the
return type says what happened.

This lets you write filtering functions such as:

SomeObj foo.
filter_a(std::move(foo));
filter_b(std::move(foo));
filter_c(std::move(foo));
filter_d(std::move(foo));

Now some will quite rightly object to using std::move when I mean "maybe
move". I should really type out:

filter_a(static_cast<SomeObj &&>(foo));
filter_b(static_cast<SomeObj &&>(foo));
filter_c(static_cast<SomeObj &&>(foo));
filter_d(static_cast<SomeObj &&>(foo));

But it takes too long to type, so I use std::move.

In case anyone thinks I am being weird on this, I was taught to think of
rvalue ref parameter inputs this way by Howard Hinnant. It's been a
useful technique to know. I just wish clang-tidy didn't warn on this
technique so readily.

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/