stl::list vs custom made linked list (any differences)
Recently just pick up about what linked list are. I notice that STL had list. Could anyone help me with these questions?
Whats the different in them?
If there is not different which one is better? and which one is faster?
A simple example of stl::list for game? showing traversing through the list, adding and removing.
thanks alot! ;)
A custom implementation can be faster, but most people would recommend you stick with std::list because it's well tested, fast, and reliable. I share that opinion myself as well. Use std::list until you have proven it to be a problem with profiling(which is very unlikely to happen without misusing it).
list<Sprite*> sprite;void add(Sprite *s){ sprite.push_front(s);}void draw_list(list<Sprite*> &l){ list<Sprite*>::iterator itr=l.begin(); while(itr!=l.end()){ Sprite *s =*itr; s->draw(); ++itr; }}void draw(){ draw_list(sprite);}
Whats the different in them?
One is already written by professionals, bug-free, portable, usable and optimized. The other is currently unwritten, and won't be bug-free, portable, usable and optimized unless you spend even more time doing it (assuming you can, which isn't necessarily the case).
If there is not different which one is better?
std::list is usually smaller in terms of memory, increases productivity by having a clean interface and interacting correctly with SC++L algorithms, and besides, it's already written.
and which one is faster?
Quite possibly std::list, unless you spend weeks optimizing your own.
showing traversing through the list, adding and removing.
One is already written by professionals, bug-free, portable, usable and optimized. The other is currently unwritten, and won't be bug-free, portable, usable and optimized unless you spend even more time doing it (assuming you can, which isn't necessarily the case).
If there is not different which one is better?
std::list is usually smaller in terms of memory, increases productivity by having a clean interface and interacting correctly with SC++L algorithms, and besides, it's already written.
and which one is faster?
Quite possibly std::list, unless you spend weeks optimizing your own.
showing traversing through the list, adding and removing.
std::list<int> list;// Addinglist.push_back(5);list.push_back(3);// Removinglist.remove(5);// Traversing by handfor(std::list<int>::iterator i = list.begin(); i != list.end(); ++i) { std::cout << *i << " ";}// Traversing using the SC++Lstd::copy( list.begin(), list.end(), std::ostream_iterator<int>(std::cout," "));
Quote:Original post by _Sigma
In your example ^^, why are you doing ++i and not i++?
i++ returns the old value of i, which forces the compiler to create a copy of the object before doing the increment, and then returning the copy. This is pointless, unless you need the old value, which you don't.
So, ++i increments the original and returns the new value, which does not require a copy. Saving a copy on complex types, such as iterators, is a good idea.
Quote:Original post by _Sigma
In your example ^^, why are you doing ++i and not i++?
Postincrement involves the creation of a temporary to save the "current value" for ues in complex expressions.
In this case as the value returned from the increment operator is not being saved so using ++i is the same as using i++.
So basically its a small optimisation.
Quote:Original post by rip-off
In this case as the value returned from the increment operator is not being saved so using ++i is the same as using i++.
Not really. Since the user may define i++ and ++i to do different things, the compiler is not allowed to substitute one for the other. And so, the postincrement code for the iterator will be executed, which may have an unusual effect, such as temporary creation.
Also dont forget to check out std:vector! My fav for most uses personally... Also check if u singly or doubly.
Quote:Original post by ToohrVykQuote:Original post by rip-off
In this case as the value returned from the increment operator is not being saved so using ++i is the same as using i++.
Not really. Since the user may define i++ and ++i to do different things, the compiler is not allowed to substitute one for the other. And so, the postincrement code for the iterator will be executed, which may have an unusual effect, such as temporary creation.
Of course they can (the user making some custom class)[smile]
But im talking about us, client users of the SC++L. std::list::iterator::operator++ and std::list::iterator::operator++(int) are the same for our purposes (return values noted).
I'm not suggesting the compiler could allow such an optimisation, if the compiler could do such an operation then the whole point would be moot as no-one would care if you use ++i over i++ (again: unless the return value was important).
I don't know where you got that impression from my post [smile]
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement