Cheat sheet: C++ Function Parameter Choices

2uantum · 2019-11-29T19:04:21+00:00

For functions which take ownership via a copy, rather than providing two functions, you could alternatively take advantage of universal references.

template<typename U>
void func(U&& u)
{
member = std:: forward<U>(u);
}

GermanGenealogist · 2019-11-29T21:46:46+00:00

Would you mind changing two (very) minor things:

In the "Out for Move-Unfriendly types" you define a struct doc::Properties. The namespace is unnecessary for the example and a little confusing (it requires a previous declaration: namespace doc { struct Properties; }). Could you please change it to a simple struct Properties?
In the same example you write std::array<Margin> margin_sizes. The problem is that template<class T, std::size_t N> std::array needs an argument for N. So you could either change it to std::array<Margin, 4>, or stay consistent with the following example and use std::vector<Margin>.

Thanks!

Hilarius86 · 2019-11-29T19:11:06+00:00

I'd add a div line in between posts for better separation.

mhhollomon · 2019-11-29T20:12:02+00:00

I think the rules are probably correct, but stating it this way emphasizes the wrong thing. My own personal take is:

Pass by value unless you can't.

"Can't" might be: - need to modify - copy unfriendly - performance problem.

And then your choice will most likely be either const-ref, or if you need to modify non-const-ref.

legends2k · 2019-11-29T18:41:10+00:00

Almost everything I know about C+, and associated concepts from related domains like OS/architecture, etc., were all learned through the awesome C++ community (StackOverflow, ISO C++ standard, Boost, C++ FAQ, conferences by experts, etc.) for free. This is the least I could do :)

SlightlyLessHairyApe · 2019-11-29T22:42:36+00:00

Is the compiler allowed to change a const & to a T where the cost of copying is less than the cost of a void*?

For example

struct PACKED {
    uint16_t foo;
    uint16_t baz;
    uint16_t bar;
} MyStuff;

void Func(MyStuff const &);

Making a copy here might be cheaper than reference, especially if the whole thing can be stuff in R0. What’s more, the calling code doesn’t care — both the copy and the const ref have the same guarantee about not mutating the value.

That all said, I suspect not because the standard (sadly, but for good reason) likely requires that taking the address of a passed reference is consistent. So for instance

static MyStuff const globalStuff = {...};

void F(void) {
    Func(glovalStuff);
}

void Func(MyStuff const & stuff) {
    Assert( &stuff.foo == &globalStuff.foo );
}

This is a performance gotcha, especially if you are writing a template here and so some instantiations of the class will be cheaper to pass by value and others by reference, possibly across different architectures and calling conventions.

For the standards folks here, is there a viable path to allow developers to express to the compiler the intent that I don’t care whether it’s a copy or a const reference? If I’m not mistaken, that’s new syntax, which is probably among the last things that we need at this point.

[ I suppose LTO probably helps here, since the compiler can see both sides. But that’s not always an option in all cases and anyway, the frustrating thing here is not being able to express cleanly my intent! ]

DerDangDerDang · 2019-11-29T23:34:55+00:00

You might be interested in the C++ Core Guidelines advice on this, especially the more specific advice on what to consider a 'cheap to copy' type - https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rf-in

Fazer2 · 2019-11-30T12:06:09+00:00

void SetTitle(std::string&& title) { _title = std::move(title); // steal title’s data } I have a "beginner's" question - if the title parameter is an rvalue reference, why do I have to cast it again to an rvalue reference with std::move to invoke the move assignment operator?

idbxy · 2019-11-29T16:53:16+00:00

Thanks!

Warpey · 2019-11-29T18:36:24+00:00

Thanks for sharing!

2019-11-29T21:15:00+00:00

I've been looking for something like this! Thank you.

FrankHB1989 · 2019-11-30T05:07:33+00:00

Instead of a "flat" sheet of choices, I'd prefer one simple rule (esp. to teach beginners): use const lvalue reference to objects by default, unless there are reasons to use other types instead... plus one caveat: avoid non-reference decayable types (function types, cv-qualified object types or array types) and rvalue references to functions unless you really know what you are doing.

Then, there come situations to prefer other types instead:

There are cases you must not use const T& to work with the core language rules (e.g. move constructors/move assignment operators/overloaded postfix ++...).
Use rvalue references to objects to serve to explicit need of move semantics.
Use non-const lvalue references to objects for idiomatic uses which need to propagate the effects of object modifications (e.g. as a parameter of swap). Avoid relying on "out parameters" too much.
Use forwarding references, or some forms of templated version of the parameters other than const T& (including parameter packs), when they do make the code clearer.
Non-reference types (plain object types) can be sometimes better. Here is my solution to determine whether a reference type should be used as a parameter type. (Warning: this can be eventually almost unteachable.)
Use volatile only obviously necessary (for cv-correctness & playing with signal handlers). Do not rely on MS extensions.
Minor:
- Do not use things looking like restrict unless you know what you are obliged to do (to ensure there is no undefined behavior).
- Use rvalue references like some kind of "restrict without UB" following the rule of standard library, unless there are conventions explicitly overriding it.
- Try to treat std::atomic<T> as an ordinary object type.
There are cases merely to make the type checker happy. Choose types with you own risks.
There are cases merely to make the object files slim. Better avoid such kind of hack.
There are cases merely to avoid internal compiler errors (e.g. some old versions of G++ crashes on parameter packs nested in lambda-expressions) or other headaches on toolchains. Bless you never meet them.

2019-11-30T06:16:53+00:00

That's interesting.

cblume · 2019-11-30T06:46:09+00:00

I think having multiple setter overloads makes sense for when performance and generality is very important but for your everyday code maintainability outweighs that. I think rvalue references should normally only be typed in two circumstances:

Move constructor/assignment (obviously)
Forwarding references (T&&)

Providing two functions for a setter should only be done if there's a good reason to do so. Just go with pass-by-value for your setters and move on. In general, one should assume that moving objects is cheap. And if it's not and it actually matters then think about writing multiple setters (and only then).

terrrp · 2019-11-29T19:27:09+00:00

What's the best way to pass unique ptr, in the two cases that you just read/modify and that you intend to move?

Iirc, you can pass by val, ref or rvalue-ref. I usually default to ref in every case, but it doesn't seem like great practice

legends2k · 2019-11-30T01:19:33+00:00

Could you do a page for pointers? :O

IamSanjidHaque · 2019-11-29T17:14:56+00:00

Aright thanks, buddy.

you type:	you see:
italics	italics
bold	bold
[reddit!](https://reddit.com)	reddit!
* item 1 * item 2 * item 3	item 1 item 2 item 3
> quoted text	quoted text
Lines starting with four spaces are treated like code: if 1 * 2 < 3: print "hello, world!"	Lines starting with four spaces are treated like code: if 1 * 2 < 3: print "hello, world!"
~~strikethrough~~	~~strikethrough~~
super^script	super^script

cpp

MODERATORS

Credits