std::vector use [0] or front()
Author
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]?
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.
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.
Author
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.
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];
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());}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.
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.
I'd be surprised if there was any significant difference in perf between the two.
Author
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().
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
