# std::vector use [0] or front()

This topic is 3369 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

My game has the possibility of having multiple balls in play so I'm using a std::vector to keep track of them. Most of the time there is only the one ball though. In various parts of the game I have to do stuff to the ball object and hence access it through the vector. Is it better to use the front() member of the vector or the old array index style of [0]?

##### Share on other sites
I guess it depends on what you are doing. Are you iterating over the array. Or do you need to access only the first element?

You mentioned that you will have multiple balls at some point, so it seems likely that you will be iterating over the vector to update the balls.

For iterating, I would use iterators, but using the subscript operator would work just as well.

Really, there isn't much overhead in any method for accessing an element of a vector, so it really just comes down to preference.

##### Share on other sites
When checking if the ball(s) are out of bounds I use a iterator. But there are lots of specific points where there is only one ball in play so I'm certain the vector only contains the one ball. I kind of thought it was pretty much a style choice between the two but thought I would ask.

##### Share on other sites
You can also get a reference to the ball. That way the way in which you access the element matters even less.

Ball& thisBall = listOfBalls.front();ORBall& thisBall = listOfBalls[0];

##### Share on other sites
Ultimately a matter of style. I wouldn't give it much thought beyond this:

void frobnicate_ball(Ball&);void frobnicator(std::vector<Ball> &balls){  // This function assumes that there is only one ball.  // So add this assertion just in case the vector contains  // more than one ball when this function is called.  assert (balls.size() == 1);    // Forward the call on the appropriate object.  frobnicate_ball(balls.front());}

##### Share on other sites
Thanks to both of you. One of the many things not talked about in school.

##### Share on other sites
Quote:
 Original post by stupid_programmerThanks to both of you. One of the many things not talked about in school.

Schools are not be-all-end-all.

You know the problem you're trying to solve.
You have the source to std::vector.
You have the compiler.
You can rebuild it, stronger.... um...

All except the last are at your disposal.

If performance matters, use some timing routine and compare.
If space matters, you can use debugger to step through assembly and see how the variables are allocated.
If anything else is the problem, formulate it, then try to devise a solution.
If you still cannot find an answer, post on forum, detailing what you did, the results you got, the concerns you have, and more.

And at some point, google may help as well.

##### Share on other sites
Most collections support front(), few of them support operator[]. The advantage of using front() would be that if you ever decide to change collections (say, maybe a queue or something) then you'll have less code to change. Being able to write code that is less dependent on the type of the underlying collection is one of the reasons for having front() in the first place.

I'd be surprised if there was any significant difference in perf between the two.

##### Share on other sites
Correct handling of ones balls is a delicate topic. :)

##### Share on other sites
Quote:
 Original post by Anon MikeMost collections support front(), few of them support operator[]. The advantage of using front() would be that if you ever decide to change collections (say, maybe a queue or something) then you'll have less code to change. Being able to write code that is less dependent on the type of the underlying collection is one of the reasons for having front() in the first place.I'd be surprised if there was any significant difference in perf between the two.

Thats a good point, and one I didn't think of. I was just going to stick with [0] but am going to switch to front().

##### Share on other sites
I like front(), it's more explicit and that's a good thing, and so it the commonality of it in other containers too. Also, in a debug build, operator[]() might perform bound checking with any associated performance penalty.

##### Share on other sites
Quote:
 Original post by dmatterI like front(), it's more explicit and that's a good thing, and so it the commonality of it in other containers too. Also, in a debug build, operator[]() might perform bound checking with any associated performance penalty.

It might do bounds checking in release builds, too. It is on by default in Visual C++. :)

The standard only says that at() is required to do the boundary check. It doesn't say that operator[] is required to not perform the check.

##### Share on other sites
Quote:
 Original post by frobThe standard only says that at() is required to do the boundary check. It doesn't say that operator[] is required to not perform the check.

That said, I among others consider MSVC's vector::operator[] release mode checks that are on by default to be completely counter to C++'s philosophy of "You don't pay for what you don't use".

I tend to just use v[0], but I do use v.back(). The main case where I'd use .front() would be when I'm doing something special with that side and trying to contrast it against more general case code using v[N].

##### Share on other sites

This topic is 3369 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Create an account

Register a new account

• ### Forum Statistics

• Total Topics
628658
• Total Posts
2984078

• 10
• 9
• 9
• 10
• 21