Menu
Suppose we have a class Foo with a non-explicit constructor from an int. Then for the following functions:
Foo makeFoo1() { return 123; }
Foo makeFoo2() { return {123}; }
I think makeFoo1 requires that Foo's copy/move ctor is accessible, and it's possible (though unlikely) that the compiler does not elide the copy and thus results in a true copy/move.
For makeFoo2, since we are using copy-list-initialization, no copy/move can ever occurred.
Should I really worry about this and put arguments to non-explicit ctors in braces whenever I can (as in makeFoo2)? (Say if I'm a library author and expect the library to be used with subpar compilers for embedded system.)
692
The following function searches through an array of integers to determine if a match exists for the variable number . If a match exists, the function match returns the value of i . If a match does not exist, the function match returns the value -1 (negative one).
A return statement ends the execution of a function, and returns control to the calling function. Execution resumes in the calling function at the point immediately following the call. A return statement can return a value to the calling function.
return {}; means that {} is the initializer for the return value. The return value is list-initialized with an empty list.
When a return statement is used in a function body, the execution of the function is stopped. If specified, a given value is returned to the function caller. For example, the following function returns the square of its argument, x , where x is a number. If the value is omitted, undefined is returned instead.
I'll go out on a limb here and combine a practical answer with a weak language-lawyery justification.
The weak language-lawyer argument: If I understand this cppreference.com description correctly, you are not guaranteed RVO when initializing with an initializer list (makeFoo2) any more than you are with just your int return (makeFoo1). So, don't surround your int in braces.
Practical argument 1: Come one, those braces have got to be redundant. They should be redundant. So don't use them, it doesn't seem right.
Practical argument 2: The principle of least surprise. Using those braces, you're implying there's something wrong with the brace-less form. I would be confused and slightly surprised by the braces (albeit not very confused).
Practical argument 3: In these kinds of situations - trust the compiler. This is not where your performance bottleneck is (and if it is - make it an inline function, and it won't be; or use a reference if you have an existing object; etc).
95
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
