Edit Question - KnowledgeHub

Title Body

I've recently begun to prefer the free functions std::next and std::prev to explicitly copying and incrementing/decrementing iterators. Now, I am seeing weird behavior in a pretty specific case, and I would appreciate any help demystifying it. I have an interpolation/extrapolation function operating on a boost::any_range of some X_type . The full definition of the range type is: boost::any_range < const X_type, boost::random_access_traversal_tag, const X_type, std::ptrdiff_t > The any_range , in this particular case, is assigned from an iterator_range holding two pointers to const X_type , which serves as an X_type view of about half of the data() area of a vector<char> . Compiling my application in MSVC 2010, everything works just fine. Compiling the same code in MinGW g++ 4.7.0, it seemed to hang in one particular location, which I've then narrowed down to this (slightly abbreviated): // Previously ensured conditions: // 1) xrange is nonempty; // 2) yrange is the same size as xrange. auto x_equal_or_greater = std::lower_bound(std::begin(xrange),std::end(xrange),xval); if (x_equal_or_greater == std::end(xrange)) { return *yit_from_xit(std::prev(x_equal_or_greater),xrange,yrange); } Stepping through the code in gdb, I found out it wasn't getting stuck, just taking a very long time to return from the single std::prev call - which in libstdc++ is implemented in terms of std::advance and ultimately the += operator. By merely replacing the return line with: auto xprev=x_equal_or_greater; --xprev; return *yit_from_xit(xprev,xrange,yrange); Performance is great again, and there's virtually no delay. I am aware of the overhead

Tags (comma-separated) Cancel