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.
Related
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 4 years ago.
Improve this question
I have always asked this question to myself. I tried to find the answer in the internet but, I just couldn't find what I was really looking for. If the developers made Vectors which can be used easier (according to some people), then what was the use of Arrays(which are generally avoided, according to some people aswell)?
The elements stored in an std::array can be allocated on the stack as the size is known at compile time and elements of a std::vector will be allocated on the heap. This can make a huge performance difference. Or more general, an std::array does not need its own memory allocation but an std::vector always does.
In C++, array is used to refer to two distinct kinds of things. One is std::array. The other is the built-in array type you get from a declaration like this: int foo[10];. This defines an array of 10 integers, named foo.
The advice against using an array will (at least usually) refer to the built-in array types. I don't know of anybody who advises against using std::array (except for cases where somebody needs a different container such as std::vector instead).
It's pretty easy to advise using std::array over a built-in array type simply because std::array is designed to impose no overhead compared to a built-in array type. In addition, however, std::array provides the normal container interface for getting things like the first element of the array, the size of the array, or iterators to the beginning and end so it's easy to apply a standard algorithm to an std::array.
Of course, all of these can be done with built-in array types as well. The implementation of std::array doesn't contain any "magic"--it just provides a standard interface to things you could do on your own. At the same time, it does provide a standard interface, and normally imposes no overhead, so there's rarely a reason to do the job on your own.
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 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 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.
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 7 years ago.
Improve this question
My application is having memory problems, including copying lots of strings about, using the same strings as keys in lots of hashtables, etc. I'm looking for a base class for my strings that makes this very efficient.
I'm hoping for:
String interning (multiple strings of the same value use the same memory),
copy-on-write (I think this comes for free in nearly all std::string implementations),
something with ropes would be a bonus (for O(1)-ish concatenation).
My platform is g++ on Linux (but that is unlikely to matter).
Do you know of such a library?
copy-on-write (I think this comes for free in nearly all std::string implementations)
I don't believe this is the case any longer. Copy-on-write causes problems when you modify the strings through iterators: in particular, this either causes unwanted results (i.e. no copy, and both strings get modified) or an unnecessary overhead (since the iterators cannot be implemented purely in terms of pointers: they need to perform additional checks when being dereferenced).
Additionally, all modern C++ compilers perform NRVO and eliminate the need for copying return value strings in most cases. Since this has been one of the most common cases for copy-on-write semantics, it has been removed due to the aforementioned downsides.
If most of your strings are immutable, the Boost Flyweight library might suit your needs.
It will do the string interning, but I don't believe it does copy-on-write.
Andrei Alexandrescu's 'Policy Based basic_string implementation' may help.
Take a look at The Better String Library from legendary Paul Hsieh