deque

Why aren't ArrayList s generally implemented to be double-ended, which would support fast amortized insertion in the front as well as the back? Is there ever a disadvantage to using the latter over the former? (I'm not talking just about Java -- I haven't seen double-ended array lists being the default in any other language, but Java was just a good example here.) *Edit: I originally called them "array deques" but that was a misunderstanding on my part; I wasn't talking about queues, but double-ended array lists. An ArrayList is simple; entries start at 0, and you can add stuff at the end

I've read that accessing elements by position index can be done in constant time in a STL deque. As far as I know, elements in a deque may be stored in several non-contiguous locations, eliminating safe access through pointer arithmetic. For example: abc->defghi->jkl->mnop The elements of the deque above consists of a single character. The set of characters in one group indicate it is allocated in contiguous memory (e.g. abc is in a single block of memory, defhi is located in another block of memory, etc.). Can anyone explain how accessing by position index can be done in constant time,

I'm porting code that uses a very large array of floats, which may trigger malloc failures from c to c++. I asked a question about whether I should use vectors or deques and Niki Yoshiuchi generously offered me this example of a safely wrapped type: template<typename T> class VectorDeque { private: enum TYPE { NONE, DEQUE, VECTOR }; std::deque<T> m_d; std::vector<T> m_v; TYPE m_type; ... public: void resize(size_t n) { switch(m_type) { case NONE: try { m_v.resize(n); m_type = VECTOR; } catch(std::bad_alloc &ba) { m_d.resize(n); m_type = DEQUE; } break; } } }; I needed a 2D vector of vectors

Please correct me if I am wrong. Thank you! insert and erase will relocate elements, but elements before the position where insertion/erasure takes place don't relocate and hence their iterators remain valid. push_back and pop_back don't invalidate any iterators. push_front and pop_front invalidate all iterators. swap won't relocate elements, but somehow I think it should invalidate iterators. push_back() and push_front() are defined in terms of insert() . Similarly, pop_back() and pop_front() are defined in terms of erase() . Here's what the C++03 standard says about iterator invalidation for

In python docs I can see that deque is a special collection highly optimized for poping/adding items from left or right sides. E.g. documentation says: Deques are a generalization of stacks and queues (the name is pronounced “deck” and is short for “double-ended queue”). Deques support thread-safe, memory efficient appends and pops from either side of the deque with approximately the same O(1) performance in either direction. Though list objects support similar operations, they are optimized for fast fixed-length operations and incur O(n) memory movement costs for pop(0) and insert(0, v)

I've been thinking for a while about how to go about implementing a deque (that is, a double-ended queue) as an immutable data structure. There seem to be different ways of doing this. AFAIK, immutable data structures are generally hierarchical , so that major parts of it can be reused after modifying operations such as the insertion or removal of an item. Eric Lippert has two articles on his blog about this topic, along with sample implementations in C#. Both of his implementations strike me as more elaborate than is actually necessary. Couldn't deques simply be implemented as binary trees,

What is the difference between the two? I mean the methods are all the same. So, for a user, they work identically. Is that correct?? From the (dated but still very useful) SGI STL summary of deque : A deque is very much like a vector: like vector, it is a sequence that supports random access to elements, constant time insertion and removal of elements at the end of the sequence, and linear time insertion and removal of elements in the middle. The main way in which deque differs from vector is that deque also supports constant time insertion and removal of elements at the beginning of the

Possible Duplicates: Is the C++ STL std::set thread-safe? Thread safety for STL queue I'm guessing it isn't, I just want to make sure. meaning 2 threads using the same std::deque using std::deque::push_back or push_front at the same time. Same question goes for std::priority_queue and the functions std::priority_queue::push and std::priority_queue::pop .. Are those containers thread-safe? Or I should personally program it to be thread-safe? Tnx a lot. From Scott Myer's Effective STL Item 12. Have realistic expectations about the thread safety of STL containers Multiple readers are safe.