Community
Participate
Working Groups
Build Identifier: 8.1.0.201201231635 I have the code std::multimap<float, std::string> sortedList; for (auto i=sortedList.rbegin(); i!=sortedList.rend(); ++i) std::cout << std::setw(40) << std::left << i->second << i->first << std::endl; I get "second", "first" and "std::cout" marked as errors and the marker reads "Field second could not be resolved - Invalid overload of std::cout - Field first could not be resolved". If I replace the second line with for (std::multimap<float, std::string>::iterator i=sortedList.rbegin(); i!=sortedList.rend(); ++i) which is wrong and does not compile, the error markers are gone, if I use for (std::multimap<float, std::string>::reverse_iterator i=sortedList.rbegin(); i!=sortedList.rend(); ++i) which is the correct type, it gets marked as an error. Reproducible: Always Steps to Reproduce: Use auto variable of a reverse_iterator type.
The bug title is misleading, while typing I discovered that not the usage of auto seems to be the culprit, but rather the reverse_iterator.
I cannot reproduce the problem, most likely it depends on the system headers in use. What's the version of the compiler you are using?
gcc 4.6.2 If I hover over the "i" variable in the not working case, I get a tooltip with line 129-133 from the file stl_iterator.h, where the copy constructor of a reverse_iterator is defined. /** * The copy constructor is normal. */ reverse_iterator(const reverse_iterator& __x) : current(__x.current) { } So it seems the return type of rbegin() is correctly recognized.
The reason for the wrong parsing is possibly the noexcept keyword. Eclipse doesn't seem to recognize it, and it's freely used in newer versions of the gcc stdlibc++ . Similar issues arise with constexpr, but for the latter it can easily replaced with a macro which expands to nothing. This makes the gcc std c++ library basically unusable in C++11 mode.
(In reply to comment #3) > gcc 4.6.2 See https://bugs.eclipse.org/bugs/show_bug.cgi?id=374993#c4 for workaround.
The code in question is parsed correctly with CDT 8.3 (I tried GCC 4.6 and GCC 4.9 headers). I think we can close this report.
Closing per comment 6.
