SFML community forums
Help => Graphics => Topic started by: Wander on September 11, 2010, 07:21:18 pm
-
I'm working on a map program. I have it working where it displays coordinate on the map, but I can't figure out how to get it to display multiple coordinates without creating a new sf::Shape for each coordinate.
-
Just draw the same shape several times each frame...
Draw(shape)
shape.SetPosition()
Draw(shape)
shape.SetPosition()
Draw(shape)
Display()
-
That would require me to manually account for how many points I have.
I forgot to mention what I actually want to do. Let me clear it up:
I want the user to enter a coordinate. The map will mark that coordinate and go about it's business. Then say 5 minutes later, the user wants to mark another coordinate. They enter it and the program displays both coordinates. Then say a few minutes later they have another coordinate to enter. It would have to display all three.
Since I want the user to input over 200 coordinates, your method would be impractical and I don't know which coordinates they would want to access.
:)
-
Why don't you want to have one sf::Shape for each coordinate?
-
Then I would have to manually have to program in 200 sf::Shapes.... Wouldn't I?
-
I think you need some minimal programming skills before going any further!
-
I do.... I want to use for loops, but I can't think of any way to manage making the elements, display them, and print them in a text file.
-
@Wander: I'm guessing you are using C++, look up std::vector (http://www.cplusplus.com/reference/stl/vector/). Otherwise look for lists in whatever language you use.
-
I was going to recommend std::list instead of std::vector, but yeah.
-
I was going to recommend std::list instead of std::vector
Why?
-
I was going to recommend std::list instead of std::vector, but yeah.
I would still recommend std::vector since this task does not seem to be in need of inserting stuff in the midle of the array (which is what std::list is good at).
-
I'd recommend list because:
- the input is user driven. The user is adding points at will. Where there's user addition there's often user removal. Removing elements from a vector is painful. Removing them from a list is harmless.
- the input can grow to infinity (again partially due to it being user driven). And sparatic growths in a vector trigger reallocation. Although granted this can be minimized with clever calls to reserve().
- random access doesn't seem to be necessary. And since random access is pretty much the only advantageous reason to use vector over, say, list or deque, there's not much point to using vector.
My question would be why did you recommend vector?
I get the impression vector is just the default "go to" container for a lot of people when it probably shouldn't be.
-
the input can grow to infinity (again partially due to it being user driven). And sparatic growths in a vector trigger reallocation. Although granted this can be minimized with clever calls to reserve().
In a list, every single insertion triggers allocation. vector does not need to allocate memory each time the user has requested to insert an element (in fact, reallocations are not as frequent as one could think). vector wins.
And since random access is pretty much the only advantageous reason to use vector over, say, list or deque, there's not much point to using vector.
It's not the only vector's advantage over other containers.
My question would be why did you recommend vector?
Perhaps because of one thing constantly overlooked by people who "care" about performance, but never measure it - vectors (arrays in general) have the best possible cache locality. Lists (unless unrolled) don't have any. Sometimes this can have tremendous impact on performance, so it could be - and sometimes actually is - faster to use vector rather than list, even though the computational complexity will be worse.
-
Removing elements from a vector is painful.
It is not. This is only known by few people, but ignoring the element order, you can remove elements of a std::vector in O(1). And this is much faster than at std::list, because no dynamic deallocation comes to play.
I get the impression vector is just the default "go to" container for a lot of people when it probably shouldn't be.
In the most cases, std::vector is the best choice. You should generally stick to it, and if you've got special requirements or measured performance problems, look for another container.
I think Silvah pointed the other advantages out quite well.
-
interesting indeed!
Thanks for the response.
-
EDIT : don't read my crappy post!
Removing elements from a vector is painful.
It is not. This is only known by few people, but ignoring the element order, you can remove elements of a std::vector in O(1). And this is much faster than at std::list, because no dynamic deallocation comes to play.
You're wrong. (isn't it the first one I read? héhé <- French laughing)
From dinkumware :
Erasing N elements causes N destructor calls and an assignment for each of the elements between the insertion point and the end of the sequence. No reallocation occurs, so iterators and references become invalid only from the first element erased through the end of the sequence.
So erasing an/some element(s) is O(n), where n is the number of element «behind» the erased one(s).
Well, if you're using pointers you can take it as O(1) (negligible). Lists are more powerful otherwise FOR INSERTION/ERASING, not for iterating.
NB : run some performance tests to see if you really need list instead of vector. If you're doing only a few insertion-erasing per second it won't matter to use vector.
-
So erasing an/some element(s) is O(n), where n is the number of element «behind» the erased one(s).
"ignoring the element order" means that in this case, you can swap the element to remove and the last one, and then erase the last one. This is O(1) ;)
-
So erasing an/some element(s) is O(n), where n is the number of element «behind» the erased one(s).
"ignoring the element order" means that in this case, you can swap the element to remove and the last one, and then erase the last one. This is O(1) ;)
oupsi :roll:
-
In my own applications, the reason to choose std::list over other containers was mostly the fact that pointers, references and iterators to elements remain valid unless the element itself is removed. The same also applies to the four associative containers of the standard library.
@ Laurent: Thank you for reading my mind :D