Skip to main content
GameDev.net gamedev.net
🔒 Locked

Reference to a std::vector

Started by Mantear Sep 13, 2006 at 1:11 PM 11 replies 1.6k views
Original Post
Mantear
Mantear
Greetings, Using C++: is it a bad idea to try to pass a std::vector to a function as a pointer? Example:

void Foo(std::vector<int>* pMyVector)
{
   int num = 5;
   (*pMyVector).push_back(num);
}

// From main...
std::vector<int> MyVector;

Foo(&MyVector);

If this is a Bad Idea(tm), how should I pass a std::vector around? Thanks!
Zakwayda
Zakwayda
The only reason I can think of why you'd want to use a pointer is if the vector were an optional parameter. Otherwise though, you should use a reference or constant reference. It's largely the same under the hood, but using a reference makes your intent more clear and eliminates a possible source of error.
Palidine
Palidine
It's infinitely better to pass it as a reference or as a pointer than as a copy. Deep copying vectors across function boundaries is one of the worst things you can do with them.

If you don't want the function to modify the vector it should be a const reference or pointer. generall references are nicer to deal with than pointers because you don't have to NULL check them before using.

-me
Mantear
Mantear
I guess my question was more a matter of whether or not it was legal/safe to do. If the push_back() causes the vector to grow, or if I shrink the vector down and it needs to re-size, will it be safe?

I come from an embedded C background, so I prefer to pass things as pointers instead of references. It helps me keep track of what's happening during a function call, although I know passing by reference would be the more proper way.

Not sure why I wrote "(*pMyVector)." instead of "pMyVector->" ...
rip-off
rip-off
Quote:
Original post by Mantear
I guess my question was more a matter of whether or not it was legal/safe to do. If the push_back() causes the vector to grow, or if I shrink the vector down and it needs to re-size, will it be safe?

I come from an embedded C background, so I prefer to pass things as pointers instead of references. It helps me keep track of what's happening during a function call, although I know passing by reference would be the more proper way.

Not sure why I wrote "(*pMyVector)." instead of "pMyVector->" ...


It is safe.

You could look into references though, they are very easy and not as prone to some of the problems of pointers ( accidental pointer arithmetic, NULL/invalid pointers ).
Conner McCloud
Conner McCloud
Quote:
Original post by Mantear
I come from an embedded C background, so I prefer to pass things as pointers instead of references.

Then go back to C. Why use C++ at all if you're just going to program in C anyhow? Pointers should only be used when a reference can't.

CM
CTar
CTar
Quote:
Original post by Mantear
I guess my question was more a matter of whether or not it was legal/safe to do.


Your code isn't safe at all, pMyVector could be 0 or an invalid pointer, which both would result in undefined behavior. Also listen to Conner McCloud, you shouldn't code C when your language is C++.
Mantear
Mantear
@ CTar, Conner McCloud: As I said before, I know that passing by reference is the better method. rip-off and Palidine made similar comments without having to bash my C-style method. I'm aware that pointers need to be verified before being used; it seems silly to perform such checks in example code when that's not even the point of my question. I "go back to C" all the time, as I have to use both (different projects/programs, etc).

Now I remember why I wrote "(*pMyVector).", because elsewhere in my code I wanted to index the vector, "(*pMyVector)", and I like to keep my notation consistent. I know, I know, passing by reference would have made it all a moot point...
Zahlman
Zahlman
As you yourself have discovered, references try to simplify the syntax you use to specify the same thing, therefore incurring no performance penalty. They could theoretically improve optimizations, even, because they give more information to the compiler; and they give more information to the *reader* of the code, too, because they are more specific about intent. When you pass by reference, you don't have to *say* "Precondition: input is not NULL" (or add an assert); it's required by the fact that the calling code must have *already* messed up (invoked undefined behaviour) in order to create anything looking like a null reference (because that process invokes undefined behaviour, real "null references" do not exist).

Considering all that, why *wouldn't* you want to use them as much as possible?
taby
taby
Quote:
Original post by Mantear
@ CTar, Conner McCloud: As I said before, I know that passing by reference is the better method. rip-off and Palidine made similar comments without having to bash my C-style method. I'm aware that pointers need to be verified before being used; it seems silly to perform such checks in example code when that's not even the point of my question. I "go back to C" all the time, as I have to use both (different projects/programs, etc).

Now I remember why I wrote "(*pMyVector).", because elsewhere in my code I wanted to index the vector, "(*pMyVector)", and I like to keep my notation consistent. I know, I know, passing by reference would have made it all a moot point...



At the very least you can make the pointer const so that you can't change its value inside of the function (const value, not const object being pointed to).
MaulingMonkey
MaulingMonkey
Quote:
Original post by Mantear
Now I remember why I wrote "(*pMyVector).", because elsewhere in my code I wanted to index the vector, "(*pMyVector)", and I like to keep my notation consistent with C.


Fixed. It's not consistent with what other C++ programers will be writing, nor with the number of indirections used throughout the procedure.

Quote:
I'm aware that pointers need to be verified before being used; it seems silly to perform such checks in example code when that's not even the point of my question.


Hardly - again, it's inconsistent (only this time the kind that can lead to bugs if you froget them in production code). I typically just assert() for example code.
Conner McCloud
Conner McCloud
Quote:
Original post by taby
At the very least you can make the pointer const so that you can't change its value inside of the function (const value, not const object being pointed to).

In this case, it isn't a const value, so that isn't an option. Although in general you would be "correct" insofar as anybody can be correct when suggesting pointer use in this situation is acceptable.

CM

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.