Geometry Boost List: [ggl] Re: problems with Boost Geometry Xcode compile?

Subject: [ggl] Re: problems with Boost Geometry Xcode compile?
From: Mateusz Loskot (mateusz)
Date: 2010-03-10 13:24:24

Bruno Lalande wrote:
> I'm a bit concerned about changing this name for the sake of an
> incompatibility with one compiler, as it can be the case with pretty
> much any C++ implementation that would overuse macros.

Bruno, I support your concern.

Bruno Lalande wrote:
> 
> When I write a C++ program, I always include stuff in the following
> order: C standard lib, C++ standard lib, boost headers, other 3rd
> party headers, my headers. Boost users should be advised to do this
> way (I remember that Boost.Python has the same constraint in some
> contexts) and that will easily avoid the majority of possible troubles.

I remember we had discussion about it. I agreed it's a good solution.
However, I personally don't like it, because it means that a library
(let's say Boost Geometry) depends on particular order of headers inclusion
on client side. It also means that Boost Geometry does not include
required C/C++ headers. For instance, if polygon.hpp uses std::vector
it should include <vector> but not leave it to user to include <vector>
before polygon.hpp to fulfil internal requirements of polygon.hpp.

I personally prefer to include C/C++ headers as last, boost and my private
headers
go always first in my code. This way, I can make sure my own headers are
self-contained
and independent from context of inclusion, and that they do not rely on
C/C++
headers dragged indirectly by Boost or 3rd-parties.

Anyway, even if I'm not convinced to it myself, in Boost Geometry we've
agreed
that C/C++ first, then Boost then Boost Geometry, so I sick to this.

Best regards,

-----
-- 
Mateusz Loskot
http://mateusz.loskot.net
-- 
View this message in context: http://n3.nabble.com/problems-with-Boost-Geometry-Xcode-compile-tp437866p440274.html
Sent from the Boost Geometry mailing list archive at Nabble.com.