I want to sort a vector using sort algorithm in C++.
str is the name of std::vector<int> I want to sort.
What's the difference between this:
std::sort(str.rend(),str.rbegin())
and this:
std::sort(str.begin(),str.end())
Assuming you intend to use std::sort to sort the string (since neither std::vector nor std::string have a sort method), the first statement is incorrect and leads to undefined behaviour (UB):
std::sort(str.rend(),str.rbegin());
Here, std::sort will attempt to dereference str.rend(), which is a "past the end" iterator. De-referencing such an iterator is UB.
A correct use of reverse iterators would be
std::sort(str.rbegin(),str.rend());
This would result in the string/vector being sorted in descending order.
The iterators in the standard library on lots of containers and other things (like std::string) have a reverse variety which begin with r (rbegin(), rend and the like). These will iterate in the reverse-sequential order. Using just begin and end will sort your string in the correct format from start to finish.
Try to avoid using the reverse iterators and just use the regular begin() and end() on your strings:
std::string str = "bacd";
std::sort( str.begin(),str.end() );
std::cout << str << std::endl; // should produce "abcd" on your output, without quotes
Edit:
So... you want vector<int> to be sorted instead? If so, do the same as above, except call std::sort with the begin() and end() of your std::vector<int>.
Related
std::multimap<std::string, std::string> authors;
authors.insert ({{"Steven,King", "Cujo"}, {"Jesse,James", "The Highlight"}});
auto it = authors.begin();
auto retVal2 = authors.erase(it+1);
for (auto &i : authors){
std::cout << i.first << " " << i.second << std::endl;
}
Is it not allowed to add values to the iterator to move to the desired location in the multimap?
In vectors this can be done.
Please clarify if there is anyway about this?
thank you.
std::multimap::iterator is a bidirectional iterator. A bidirectional iterator does not have operator+ because it can only advance one at a time making operator+ a very slow function. Maybe you're comparing it to the iterator of something like std::vector or std::array. However, those are random access iterators where operator+ can work in constant time.
Since you only need to add it by 1, you can easily replace it+1 with std::next(it). If you want to make a new iterator n elements after it you can also do std::next(it, n). Like std::next, there's also std::prev for going backwards. If you want to modify it itself, you can use operator++/operator-- (which act like how you would expect them to) or use std::advance(it, n) to go n elements forward or backward (There's no opposite of std::advance like std::recede, to make your iterator go back n should be a negative number).
Consider the following code (taken from cppreference.com, slightly adapted):
#include <algorithm>
#include <string>
#include <iostream>
#include <cctype>
int main()
{
std::string str1 = " Text with some spaces";
str1.erase(std::remove(str1.begin(), str1.end(), ' '), str1.end());
std::cout << str1 << '\n';
return 0;
}
Why is the second parameter to erase neccessary? (I.e. str1.end() in this case.)
Why can't I just supply the iterators which are returned by remove to erase? Why do I have to tell it also about the last element of the container from which to erase?
The pitfall here is that you can also call erase without the second parameter but that produces the wrong result, obviously.
Are there use cases where I would not want to pass the end of the container as a second parameter to erase?
Is omitting the second parameter of erase for the erase-remove idiom always an error or could that be a valid thing to do?
std::remove returns one iterator; it's the new past-the-end iterator for the sequence. But when the sequence is managed by a container, the size of the container hasn't changed; std::remove shuffles the order of the elements in the sequence, but doesn't actually remove any of them.
To get rid of the elements in the container that are not part of the new sequence you call, of course, container.erase(). But the goal is to remove all the extra elements; calling container.erase() with only one iterator tells it to remove that element. To tell container.erase() to erase everything "from here to the end" you have to tell it both where "here" is and where the end is. So that means two iterators.
If it helps, think of the "remove/erase" idiom as two separate steps:
auto new_end = std::remove(str1.begin(), str1.end(), ' ');
str1.erase(new_end, str1.end());
According to some STL documentation I found, inserting or deleting elements in an std::list does not invalidate iterators. This means that it is allowed to loop over a list (from begin() to end()), and then add elements using push_front.
E.g., in the following code, I initialize a list with elements a, b and c, then loop over it and perform a push_front of the elements. The result should be cbaabc, which is exactly what I get:
std::list<std::string> testList;
testList.push_back("a");
testList.push_back("b");
testList.push_back("c");
for (std::list<std::string>::iterator itList = testList.begin(); itList != testList.end(); ++itList)
testList.push_front(*itList);
for (std::list<std::string>::const_iterator itList = testList.begin(); itList != testList.end(); ++itList)
std::cout << *itList << std::endl;
When I use reverse iterators (loop from rbegin() to rend()) and use push_back, I would expect similar behavior, i.e. a result of abccba. However, I get a different result:
std::list<std::string> testList;
testList.push_back("a");
testList.push_back("b");
testList.push_back("c");
for (std::list<std::string>::reverse_iterator itList = testList.rbegin(); itList != testList.rend(); ++itList)
testList.push_back(*itList);
for (std::list<std::string>::const_iterator itList = testList.begin(); itList != testList.end(); ++itList)
std::cout << *itList << std::endl;
The result is not abccba, but abcccba. That's right there is one additional c added.
It looks like the first push_back also changes the value of the iterator that was initialized with rbegin(). After the push_back it does not point anymore to the 3rd element in the list (which was previously the last one), but to the 4th element (which is now the last one).
I tested this with both Visual Studio 2010 and with GCC and both return the same result.
Is this an error? Or some strange behavior of reverse iterators that I'm not aware of?
The standard says that iterators and references remain valid during an insert. It doesn't say anything about reverse iterators. :-)
The reverse_iterator returned by rbegin() internally holds the value of end(). After a push_back() this value will obviously not be the same as it was before. I don't think the standard says what it should be. Obvious alternatives include the previous last element of the list, or that it stays at the end if that is a fixed value (like a sentinel node).
Technical details: The value returned by rend() cannot point before begin(), because that is not valid. So it was decided that rend() should contain the value of begin() and all other reverse iterators be shifted one position further. The operator* compensates for this and accesses the correct element anyway.
First paragraph of 24.5.1 Reverse iterators says:
Class template reverse_iterator is an iterator adaptor that iterates from the end of the sequence defined
by its underlying iterator to the beginning of that sequence. The fundamental relation between a reverse
iterator and its corresponding iterator i is established by the identity:
&*(reverse_iterator(i)) == &*(i - 1).
I think to understand this, it's best to start by re-casting the for loop as a while loop:
typedef std::list<std::string> container;
container testList;
testList.push_back("a");
testList.push_back("b");
testList.push_back("c");
container::reverse_iterator itList = testList.rbegin();
while (itList != testList.rend()) {
testList.push_back(*itList);
++itList;
}
Along with that, we have to understand how a reverse_iterator works in general. Specifically a reverse_iterator really points to the element after the one you get when you dereference it. end() yields an iterator to just after the end of the container -- but for things like arrays, there's no defined way to point to just before the beginning of a container. What C++ does instead is have the iterator start from just after the end, and progress to the beginning, but when you dereference it, you get the element just before where it actually points.
That means your code actually works like this:
After that, you get pretty much what you expect, pushing back B and then A, so you end up with ABCCCBA.
Try using an iterator for both. Try:
std::list<std::string>::iterator i = testList.end();
and reverse through with --i
The standard way to remove certain elements from a vector in C++ is the remove/erase idiom. However, the predicate passed to remove_if only takes the vector element under consideration as an argument. Is there a good STL way to do this if the predicate is conditional on other elements of the array?
To give a concrete example, consider removing all duplicates of a number immediately following it. Here the condition for removing the n-th element is conditional on the (n-1)-th element.
Before: 11234555111333
After: 1234513
There's a standard algorithm for this. std::unique will remove the elements that are duplicates of those preceding them (actually, just like remove_if it reorganizes the container so that the elements to be removed are gathered at the end of it).
Example on a std::string for simplicity:
#include <string>
#include <iostream>
#include <algorithm>
int main()
{
std::string str = "11234555111333";
str.erase(std::unique(str.begin(), str.end()), str.end());
std::cout << str; // 1234513
}
Others mentioned std::unique already, for your specific example. Boost.Range has the adjacent_filtered adaptor, which passes both the current and the next element in the range to your predicate and is, thanks to the predicate, applicable to a larger range of problems. Boost.Range however also has the uniqued adaptor.
Another possibility would be to simply keep a reference to the range, which is easy to do with a lambda in C++11:
std::vector<T> v;
v.erase(std::remove_if(v.begin(), v.end(),
[&](T const& x){
// use v, with std::find for example
}), v.end());
In my opinion, there will be easier to use simple traversal algorithm(via for) rather then use std::bind. Of course, with std::bind you can use other functions and predicates(which depends on previous elements). But in your example, you can do it via simple std::unique.
Using STL, I want to find the last instance of a certain value in a sequence.
This example will find the first instance of 0 in a vector of ints.
#include <algorithm>
#include <iterator>
#include <vector>
typedef std::vector<int> intvec;
intvec values;
// ... ints are added to values
intvec::const_iterator split = std::find(values.begin(), values.end(), 0);
Now I can use split to do things to the subranges begin() .. split and split .. end(). I want to do something similar, but with split set to the last instance of 0. My first instinct was to use reverse iterators.
intvec::const_iterator split = std::find(values.rbegin(), values.rend(), 0);
This doesn't work because split is the wrong type of iterator. So ...
intvec::const_reverse_iterator split = std::find(values.rbegin(), values.rend(), 0);
But the problem now is that I can't make "head" and "tail" ranges like begin(), split and split, end() because those aren't reverse iterators. Is there a way to convert the reverse iterator to the corresponding forward (or random access) iterator? Is there a better way to find the last instance of an element in the sequence so that I'm left with a compatible iterator?
But the problem now is that I can't
make "head" and "tail" ranges using
begin() and end() because those aren't
reverse iterators.
reverse_iterator::base() is what you are looking for - section new members on SGIs reverse_iterator description or here on cppreference.com
What about std::find_end? (To find the last occurrence of a sequence)