why C++ STL have five different iterators? [closed] - c++

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.

Related

Why do we need to learn different Sorting algorithms when the STL sort function is already available to us in C++? [closed]

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.

Use of studying different algorithm mechanism for sorting when STL does it crisply [closed]

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.

Implementing specialized data structures in modern C++ [closed]

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.

When is using an iterator appropriate? [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions concerning problems with code you've written must describe the specific problem — and include valid code to reproduce it — in the question itself. See SSCCE.org for guidance.
Closed 9 years ago.
Improve this question
I'm currently taking a class on data structures (in c++) and today we briefly touched iterators. The prof didn't really make much sense of it and while i acquired a basic understanding of what iterators do I was wondering if someone could expand on the topic, possibly giving a Pro's/Con's list of using them vs not preferably in c++ but a general outline would also work.
Thanks in advance to everyone who responds :).
Using an iterator can maintain the protected status of object data. For example, you will probably be iterating through a list. An iterator returned could allow you to step through the list elements (nodes) without being able to directly modify the list. It's implementation dependent, though. You could easily write your own iterator that allows direct modification of the list vectors. It's just another form of convenience abstraction.
An iterator as an interface (pure abstract) could be used to provide a common interface to iterate through different types of lists or arrays, as they are in Java, C#, etc.

Efficiency of c++ built ins [closed]

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.