I have a set of items, which i push back at the end of the container and pop back. For this purpose,
I'm not using std::stack because std::stack is already using std::deque inside. So I'm using std::vector<> and instead of push_back, I'm using emplace_back as i have multiple arguments.
I would like to know is it worth switching to std::deque to improve performance?
Whether it will improve performance or not will depend greatly on your usage pattern: how much you push, how often you pop, how expensive is element copying (or moving) during vector reallocation and so on and so forth. There's no way to say anything definitive without looking at the specifics. Try it, profile it and see which one works better.
BTW, you can specify which container type std::stack will use under the hood. And you also have std::list to try.
Related
I could always use an array and write an algorithm for pushing items to the top but a stack would probably be more efficient and simpler to use later. I've searched for this function and couldn't find one.
Use a std::deque, which provides both std::deque::push_back and std::deque::push_front methods for pushing elements to the "top" and "bottom" of the data structure, respectively, in constant time.
std::stack is a container adapter, not a container itself. That means it simply enforces a stack interface (which by definition only offers push and pop to the top of the stack) over the top of a user specified underlying container that provides push_back(), pop_back() and back() functions. By default std::stack uses std::deque as its underlying container but std::vector and std::list are standard containers that also meet the requirements (and std::vector is probably a better choice in most cases).
If you want to be able to push to the other end of the stack then just directly use a container that supports that efficiently - std::deque is likely your best choice.
std::stack is a FILO data container, full stop. You can add to the back and then you can remove from the back. If you need to do anything else, then you need to use a container that isn't std::stack.
You seem to be using wrong container for what you want to achieve. deque seems to be a better fit.
I am using std::stack for an project and I need to travel on it for checking same values. I checked member functions but, I could not find an appropriate one for this task.
The first idea that came up is using a copy stack but, the program might waste lots of extra space in this case, and not using an user-defined stack class is important at this level of the project (Yeah, I made a design mistake... ).
So, any idea?
Thank you!
Avoid std::stack, it's just a useless wrapper that dumbs down the interface of the underlying container. Use a std::vector with push_back/pop_back for insert insertion/removal (insertion/removal at the end is amortized O(1)) or std::deque, whence you can push/pop on either side without significant changes in performances (still amortized O(1)). In both cases you can walk all the elements using their random-access iterators.
(the same holds for std::queue: it's useless, use directly std::deque (not vector) with push_back/pop_front)
I am implementing a variant of toposort, which needs a structure to hold elements with no incoming edges. Both queue and stack seem fine for this purpose, as the order in which they are taken out does not matter. The question is: is any of them significantly faster than the other?
queue and stack are both container adaptors, not complete containers in their own right.
Both stack and queue are implemented on top of a std::deque by default, they should have similar performance if you did not change this setup.
It really depends on what kind of application you are coding and you may select the underlying container which benefits those operations you want the most.
Answer to your main question: I don't know. I don't think any of them is significantly faster, because for std::deque (the default internal container for both stack and queue) the push_back and push_front (and pop_back and pop_front) are symmetric. None should be faster. I would however suggest using plain old std::vector with push_back and pop_back, or equivalently
std::stack<T, std::vector<T>>
See here for the reasons why stack uses deque by default.
they both have constant complexity ... you'll just need to time it to determine whether any of the constants is higher
http://www.cplusplus.com/reference/stack/stack/pop/
http://www.cplusplus.com/reference/queue/queue/pop/
While queue and stack aren't wildly different in performance, they obviously induce a different node-visiting order. One of them may give a more cache-friendly order than the other, depending on how your nodes are laid out in memory.
queue and stack are different.
First is FIFO and stack is FILO
I am doing a game where I create objects and kill them frequently. I must be able to loop the list of objects linearly, in a way that the next object is always newer than previous, so the rendering of the objects will be correct (they will overlap). I also need to be able to store the pointers of each object into a quadtree, to quickly find nearby objects.
My first thought was to use std::list, but I have never done anything like this before, so I am looking for experts thoughts about this.
What container should I use?
Edit: I am not just deleting from the front: the objects can be killed at any order, but they are always added in the end of the list, so last item is newest.
std::vector is the recommended container to start with when you're not sure what you're doing. Only when you know that's not going to work for you should you choose something else.
That said, if you're regularly adding to the back of the container and deleting from the front, you probably want std::deque. [Edit] But it appears that's not what you're doing.
I'm thinking you might want two containers, one to maintain the insert order and one for your quadtree. There are lots of quadtree implementations on the Internet, so I'll focus on the other one. Using std::list as you suggest will make the delete operation itself faster than vector or deque. It also has the advantage of letting you store iterators, because list won't invalidate the other iterators when an element is removed. Your objects in the quadtree could maintain an iterator into the insert order list. When you remove an element from the quadtree, you can remove it from the list too in O(1) time.
As always, the decision about which container to use is all about tradeoffs. A list comes with increased memory footprint over vector and the loss of contiguous memory layout. You might be surprised how much cache locality matters when your data set is large. The only way to know for sure is to try various containers and see which one runs the best for your application.
I think boost::stable_vector fits your needs for deletion\iteration.
So, you want to be able to iterate through through your container in the order in which the items have been added, but you want to be able to remove items from any point in the container. A simple queue obviously isn't going to hack it.
Happily, there are 4 containers that will do this job easily enough, std::vector, std::list and std::deque and std::set. If you use standard container idioms (eg. begin, end, erase, insert, and to a lesser extent, push_front, pop_back, front, back) you can use whichever container you felt like. With those 8 operations, you could switch between std::vector, std::list and std::deque, and with just the first 4 you could use std::set, too. Write your code, and then you can easily chop and change between the different container types and do a little profiling to compare performance and memory overheads or whatever.
Intuitively, std::list is probably a good bet, and perhaps std::set would work too. But rather than making assumptions, just use the general tools the template library gives you, and profile and optimise things later when you have some meaningful performance data to work with.
What would have better performance, a stl vector, or a dynamic array that's just realloc'd everytime I want to add something to it?
Would using vectors::iterator be faster then using a for loop on an array?
And if someone could explain why, that would be great.
Premature optimization is evil. The standard C++ way of doing things is to use the standard library containers as much as possible. If you want to use the best containers fitting your needs: here is the diagram
source: Original Image by Jameson Williams
One day you will maybe need to heavily optimize and use a dynamic array, but it should be rare.... one day you will also need collection that are multi-thread safe... and so on... but in general std containers are the way to go.
What would have better performance, a stl vector, or a dynamic array that's just realloc'd everytime I want to add something to it?
Stl vectors have insertion in amortized constant time (because reallocation is not done all the time and reservations occur by factor 1.5 (minimum)).
Therefore according to your description, vectors will be massively faster than reallocating all the time
Would using vectors::iterator be faster then using a for loop on an array?
In the general case: exactly identical.
However certain STL implementations generate checks in debug mode that can considerably slow down the use of container iterators.
(note most implementations implement vector/string iterators as a typedef to value_type*)
And if someone could explain why, that would be great.
What would have better performance, a stl vector, or a dynamic array that's just realloc'd everytime I want to add something to it?
stl vector should be the winner in this case, because it doesn't realloc every time[vector guarantees O(1) amortized insert time]. However, it might be similar if your malloc implementation is optimized for this kind of usage.
Would using vectors::iterator be faster then using a for loop on an array?
These should be the same, particularly because vector::iterator are usually just pointers into an array or thin wrappers thereof.
There is no difference in speed, but vector is massively safer. This is because the functions will just be inlined by your compiler, but vector carries a large number of exception and bounds-checking (if you ask for it) gurarantees that you won't see when using your own raw arrays.