Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a book, tool, software library, tutorial or other off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 8 years ago.
Improve this question
I'm looking for a lib that would implement something similar to std::map and multimap, but without tree but vectors instead, like a pair<vector<key>,vector<value>>. The lib would have to keep the vectors synchronized and sorted.
I'd like to compare the performance of maps, vector<pair<key,value>> and such a lib. I'm not going to try to make a general benchmark, I only want what's faster for my application.
I could just use map like everyone else, but -and I don't know I'm talking about- I fear for too many cache misses. My wild, uneducated guess is that my app, doing few, grouped inserts and many scattered searches, would benefit from more compact and contiguous keys.
As a matter of fact, if I was to code the thing, I'd do it with two classes. An unsorted version with only fast, push_back inserts permitted, then a transformation into a sorted version that would take the unsorted version, sort it, maybe check for duplicity, and then allow fast searches and slower, sorted inserts. This is actually Scott Meyers' Effective STL's Item 23: "Consider replacing associative containers with sorted vectors".
Edit: As pointed out by the Boost documentation about flat_(multi)map/set, Matt Austern, not Scott Meyers first suggested replacing maps and sets with vectors: http://lafstern.org/matt/col1.pdf
Maybe you are looking something like flat_(multi)map/set from Boost.Container ?
You should look into std::make_heap and associated functions, which manages a collection as a sorted heap. It fits almost perfectly your requirement of fast, unsorted inserts, and quick retrieval from a sorted collection.
Related
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
I mean, what is the use of studying different sorting algorithms when it can be done with the help of a single line in c++ using STL?
Is it just for the sake of knowing (or any other reason)?
It's comparable (i think) to knowing all of the different STL containers. Think about all the different options you have just too store objects, priority queue's, vectors, arrays, deques, stacks, maps, sets, etc... The list goes on. A naive programmer may simply use a std::vector for everything. I mean everyone is always saying such good things about std::vector, it manages it's own size, it's extremely fast at adding new elements, etc... The list goes on. But do you use std::vector for all your containers, i certainty hope not! The same logic apply's too knowing the various sorting algorithms, their are cases where the built in sorting mechanisms are simply inadequate, and you must not only know how to recognize when this situation occurs but be able too come up with a clean solution.
Just because the STL handles many operations (such as sorting) effectively it does not mean it will handle ALL situations effecively
Learning different ways to do things and the benefits/tradeofs they provide is often helpful.
For (an extreme) example; if you are sorting a container of at most 5 elements, then the lowly bubble sort may out-perform std::sort (which is most likely quicksort). So if this is something you do millions of times each second then you'd lose out with std::sort.
There is never (or at least "very rarely") a single " best" solution to a problem. So learning about the alternatives and the tradeoffs is valuable.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 9 years ago.
Improve this question
I'm looking for a boost or a stl API that mimics this one:
https://mxr.mozilla.org/mozilla-central/source/xpcom/ds/nsStaticNameTable.h
In short, to improve the lookup performance, it creates a map (hash) from a strings (char*) array in which the keys are the array indices.
I know it's easy to implement on top of other APIs.
First of all, have you benchmarked that the current implementation is particular slow? You should always benchmark before trying to optimize.
Anyway, it would seem that boost::bimap<> is just what you asked for. Then you simply replace the array with a boost::bimap, and make up your own indices on the fly.
Given an array of const char*s like that accepted by the nsStaticCaseInsensitiveNameTable::Init function, you can initialise an std::unordered_map<>:
std::unordered_map<const char*, int, my_equal_to<const char*>> string_to_index;
for (int i = 0; i < count; ++i)
string_to_index[aNames[i]] = i;
Unfortunately, the default hashing function - std::hash() - will has const char* addresses rather than the pointed-to ASCIIZ textual data, so you'll have to write your own or copy one. There's one called "my_equal_to" edited into the question at C++ unordered_map with char* as key
The only difference here is that the std::unordered_map's equivalents to "Lookup" (you could use operator[] if you knew the string would appear somewhere, otherwise it's best to use find) are not case insensitive, so you'd need to call a to_lower() string-processing function on your key if you weren't sure it was already lower case. (Note that per the nsStaticCastInsensitiveNameTable header's documentation, the strings it's asked to store must be lowercase as a precondition of use). If having to call some manner of to_lower() function bothers you, you could trivially wrap the unordered_map in your own class, that called to_lower() before forwarding to the search functions.
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 9 years ago.
Improve this question
why C++ STL have five iterators? Only random iterator could be sufficient to operate on all the containers. Any specific reason?
Sorry..It is my mistake..I did't mean random iterator...I was supposed to ask about bidirectional iterator...So don't you think that only bidirectional iterator can cover the functionality of input, output, forward iterators? So is there any specific reason to introduce (input, output, forward) iterators concept? Thanks. –
Containers aren't the the only interesting sequence. Also, std::list<...> and the associative containers don't have an efficient method for random access although they are containers. std::forward_list<...> can walk in just one direction. When sequences are sources or drains, they can often just traversed once. Oh, look! I actually gave reasons for all five categories!
Note that the "STL iterators" are not classes but concepts, i.e., requirements for operations and associated types needed to meet the respective iterator concept. The basic idea is that algorithm interfaces are specified in terms of the weakest concepts yielding an efficient implementation. When stronger concepts are provided to the algorithms they may be able to apply some optimizations. This approach yields flexible and efficient algorithms operating on all kinds of different sequences.
To get an idea why check this page
A random access iterator cannot always work. A simple example: If you're streaming data via the network, you cannot start again from the beginning. There are more reasons, but simply read the page.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 9 years ago.
Improve this question
I'm looking for book titles or papers about how to decompile X86 Disassembly into C/C++ code MANUALLY.
Well , I know about many tools that do the job , but I think doing it manually is more efficient even if it's a slow process.
If you are VERY used to looking at disassembly from a particular compiler, you MAY be able to come up with decent C or C++ code. But it's a TERRIBLY slow process even then. Just taking one small function (say a for-loop, a couple of if-statements and some basic math) and reconstructing it back into source code can take half an hour for me, and I don't think I'm terribly bad at it. Of course, one of the main points is identifying commonly used algorithms, such as linked lists, binary trees, string management, vector management, etc.
Doing it by machine will give you a lot of the work done for you, but even then, it can take days to do even a few hundred lines of orginal C++ code into something that is actually readable.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 5 years ago.
Improve this question
I am fairly new to C++, having much more C experience.
I am writing a program that will use the string class, and began to wonder about the efficiency of the "length()" method.
I realized though that I didn't have a good answer to this question, and so was wondering if the answer to this and similar questions exist somewhere. While I am more than capable of determining the runtime of my own code, I'm at a bit of a loss when it comes to provided code, and so I find I can't accurately judge the efficiency of my programs.
Is there c++ documentation (online, or in "man" format) that includes information on the runtime of provided code?
Edit: I'm interested in this in general, not just string::length.
At present, time complexity of size() for all STL containers is underspecified. There's an open C++ defect report for that.
The present ISO C++ standard says that STL containers should have size() of constant complexity:
21.3[lib.basic.string]/2
The class template basic_string conforms to the requirements of a Sequence, as specified in (23.1.1). Additionally, because the iterators supported by basic_string are random access iterators (24.1.5), basic_string conforms to the the requirements of a Reversible Container, as specified in (23.1).
23.1[lib.container.requirements]/5
Expression: a.size()
Complexity: (Note A)
Those entries marked ‘‘(Note A)’’ should have constant complexity
However, "should" is not a binding requirement in the Standard parlance; indeed, the above applies to std::list as well, but in practice some implementations (notably g++) have O(N) std::list::size().
The only thing that can be guaranteed is that (end() - begin()) for a string is (possibly amortized) O(1). This is because string iterators are guaranteed to be random-access, and random-access iterators are guaranteed to have constant time operator-.
As a more practical issue, for all existing C++ implementations out there, the following holds:
std::string::size() is O(1)
std::vector::size() is O(1)
They are fairly obvious, as both strings and vectors are most efficiently implemented as contiguous arrays with separately stored size: contiguous because it gives fastest element access while satisfying all other complexity requirements, and storing size is because Container requirements demand that end() be constant-time.
All of the implementations I've seen are O(1).
The documentation you're looking for is the C++ standard -- I believe C++03 is the latest one at present. It isn't available online or in man format, it's sold commercially. There's a list of the places to find it, and recent prices, here.