2

I'm using Visual Studio 2013 and wizard created Win32 Console Application project. This code:

    #include <boost/geometry.hpp>
    #include <boost/geometry/geometries/point_xy.hpp>

    using namespace std;
    using namespace boost::geometry;

    int main()
    {
        model::d2::point_xy<int> p1(1, 1), p2(2, 2);
        cout << "Distance p1-p2 is: " << distance(p1, p2) << endl;

        return 0;
    }

produces a long template barf starting with:

error C2039: 'iterator_category' : is not a member of 'boost::geometry::model::d2::point_xy<int,boost::geometry::cs::cartesian>'

The same code runs fine with gcc and clang. Do I have to change my project settings to make it compile?

EDIT

This code works fine with Visual Studio 2015 CTP, so the problem is a deficiency of overload resolution in VS2013 as Marc Glisse pointed out.

using namespace std is not a root of the problem here as juanchopanza claims. Considering it a bad practice is somewhat arbitrary, as there are many arguments to the contrary (see discussion at Why is “using namespace std;” considered bad practice?). In this specific case, one can argue that using namespace boost::geometry is a bad practice, not using namespace std.

The quest of some editors to remove all redundancy from stackoverflow questions will make search more difficult, due to chicken and egg paradox: one would have to know an answer to the question before embarking on a successful search. Ultimately you could reduce the entirety of stackoverflow to 42, but utility would suffer.

genpfault
  • 51,148
  • 11
  • 85
  • 139
Paul Jurczak
  • 7,008
  • 3
  • 47
  • 72

1 Answers1

1

The std::distance function computes the distance between two iterators.

Try removing the using namespace std or properly qualify the boost distance function.

Edit

The question remains, why gcc and clang didn't complain?

As @MarcGlisse points out the reason for this may boil down to the level of sophistication employed by the C++ library implementation:

Recent versions of libstdc++ and libc++ use sfinae

Old versions of Visual Studio don't do that yet

This is a very plausible explanation as to why it works for some compilers and not others, as SFINAE is a mechanism to remove functions from the set of possible functions the compiler will consider. For more information about SFINAE (cppreference.com and WIKIPEDIA)

Community
  • 1
  • 1
James Adkison
  • 9,412
  • 2
  • 29
  • 43
  • No, still the same problem. – Paul Jurczak Apr 18 '15 at 04:10
  • Using `boost::geometry::distance` solves the problem, thank you. The question remains, why gcc and clang didn't complain? Shouldn't the template resolution continue until all possible options are exhausted? – Paul Jurczak Apr 18 '15 at 05:03
  • @PaulJurczak I'm not sure why it works for those compilers but not Visual Studio 2013. It seems that for Visual Studio it doesn't keep looking because it found the match it wants, it's just the chosen match doesn't compile (perhaps the headers you're including on those platforms never include ``?). – James Adkison Apr 18 '15 at 05:12
  • 1
    Recent versions of libstdc++ and libc++ use sfinae to constrain the arguments of std::distance, so unsuitable arguments mean this overload is ignored. Old versions of Visual Studio don't do that yet and have a hard error. – Marc Glisse Apr 18 '15 at 06:35
  • @MarcGlisse Thank you, that sounds like a very plausible reason. I updated my answer based on your feedback. – James Adkison Apr 18 '15 at 06:47
  • @MarcGlisse You are right. The same code works fine with Visual Studio 2015 CTP. – Paul Jurczak Apr 18 '15 at 15:41