Geometry Boost List: [ggl] Headers order (was: problems with Boost Geometry Xcode compile?)

Subject: [ggl] Headers order (was: problems with Boost Geometry Xcode compile?)
From: Mateusz Loskot (mateusz)
Date: 2010-03-11 16:48:57

Bruno Lalande wrote:
>> 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.

Bruno,

You're right, of course.
I wasn't referring to macros only, but to all definitions, to headers
as a whole.

> So it makes sense to include everything that can declare a weird 
> macro as late as possible.

Aha! I see your point much better now. I agree that it is necessary or a
good idea, sometimes. But, as probably everyone here has observed,
experiences with variety of C/C++ implementations and build environments
show that the judgement on what headers are troublesome and what are
save is somewhat fragile.

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

Aha once again! Generally, I agree :-) but specifically I don't really
believe it's robust enough to make it a strong convention.
Quick test with GCC shows that even if I really want to be C++ purist,
I'm being offered with pile of unrelated garbage:

#include <iostream>
#ifdef _GNU_SOURCE
#error _GNU_SOURCE
#endif
#ifdef _POSIX_SOURCE
#error _POSIX_SOURCE
#endif
#ifdef _XOPEN_SOURCE
#error _XOPEN_SOURCE
#endif
#ifdef _SVID_SOURCE
#error _SVID_SOURCE
#endif
#ifdef _ISOC99_SOURCE
#error _ISOC99_SOURCE
#endif
int main(){}

$ g++ -Wall -pedantic -std=c++98 -ansi test.cpp
test.cpp:3:2: error: #error _GNU_SOURCE
test.cpp:6:2: error: #error _POSIX_SOURCE
test.cpp:9:2: error: #error _XOPEN_SOURCE
test.cpp:12:2: error: #error _SVID_SOURCE
test.cpp:15:2: error: #error _ISOC99_SOURCE

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

Yes, you've clarified it to me above.

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

Yes, that's right. Practical conclusion seems to sound that we should
not care about the order, but I think it's a good idea to not to freely
spread and interleave headers, but to keep things clean.

As I said, I do agree with the order you proposed.

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org