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

Subject: [ggl] Re: problems with Boost Geometry Xcode compile?
From: Bruno Lalande (bruno.lalande)
Date: 2010-03-11 07:59:43

Hi Mateusz,

> 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.

I wouldn't state it like that. It's just that macros don't care about
namespaces, so any library, even written *very* properly, is a
potential victim of macros. So it makes sense to include everything
that can declare a weird macro as late as possible. My order actually
meant that: standard libs are less likely to declare an evil macro
than Boost, that's less likely to declare an evil macro than other 3rd
party libs, that are less likely to declare an evil macro than my own
headers (because my own headers are used only in my program so if I'm
not developing a library I feel free to use whatever evil and ugly
macro I want :-) ).

In this regard, I agree that the respective order of standard libs vs.
Boost is subject to discussion...

> 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.

That's not what I meant, I was thinking about a standard header that
the end-user needs, not one that the other headers need.

But the rule I gave can't be a general rule anyway: when it comes to
include some headers in the .h and others in the .cpp, you can't
satisfy it in all cases. You have to find compromises.

Regards
Bruno