I wrote the following code:
class MyObjectHolder {
public:
std::vector<int> getMyObject() const {
return myObject;
}
private:
std::vector<int> myObject;
};
At some point of my program I attempt to use the getMyObject
method and use only const
methods on the retrieved object:
const std::vector<int> myObject = myObjectHolder.getMyObject();
myObject.size();
int a = myObject.front();
Now, is it possible that the compiler will optimize this code so that no copies of the std::vector<int>
are done?
Is it somehow possible that the compiler determines that I'm only using the
const
methods on the retrieved object (and let's assume there is nomutable
nonsense happening behind it) and it would not make any copies of the objects and perform theseconst
operations on theprivate
member of theMyObjectHolder
instead?
If yes, would it be possible if I didn't explicitly declare the const std::vector<int> myObject
as const
?
If no, what are the reasons not to do this? In which cases this optimization would be to hard to implement / deduce that it's possible and correct here / etc... ?
Returning an object invokes the copy constructor while returning a reference doesn't. So, the version #2 does less work and is more efficient. The reference should be to an object that exists when the calling function is execution.
If a function returns a reference, and that reference is used to initialize or assign to a non-reference variable, the return value will be copied (as if it had been returned by value).
It would mean make a copy and return it. The difference is that if you return pointer to objects internal variable that object state could be modified from outside. If you return copy that copy can be modified and the original object will not change.
The copy constructor is invoked. It takes a reference to the local variable. It uses this reference to copy everything into the new object that will be used as the return value.
Now, is it possible that the compiler will optimize this code so that no copies of the
std::vector<int>
are done?
No, the compiler doesn't know what callers will do with that object unless you are making use of global optimization over all code that uses the object (the compiler can't generally make assumptions about its use; moreover if object is exported from a dll it can't make any assumption at all).
If yes, would it be possible if I didn't explicitly declare the const std::vector myObject as const?
No, anyway the conversion from non-const to const could be implicit.
If no, what are the reasons not to do this? In which cases this optimization would be to hard to implement / deduce that it's possible and correct here / etc... ?
It's an optmiziation that should be done inside getMyObject()
but the compiler can't be sure that callers won't cast away the const. Actually this is a very old debate about the use of const
, usually I think it's more clear to always think about const
as something for programmers and not for compilers.
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