Geometry Boost List: [ggl] namespaces and ADL

Subject: [ggl] namespaces and ADL
From: Bruno Lalande (bruno.lalande)
Date: 2010-12-14 08:51:41

Hi Barend,

When I read this yesterday I thought it was indeed the only solution. But
today at second thought, I'm not that convinced. I'm not even convinced we
should care about ADL at all in this particular case. But I might be
misunderstanding something.

If I understand correctly, before the namespace change, we had:
- boost::geometry::polygon class
- boost::geometry::area function

Now we have:
- boost::geometry::model::polygon class
- boost::geometry::algorithms::area function

So area is no longer found by ADL. Both changes have to be reverted so that
ADL works again. Is my understanding correct?

If yes, then I would like to point out that we have the same problem for
custom types anyway (which are the whole point of Boost.Geometry). You will
typically end up in the following situation:

- my_namespace::my_polygon class (models polygon concept)
- boost::geometry::area function

Now try:
my_namespace::my_polygon p;
cout << area(p) << endl;

It won't work. And you can't do much about it. The user will typically put
the appropriate "using namespace" stuff in his program, or specify the
namespace at calling site. This is how all other libraries work. Say I want
to use the remove_all() algorithm from Boost.StringAlgo, I'll obviously have
to use the boost::algorithm namespace it lives in, and I don't find anything
shocking here.

So I'm not quite sure if having ADL work in such situation is that much a
concern. AFAIK, the only places where it's important is when it's necessary
for the library itself to work. For instance the Boost.Math bindings use it
to find math functions, and if you want your library to be
Boost.Math-binding-compliant you have to call functions like sqtr(), cos()
and so on without any namespace to ensure that you will end up in the
overloaded which belongs to the arithmetic type you are using. So ADL is
important there. But at end-user level, it's not that relevant. Am I missing
something?

Regards
Bruno
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/ggl/attachments/20101214/fa3e41a7/attachment-0001.html