Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
Somebody told me yesterday that the underlying structure of an ordered map is a binary search tree. This does not make sense to me since you cannot have O(1) retrieval if that were the case. Can anyone explain?
Also, if one were to implement a hash table in C++ without using the stdlib, what would be the best way to do so?
std::map lookup time is not O(1) its O(log(n)).
std::unordered_map has a lookup time of O(1) amortized.
std::unordered_map and std::unordered_set are hashtables.
The underlying data structure is implementation-defined. It is most commonly implemented as a Red-Black tree which is a self-balancing binary search tree. The time complexity for getting an element is O(logn) (see this)
I would just read the implementation of std::unordered_map as a starting point. I assume this is learning activity so reading and understanding working STL implementation would be a good exercise. If it's not an exercise then use std::unordered_map
std::map uses Red-Black tree as it gets a reasonable trade-off between the complexity of node insertion/deletion and searching.
Related
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 3 years ago.
Improve this question
std::set in C++ is not a real set in terms of data structures. std::unordered_set is a real set, but std::set is a binary search tree, more specifically a red-black tree. Why, then, is it called std::set? Is there some specific functionality that sets a std::set apart from a binary tree? Thanks.
Why isn't std::set just called std::binary_tree?
Because
Tree doesn't describe how the interface is used. Set does.
std::set does not provide sufficient operations to be used as a general purpose search tree. It only provides an interface to a particular application of a search tree: The representation of a set.
Technically the standard doesn't specify that std::set is a binary search tree; although red-black BST may be the only data structure that can achieve the requirements imposed on std::set, and the interface has carefully been specified with that data structure in mind, the choice of internal data structure is an implementation detail.
For same reason std::unordered_set isn't called std::hash_table.
std::unordered_set is a real set, but std::set is a binary search tree
std::unordered_set isn't any more or less "real" than std::set is. They are both sets with slightly different requirements and guarantees; One designed to be implementable using a tree, and another designed to be implementable using a hash table.
P.S. Tree and a hash table are not the only ways to represent a set. One internal data structure that can implement most - but not all - of std::set is a sorted vector. Especially for small sets, a sorted vector can be much faster than std::set.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
So we know that the basic structures which form the backbone of C++ algorithms are:
trees set
queue
linkedlist
array
vector map
unordered_map and pair.
My question is which data structure is suitable for which application.For instance I know that for Database indexing and searching preferred choices are B+ tree and Hash table.Can anyone shed some more light on this,
This is not only a C++ problem, but also an algorithm question. It maybe too broad, but I can give you some advice.
set and map: They are ordered container, it is used for a both manytimes-insert-and-read structure. It can finish insert delete read in O(logn) time.
vector: used for something like dynamic array or a structure you will frequently push_back at it, and if no other reason, you should use it.
deque: much like vector, but it can also finish push_front in O(1) time
list: used for a structure you need to frequently insert, but less random access
unordered_map and unordered_set: look for hash table
array: used for a structure whose size is fixed.
pair and tuple: bind many object into one struct. Nothing special
Beside all of this, there are also some container meeting other requirement, you can serach them.
e.g. any and optional
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
Yesterday, this question came in my mind. Although I have neither read all the sorting algorithms like Quicksort, Merge Sort, Heapsort
Insertion Sort,
Selection Sort, and
Bubble Sort nor I have read the Introduction to Algorithms by CLRS but still, I am curious to know why there is a need to learn all such algorithms when the pre-defined sort function is already available to us in many languages.
Because
Simply sorting only may not be always the requirement. The requirement can be different. You may need to modify / integrate a sorting algorithm in order to develop a completely different thing.
The predefined sorting methods may not be the efficient at all cases.
Its always not about the sorted result but the approach of sorting in order to improve time and space complexity. Efficiency is the key.
There is no particular algorithm that is guaranteed to work best at all cases. Pros and cons may differ for different algorithms.
Need to understand which algorithm to be applied at what scenarios.
Sorting may not always done with numbers. It can be applied on other different complex types / structures. (There may not be pre-defined methods for complex cases )
There is always scope for a better approach.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
(Okay, so my previous question is on hold as being too broad, so I'm narrowing it down here.)
I'm looking to take part in algorithmic programming contests, and a lot of problems hinge on the use of specialized data structures which are extremely good at a certain operation - for example, Fenwick trees allow calculation of prefix sums of a list of values in logarithmic time.
What is the preferred way of implementing such data structures in modern C++ (i.e. using C++11 features)? Is it possible to use STL algorithms and containers instead of writing structs and coding every operation by hand?
I'm looking for Fenwick trees, segment trees, treaps and some other data structures often useful in IOI-style contests, but general strategies are more than enough.
there's an implementation of a fenwick tree here: http://www.algorithmist.com/index.php/Fenwick_tree
It uses std::vector as the underlying container.
arguably the method increase could be written in terms of std::transform or std::foreach.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
What's the complexity of iterator++ operation for stl RB-Tree(set or map)?
I always thought they would use indices thus the answer should be O(1), but recently I read the vc10 implementation and shockly found that they did not.
To find the next element in an ordered RB-Tree, it would take time to search the smallest element in the right subtree, or if the node is a left child and has no right child, the smallest element in the right sibling. This introduce a recursive process and I believe the ++ operator takes O(lgn) time.
Am I right? And is this the case for all stl implementations or just visual C++?
Is it really difficult to maintain indices for an RB-Tree? As long as I see, by holding two extra pointers in the node structure we can maintain a doubly linked list as long as the RB-Tree. Why don't they do that?
The amortized complexity when incrementing the iterator over the whole container is O(1) per increment, which is all that's required by the standard. You're right that a single increment is only O(log n), since the depth of the tree has that complexity class.
It seems likely to me that other RB-tree implementations of map will be similar. As you've said, the worst-case complexity for operator++ could be improved, but the cost isn't trivial.
It quite possible that the total time to iterate the whole container would be improved by the linked list, but it's not certain since bigger node structures tend to result in more cache misses.