Sign in to follow this  

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.

If you intended to correct an error in the post then please contact us.

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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
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();
OR
Ball& thisBall = listOfBalls[0];

Share this post


Link to post
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 this post


Link to post
Share on other sites
Quote:
Original post by stupid_programmer
Thanks 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 this post


Link to post
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 this post


Link to post
Share on other sites
Quote:
Original post by Anon Mike
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.


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 this post


Link to post
Share on other sites
Quote:
Original post by dmatter
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.

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 this post


Link to post
Share on other sites
Quote:
Original post by frob
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.


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 this post


Link to post
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.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this