C++ pointers and references in functions

Question

I am coming from a C#/Java background into C++, using visual studio community 2017 & plenty of tutorials. I came to the point where am unsure of what is a correct way to write a function to process a vector of data. Should I force a function to use a pointer / reference? Should I let compiler sort it out? What is best practice?

This is my main, I ask for an input on vector size, then pass a pointer to the integer value to function that creates and populates vector with values through a simple for loop. I then pass the array to another function that performs a shuffle.

vector<int> intVector(int* count)
{
    vector<int> vi;
    for (int i = 1; i <= *count; i++)
        vi.push_back(i);
    return vi;
}

vector<int> &randVector(vector<int> *v)
{
    shuffle(v->begin(), v->end(), default_random_engine());
    return *v;
}

int _tmain(int argc, _TCHAR* argv[])
{
    int count;
    cout << "Enter vector array size: ";
    cin >> count; cout << endl;
    cout << "Vector of integers: " << endl;
    vector<int> vi = intVector(&count);

    for_each(vi.begin(), vi.end(), [](int i) {cout << i << " ";});
    cout << endl;
    vi = randVector(&vi);
    cout << "Randomized vector of integers: " << endl;
    for_each(vi.begin(), vi.end(), [](int i) {cout << i << " ";});
    cout << endl;

    return 0;
}

So my question is, what is the best practice in my case to avoid unnecessary copying. Should I even care about it? Should I rely on compiler to solve it for me?

I am planing to use C++ for game development on desktop and consoles. Understanding memory and performance management is important for me.

Answer 1

You are in charge of enforcing (or avoiding) the copy of objects around.

Regarding your example:

• You can avoid using pointers and use a reference instead.

Like in the following:

vector<int>& randVector(vector<int>& v)
{
    shuffle(v->begin(), v->end(), default_random_engine());
    return v;
}

Note that since you are using a reference, the shuffle operation is already modifying the parameter of randVector so there is no real need to return a reference to it.

As a rule of thumb when you need to pass an object around and you want to avoid a potentially expensive copy you can use references:

void function(<const> Object& v)
{
//   do_something_with_v
}

Answer 2

The rules on passing in C++ for typical code are pretty straightforward (though obviously still more complex than languages without references/pointers).

• In general, prefer references to pointers, unless passing in null is actually something you might do
• Prefer to write functions that don't mutate their inputs, and return an output by value
• Inputs should be passed by const reference, unless it is a primitive type like an integer, which should be passed by value
• If you need to mutate data in place, pass it by non-const reference

See https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#Rf-conventional for more details.

The upshot of this is that here are the "correct" signatures for your two functions:

vector<int> intVector(int count);

void randVector(vector<int> &v);

This doesn't take into account iterators which is probably really the correct "generic" way to write the second function but that is a bit more advanced. But, see std::shuffle which lets you randomize any arbitrary container by leveraging iterators: http://en.cppreference.com/w/cpp/algorithm/random_shuffle.

Since you mentioned unnecessary copying, I will mention that when you return things like vector by value, they should never be copied (I'm assuming you're using C++11 or newer). They will instead be "moved", which doesn't have significant overhead. Thus, in newer C++ code, "out parameters" (passing in arguments by reference to mutate them) is significantly discouraged compared to older versions. Good to know in case you encounter dated advice. However, passing in by reference for something like shuffling or sorting is considered an "in/out" parameter: you want to mutate it in place and the existing data is important, not simply being overwritten.