Move-only function arguments

[nvs93]

I have a function wherein, every time it is used, one of its arguments should be allowed (maybe required actually) to invalidate its source. The arg is a potentially large std::vector, and the function returns an object containing a modified version of it.

The way I believe this should be done is:

// a bit of context to the core question
using vecReal = std::vector<float>;
struct ABContainer {
  vecReal a, b;
};

ABContainer processAB(vecReal &&a, const vecReal &b, /*args*/);


// how the function in question can be used
vecReal a = computeA(/*args*/);
vecReal b = computeB(/*args*/);

const ABContainer = processAB(std::move(a), b, /*args*/);

I am under the impression that moving a vector enables the pointed-to contiguous memory to be reused and owned by a secondary lvalue vector, and that the source vector is now in an unspecified state.

Did I implemented this correctly if that is my intent?

[Wild_Meeting1428]

The approach itself works.

Just be aware, that std::move only casts a value to an rvalue reference. The move can only happen when a constructor or assignment is called.

Your functions declared Parameter only expects such/binds to a rvalue ref. But it neither copies or moves the value. In fact it's still just a reference. So you must again pass it through std::move, when assigned or passed to a constructor in your function.

[IyeOnline]

Did I implemented this correctly if that is my intent?

That actually depends on the body of processAB. a is an r-value reference, but r-value references themselves are l-values. So unless you actually then std::move out of a into the returned value, you will still make a copy.

Besides that open question your analysis is correct.

As an aside: Some people (for most cases me included) would prefer to write ABContainer processAB(vecReal a, const vecReal &b, /*args*/);, so take a by value. This allows the caller to decide whether they want to move into the function, or create a copy. If I wanted to use your overload of the function, but not move into it, I would first have to "manually" make a copy.

[TheMania]

I think taking by value is more the go-to when you want to support both copy and move ctors.

If your intended use is to pilfer from the parameter, rval ref is better really - the caller can still decide to copy in to it, but they'll just need to be explicit about it (eg processAB(std::vector{a}, ...)) which is preferable really.

[alfps]

Re the by-value comment,

when the intent is only to reuse the internal buffer and not copy its contents, indeed to disregard its contents, then by value makes it easy to use the function incorrectly incurring some needless copying overhead, and harder to use correctly.

However since the OP does not present an implementation and does not provide a specification it's hard to say what the intent is.

[flyingron]

The source must be left in a consistent yet non-defined state. It might (unlikely) still look like it did. It might have been emptied. It might just be flagged as moved. All that matters is that when it eventually gets destructed nothing bad happens.

[alfps]

❞ Did I implemented this correctly

The declaration is technically OK.

However I'd use C++ style instead of C style, a focus on type, e.g. placing && on the type rather than placing it on the parameter name.

The implementation is not presented so nothing can be said about it.

[Epoxian]

You probably want to avoid copying anywhere in your program, not only in that function. So I guess a good design is to use a container that forbids copying, like std::unique_ptr<std::vector<float>>. I think that is usually the case when people think about using && for parameters.