const-iterator

Here is my code: #include <set> #include <iostream> using namespace std; int main(){ set<int> st; st.insert(1); int x = st.find(1) - st.begin(); return 0; } I am getting error: no match for 'operator-' in 'st.std::set<_Key, _Compare, _Alloc>::find [with _Key = int, _Compare = std::less<int>, _Alloc = std::allocator<int>](((const int&)((const int*)(&1)))) - st.std::set<_Key, _Compare, _Alloc>::begin [with _Key = int, _Compare = std::less<int>, _Alloc = std::allocator<int>]()' . I am not able to figure out how did iterator difference stopped working all of a sudden! Am I missing something here?

With the advent of C++11, we have unordered_map.cbegin/cend to specifically return us values of const_iterator. so the deduced type of 'it' in the expression "auto it = unordered_map.cbegin()" is const_iterator. However, when it comes to unordered_map.find(key) function, I think there may be missing a "cfind()" counterpart, which returns a const_iterator specifically. Some say that we can use "const auto it = unordered_map.find(key)" to obtain a "const iterator", but I have a strong suspicion that "const iterator" is the same "const_iterator", where "const iterator" limits the ability to

I believe that since C++11, the erase function of most containers (e.g. std::vector ) accepts a const_iterator as parameter: iterator erase (const_iterator position); Still my compilers (GCC 4.8 and Clang 3.2, both using GCC libstdc++) won't allow me to use such function, even when compiling with --std=c++11 . Is it a compiler/libstdc++ bug, or did I do something bad? This is a sample code: #include <vector> int main( ) { std::vector<int> v; v.push_back( 1 ); v.push_back( 2 ); v.push_back( 3 ); std::vector<int>::const_iterator i = v.begin(); while( i != v.end() ) { i = v.erase( i ); } return 0

C++98 containers defined two kinds of iterator, ::iterator s and ::const_iterators . Generally, like this: struct vec{ iterator begin(); const_iterator begin() const; }; In C++11 this part of the design seems to be unchanged. The question is, for consistency and for practical purposes would it make sense to add ::move_iterator s as well? or it an overkill. I can imagine that an rvalue container maybe have their elements moved if possible. class vec{ iterator begin() &; const_iterator begin() const&; move_iterator begin() &&; }; If I understand correctly, it could be implemented like this in

Consider the following code: #include <vector> #include <iostream> int main() { std::vector<int> vec{1,2,3,5}; for(auto it=vec.cbegin();it!=vec.cend();++it) { std::cout << *it; // A typo: end instead of cend if(next(it)!=vec.end()) std::cout << ","; } std::cout << "\n"; } Here I've introduced a typo: in the comparison I called vec.end() instead of vec.cend() . This appears to work as intended with gcc 5.2. But is it actually well-defined according to the Standard? Can iterator and const_iterator be safely compared? Surprisingly, C++98 and C++11 didn't say that you can compare a iterator with a

I'm writing an own container class and have run into a problem I can't get my head around. Here's the bare-bone sample that shows the problem. It consists of a container class and two test classes: one test class using a std:vector which compiles nicely and the second test class which tries to use my own container class in exact the same way but fails miserably to compile. #include <vector> #include <algorithm> #include <iterator> using namespace std; template <typename T> class MyContainer { public: class iterator { public: typedef iterator self_type; inline iterator() { } }; class const

Someone here recently brought up the article from Scott Meyers that says: Prefer iterators over const_iterators ( pdf link ). Someone else was commenting that the article is probably outdated. I'm wondering what your opinions are? Here is mine: One of the main points of the article is that you cannot erase or insert on a const_iterator , but I think it's funny to use that as an argument against const_iterators . I thought the whole point of const_iterators it that you do not modify the range at all, neither the elements themselves by substituting their values nor the range by inserting or