That is a much better example!

Of course, string_view, iterators and the return type of reversed() are non-owning and store a reference. I’m still searching for the right words… They are all temporary objects. It is easy to see that they never have a dangling reference. Except they are used as non-temporary objects.

What I want to say: Dangling references are very hard to debug. If people never see code which store references, people never write code which store references. And that should be our goal. To show the people to use the right techniques.

If one need a non-owning string object: use std::string_view. It is primary designed to use as temporary object. If one need a permanent non-owning string object, use this or that pattern.

Aah, I see. I’m sorry, I don’t know… 🙁

Thank you for your comments.

Maybe I chose the example wrong. I didn’t want to add more complexity. Have you ever used string views? They aren’t owning either.

Imagine you want to make (function/object/whatever) that lets you see a container in reverse (a la rangesv3), so that you can do something like:
for (auto&& x : reversed(mycontainer))
{
// do stuff
}

But you don’t want all the elements in mycontainer to be copied, as this would incur a nontrivial performance penalty. What can you do? Reversed must store a reference to myContainer. But then this won’t work:
for (auto&& x : reversed(get_container()))

The solution proposed works on both cases, and never makes a copy. Of course, you could, in this case, do:
for (auto it = mycontainer.rbegin(); it != mycontainer.rend(); ++it)
but aside from begin ugly and not expressive, what if you instead want a filter? or any other “view” type thing?

Hey, thanks for the reply but you misunderstood me. I was just inspired by your post to ask a bit unrelated question. My class looks like:

class bar {
std::shared_ptr myptr; // could be a more expensive-to-copy resource
void foo() const & {
// copy myptr and do work with it
}
void foo() && {
// here I can move myptr
}
};

I know foo() will often be called on rvalues, and there’s no reason to pay for what I don’t need, but is there an alternative to writing the same method twice?

Fixed, thanks!

The topic is very interesting. To choose between const& or to move for function parameters is helpful to not duplicate code.
A thing which displays text either owns it’s content or not. But not both. If it not owns the content it have to ask the owner if there is something to display. That’s the way to go.

I have a (german) example which extend sort() with a visitor which can passed a lvalue or rvalue. You may want to take a look http://roboblog.fatal-fury.de/?p=3390
Thomas

What happened is that in my original implementation I was using a forwarding reference in the constructor too, (like template TextDisplayer(U&& u)) but then realized I didn’t need it, but never realized that it’s not called a forwarding reference then.

I don’t think the use case is the same. First, shared_ptr is a pretty small object, so copying or moving cost almost the same (except that moving does not update the control structure associated to a shared_ptr, but oh well). Also, you are not holding the shared_ptr by reference like, ever, so the use case is not the same.

I would pass-by-value-and-then-move, like so:

class MyClass
{
public:
MyClass(std::shared_ptr ptr) : mypointer_(std::move(ptr)) {}
private:
std::shared_ptr mypointer_
}

Then if you get passed an lvalue it copies, but if you get passed an rvalue it moves.

Compare this to what we were trying to accomplish in the post, in which if you get passed an lvalue it *references*, and if you get passed an rvalue it moves.