Use of Boost Bimap in C++ - c++

C++ Boost has Bimap container that is a bidirectional map:
http://www.boost.org/doc/libs/1_43_0/libs/bimap/doc/html/index.html
Does anyone know the performance of Boost::bimap? I mean what's the time complexity of accessing an element in the map? Is it as quick as unordered_map access (which is O(1))?
Thanks!

AFAIK each different container of this library have different operation complexity relative to the implementation (like for the stl containers). For details necessary to make your choice, read : http://www.boost.org/doc/libs/1_43_0/libs/bimap/doc/html/boost_bimap/the_tutorial/controlling_collection_types.html

Related

Two questions concerning C++ Containers

Why are the Container Adapters like std::stack or std::queue implemented as adapters and not as independent containers? Is it because you want e.g. a stack with an underlying memory managment of different Sequence Containers?
Why are the algorithms of the STL implemented as free functions, which expect iterators, and not as methods of the corresponding containers?
This is done to give programmers better control over the implementation. An ability to mix-and-match is incredibly powerful, because it lets you achieve more things with less code.
Why are the Container Adapters like std::stack or std::queue implemented as adapters
Because you can mix-and-match containers and adapters: depending on your needs, you can create a queue based on a vector, or a stack based on a list, and then change the implementation details by swapping in a container of different type.
Why are the algorithms of the STL implemented as free functions
To avoid coding them in multiple places. For example, a linear search in a vector remains the same linear search in a list, and can also be applied to other containers that have iterators.
Note that some containers do have member-functions specific to their implementation. For example, std::set has find method for faster non-linear search.

What is time complexity involved for finding an element in Various STLs

Can anyone help me with the time complexity involved in finding a value in various STL Containers
Vectors
deque
list
string
set
multiset
map
multimap
stack
queue
priority queue.
I think, the search/find time should be based on how these STL containers are implemented internally. So it would help if information about same can be provided as well. It might vary from implementation to implementation, so answers based on commonly used data structures behind these STL containers would also help.
Thanks in advance..

what are the differences between these in C++?

I am a big java fan but i have to work now on C++ for a project. I intended to you a java hashmap kind of feature in c++. After googling i found there exists no hashmap/hashtable in C++ STL library. But i found these data types: map, unordered_map, unorderd_set and hash_map. hash_map is microsoft's specific dll/library and remaining are used under STL. i have to work on IBM XL C/C++ compiler. So i can't use microsoft/boost as my company don't recommend them. All i have to use STL specific. Please, provide some info on these collections. What would be best among these STL specifics if i have to choose hashmap functionality? Thanks in advance.
unordered_map is equivalent to java's HashMap, and is a hash map - so it is probably what you are after.
map is equivalent to a TreeMap in java. It is implemented as a red-black tree.
unordered_set is equivalent to java's HashSet. It contains only keys, and not pairs of (key,value)
Did you read Wikipedia's page on associative containers in C++?
If you want real hash table (with a key providing an hash code, but no order between keys) you could use C++ 2011 std::unordered_map template. You'll need a compiler recent enough to be C++11 compatible in that regard.
If you can provide an order on keys, consider also using std::map which is available even in the older C++03 standard.

What other data structures are available in the C++ STL?

I'm already aware of the following:
arrays
bitsets
hash maps and sets
regular maps and sets
iterators
lists
pairs
tuples
queues, deques, and priority queues
stacks
valarrays
vectors
Is there any other type of data structure available in the C++ library. What I'm specifically looking for is graphs, but I'd also like to know what else is there.
Also, I'd like to know if there are any external libraries I can link with my projects to implement a graph.
It's "the C++ standard library" or something to that effect, not "the STL". That term refers to an initial draft of some specific data structures and algorithms. Not all of them made it into the standard library, and the standard library also contains other stuff (for example, all the iostream classes).
That looks like a complete list to me (you appear to be talking specifically about C++0x, since you mention tuples and arrays). I don't know if I would even consider bitsets and iterators to be "data structures", but I guess that's a fair description.
There is definitely not a graph implementation. Unfortunately. :( You can get one from Boost, though.
The STL is divided into three parts:
Containers
Iterators
Algorithms
You have obviously found the containers part and you have probably used the iterators associated with the containers. But there is even more to the iterators than you have found.
The algorithms sections is linked to the containers via iterators. But also contains the parts handle functors and associated binders.
My favortie site for this is: http://www.sgi.com/tech/stl/table_of_contents.html
In addition to the standard libraries you should have a look at the boost libraries:
see also: Boost Library

Is there already some std::vector based set/map implementation?

For small sets or maps, it's usually much faster to just use a sorted vector, instead of the tree-based set/map - especially for something like 5-10 elements. LLVM has some classes in that spirit, but no real adapter that would provide a std::map like interface backed up with a std::vector.
Any (free) implementation of this out there?
Edit: Thanks for all the alternative ideas, but I'm really interested in a vector based set/map. I do have specific cases where I tend to create huge amounts of sets/maps which contain usually less than 10 elements, and I do really want to have less memory pressure. Think about for example neighbor edges for a vertex in a triangle mesh, you easily wind up with 100k sets of 3-4 elements each.
I just stumbled upon your question, hope its not too late.
I recommend a great (open source) library named Loki.
It has a vector based implementation of an associative container that is a drop-in replacement for std::map, called AssocVector.
It offers better performance for accessing elements (and worst performance for insertions/deletions).
The library was written by Andrei Alexandrescu author of Modern C++ Design.
It also contains some other really nifty stuff.
If you can't find anything suitable, I would just wrap a std::vector to do sort() on insert, and implement find() using lower_bound(). It should be straight forward, and just as efficient as a custom solution.
Old post, I know, but for more recent visitors, Boost's flat_set and flat_map look like what you need. See https://theboostcpplibraries.com/boost.container for more information.
I don't know any such implementation, but there are some functions that help working with sorted vectors already in STL, such as lower_bound and upper_bound.
If the set or map truly is small, the performance gained by micro-optimizing the data structure will have little to no noticeable effects. You'll save maybe one or two memory (read: cache) lookups when searching a tiny tree vs tiny vector, which in the big picture is insignificant.
Having said that, you could give hash_map a try. Lookups by key are guaranteed to run in constant time.
Maybe you're looking for unordered map's and unordered set's. Try taking a look at the TR1 unordered containers that rely on hashing, or the Boost.Unordered container library. Underneath the interface, I'm not sure if they really do use std::vector, but I'd wager it's worth taking a look at.