hi,
i'm currently in practice with c++, i found a situation(not critical).

as i read from tutorial & article, it said that good thing in passing argument by reference, but not to change the value inside the function, is to use the constant-references as the function parameter.

in situation that i just want to pass the argument to a function just for resource only, not to change the value itself,
1. so when is the right time to use the by-value parameter ?
or
2. when is the time not to use the constant-references parameter ?

may anyone have suggestion..

thank you,
happy coding

in situation that i just want to pass the argument to a function just for resource only, not to change the value itself,
1. so when is the right time to use the by-value parameter ?
or
2. when is the time not to use the constant-references parameter ?

The reason for using const references is to avoid the cost of performing expensive copy operations which occur when passing a complex type by value. Also, some classes outright prevent copying so you couldn't pass objects of those classes by value even if you wanted to. So, always use by-value for built-in types (ints, doubles, pointers, ...), and use const references for arguments with a class type. It's fine to pass simple, copyable classes by value also.

yes, i also read about that too, use the by-val parameter for built-in types data, use the const-ref for class type data or large list/collection.

and additionally, a consideration when there are needs to copy that function param into local(of function block) variable, some suggested to provide the function with by-value param type.

that give me perspective now, thank you stroppy.

I've posted my opinions on it in this thread ([size=2]I don't want to copy+paste the large-ish post).

I've posted my opinions on it in this thread ([size=2]I don't want to copy+paste the large-ish post).

That's about return values, not parameters, though.

Regarding your post on that other thread, you claim that the compiler will use move semantics in a situation where a caller passes a (local?) value as a function parameter and doesn't use that value afterwards. I see how the compiler has a chance to optimize in this situation, but does the standard actually guarantee the compiler will do so? I don't remember reading about such a thing before. It seems like a potentially very expensive and difficult thing for the compiler to detect reliably under all conditions.

[quote name='Stroppy Katamari' timestamp='1351758851' post='4996112']
[quote name='Servant of the Lord' timestamp='1351733904' post='4996031']
I've posted my opinions on it in this thread ([size=2]I don't want to copy+paste the large-ish post).

That's about return values, not parameters, though.

Regarding your post on that other thread, you claim that the compiler will use move semantics in a situation where a caller passes a (local?) value as a function parameter and doesn't use that value afterwards. I see how the compiler has a chance to optimize in this situation, but does the standard actually guarantee the compiler will do so? I don't remember reading about such a thing before. It seems like a potentially very expensive and difficult thing for the compiler to detect reliably under all conditions.
[/quote]
RVO and named RVO are both allowed by the standard. They are not REQUIRED by the standard, no optimizations of any kind are REQUIRED by the standard.
[/quote]Hold on. I wasn't talking about RVO. In Servant of the Lord's example above we have the line:
std::vector<std::string> notACopy = GetStuff(veryLargeVector); //No copy made - not in passing the variable in, and not in return the variable.
For the return value, the standard guarantees that no copy happens. Either RVO is performed *or* the vector is move constructed. The thing I do not fully understand is the claim that veryLargeVector will not be copied when it goes in as a value parameter. Sure, a compiler might notice it will never be used again and use that to optimize (in spite of its lvalue-ness), but do we have an actual guarantee like we do with the return value?

[quote name='Servant of the Lord' timestamp='1351733904' post='4996031']
I've posted my opinions on it in this thread ([size=2]I don't want to copy+paste the large-ish post).

That's about return values, not parameters, though.[/quote]
The thread is about return values primarily, but my post talks about both parameters and return values.

Regarding your post on that other thread, you claim that the compiler will use move semantics in a situation where a caller passes a (local?) value as a function parameter and doesn't use that value afterwards. I see how the compiler has a chance to optimize in this situation, but does the standard actually guarantee the compiler will do so?

I don't remember reading about such a thing before. It seems like a potentially very expensive and difficult thing for the compiler to detect reliably under all conditions.[/quote]
I was under the impression from the Going Native 2012 videos that it is very likely to use move semantics in that situation, but I was getting confused between lvalues and rvalues. If it was an rvalue, such as an unnamed temporary, it would use move semantics instead of copying (if a move constructor exists for that type). I don't know if it's guaranteed that it will, but I think it would be if the argument type had the proper move constructor.

std::vector<std::string> result = GetStuff(std::vector<std::string>(1000, "very large string containing alot of data");

In this case, since the vector as an argument is an unnamed temporary, my possibly flawed understanding is that it will be guaranteed to be moved instead of copied (if a move constructor exists). Further, my (again: possibly-flawed) understanding that GetStuff(), without RVO, would create a temporary, and then the temporary would be moved into 'result'.

However, you could use std::move() to tell the compiler to move the lvalue and get the same effect: std::move() would take the lvalue and return it as a rvalue, allowing GetStuff() to use a move-constructor for its parameter.

std::vector<std::string> veryLargeVector;
veryLargeVector.resize(2000, "very large string containing alot of data");
std::vector<std::string> result = GetStuff(std::move(veryLargeVector));

It seems all of this would depend on the class being passed around to actually implement move constructors though (which std::vector does).

Where I'm getting my impressions from:
[size=2]C++11: Rvalue references and move constructors (Wikipedia)
[size=2]A Brief Introduction to Rvalue References (2008)
[size=2]GoingNative 2012 - STL11: Magic && Secrets (2012 - Particularly 35 minutes into the video)

I haven't read the actual standard, despite having the PDF draft on my computer.

tl;dr: I was getting confused between lvalues and rvalues, but you can explicitly get the same result if you use std::move() and the type has a move constructor defined. Whether or not a compilers would automaticly detect it (which I recall hearing somewhere, but have no proof of, and it wouldn't be guaranteed), an explicit std::move() should guarantee it.

tl;dr: I was getting confused between lvalues and rvalues, but you can explicitly get the same result if you use std::move() and the type has a move constructor defined. Whether or not a compilers would automaticly detect it (which I recall hearing somewhere, but have no proof of, and it wouldn't be guaranteed), an explicit std::move() should guarantee it.

Thank you, that was an excellent response. (A++++, would reply again, ... )
The Lavavej video at exactly 36:53 confirms my earlier point. In your initial example when you passed in a lvalue, you would have gotten a useless copy, contrary to what you initially assumed. I also think you are correct in that applying std::move to the argument would work here, assuming the type has a move constructor. However, the smart default to use is still const ref, and a beginner should just go with that every time instead of trying to puzzle out when to use by-value and when to use move. Moving the argument also leaves the undefined object dangling in the caller and causes the risk of accidentally using it again. I think it's safe to say >90% of people coding C++ for a living do not understand move yet, and a lot of them never will.