Search code examples
c++optimizationcopycopy-constructorrvo

C++ returning an object copy


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 no mutable nonsense happening behind it) and it would not make any copies of the objects and perform these const operations on the private member of the MyObjectHolder 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... ?


Solution

  • 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.