Convention of headers inclusion

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Convention of headers inclusion

Mateusz Loskot
Administrator
Hi,

Is there any convention about order in which std, boost and ggl
headers should be included in GGL code?
Sometimes order of headers may cause different behaviour on different
C++ implementations, for instance by implicit inclusion (or lack of) of
some headers.

What's the suggested order of std, boost and ggl headers
included in ggl code?

Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org
--
Mateusz Loskot
http://mateusz.loskot.net
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Convention of headers inclusion

Mateusz Loskot
Administrator
Mateusz Loskot wrote:
> Hi,
>
> Is there any convention about order in which std, boost and ggl
> headers should be included in GGL code? Sometimes order of headers
> may cause different behaviour on different C++ implementations, for
> instance by implicit inclusion (or lack of) of some headers.
>
> What's the suggested order of std, boost and ggl headers included in
> ggl code?

Example of potential problems caused by implicit inclusion is in
file test/circle.cpp which includes:

#include <geometry/geometries/nsphere.hpp>
#include <geometry/core/concepts/nsphere_concept.hpp>

Reordering these two to include the concept first:

#include <geometry/core/concepts/nsphere_concept.hpp>
#include <geometry/geometries/nsphere.hpp>

gives compilation error:

In file included from circle.cpp:13:
../../geometry/core/concepts/nsphere_concept.hpp: In destructor
?geometry::ConstNsphere<S>::~ConstNsphere()?:
../../geometry/core/concepts/nsphere_concept.hpp:60: error: ?dimension?
was not declared in this scope
../../geometry/core/concepts/nsphere_concept.hpp:60: error: expected
primary-expression before ?>? token
../../geometry/core/concepts/nsphere_concept.hpp:60: error: ?::value?
has not been declared
../../geometry/core/concepts/nsphere_concept.hpp:61: error: ?N? is not a
valid template argument for type ?long unsigned int? because it is a
non-constant expression
../../geometry/core/concepts/nsphere_concept.hpp:61: error: invalid type
in declaration before ?;? token
../../geometry/core/concepts/nsphere_concept.hpp:62: error: ?N? is not a
valid template argument for type ?long unsigned int? because it is a
non-constant expression
../../geometry/core/concepts/nsphere_concept.hpp:62: error: invalid type
in declaration before ?;? token
../../geometry/core/concepts/nsphere_concept.hpp: In destructor
?geometry::Nsphere<S>::~Nsphere()?:
../../geometry/core/concepts/nsphere_concept.hpp:107: error: ?dimension?
was not declared in this scope
../../geometry/core/concepts/nsphere_concept.hpp:107: error: expected
primary-expression before ?>? token
../../geometry/core/concepts/nsphere_concept.hpp:107: error: ?::value?
has not been declared
../../geometry/core/concepts/nsphere_concept.hpp:108: error: ?N? is not
a valid template argument for type ?long unsigned int? because it is a
non-constant expression
../../geometry/core/concepts/nsphere_concept.hpp:108: error: invalid
type in declaration before ?;? token
../../geometry/core/concepts/nsphere_concept.hpp:109: error: ?N? is not
a valid template argument for type ?long unsigned int? because it is a
non-constant expression
../../geometry/core/concepts/nsphere_concept.hpp:109: error: invalid
type in declaration before ?;? token



This is because <geometry/core/concepts/nsphere_concept.hpp> uses
dimension type but does include coordinate_dimension.hpp, which in the
original (working) version is included implicitly/indirectly by
<geometry/geometries/nsphere.hpp>

AFAIU, actual fix for this is to add following line to header
<geometry/core/concepts/nsphere_concept.hpp>:

#include <geometry/core/coordinate_dimension.hpp>

Then, inclusion of only nsphere_concept.hpp header will work.

Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org
--
Mateusz Loskot
http://mateusz.loskot.net
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Convention of headers inclusion

Barend Gehrels


Mateusz Loskot wrote:

> Example of potential problems caused by implicit inclusion is in
> file test/circle.cpp which includes:
>
> #include <geometry/geometries/nsphere.hpp>
> #include <geometry/core/concepts/nsphere_concept.hpp>
>
> Reordering these two to include the concept first:
>
> #include <geometry/core/concepts/nsphere_concept.hpp>
> #include <geometry/geometries/nsphere.hpp>
>
> gives compilation error:
>
> [snipped]
>
>
> AFAIU, actual fix for this is to add following line to header
> <geometry/core/concepts/nsphere_concept.hpp>:
>
> #include <geometry/core/coordinate_dimension.hpp>
>
> Then, inclusion of only nsphere_concept.hpp header will work.
>
>  
Right, this is how it should be, thanks.
Barend
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Convention of headers inclusion

Barend Gehrels
In reply to this post by Mateusz Loskot

> Is there any convention about order in which std, boost and ggl
> headers should be included in GGL code?
>  
Good question. As far as I know Boost does not give a guideline about
this. I glanced through some of the boost headers and they usually
include boost headers first, then std headers. This is different from
what I did, I usually put the std headers first. But it makes sense to
first put the boost headers - they might define macro's which change the
behaviour of the std library.

So I would propose the order is:
1) boost headers
2) geometry headers (because ggl might once belong to boost)
  within geometry:
    a) core
    b) strategies
    c) algorithms
3) std headers


Regards, Barend



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Convention of headers inclusion

Mateusz Loskot
Administrator
Barend Gehrels wrote:
>
>> Is there any convention about order in which std, boost and ggl
>> headers should be included in GGL code?
>>  
> Good question. As far as I know Boost does not give a guideline about
> this. I glanced through some of the boost headers and they usually
> include boost headers first, then std headers. This is different from
> what I did, I usually put the std headers first.

I usually try to stick to a simple rule: include a std header in every
file that uses type defined in that header and avoid indirect and
implicit inclusions.

I usually put std headers as last, so I it helps me to avoid
implicit inclusion of std types.

> But it makes sense to first put the boost headers - they might
> define macro's which change the behaviour of the std library.

Yes.

> So I would propose the order is:
> 1) boost headers
> 2) geometry headers (because ggl might once belong to boost)
>  within geometry:
>    a) core
>    b) strategies
>    c) algorithms
> 3) std headers

Great. That's best practice IMHO too.

Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org
--
Mateusz Loskot
http://mateusz.loskot.net
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Convention of headers inclusion

Bruno Lalande
Hi,

>> So I would propose the order is:
>> 1) boost headers
>> 2) geometry headers (because ggl might once belong to boost)
>>  within geometry:
>>    a) core
>>    b) strategies
>>    c) algorithms
>> 3) std headers

I agree except for the std headers, which I usually place in first.
This avoids to have any other header influencing them in any way, such
as macro definition, use of reserved names, or anything else. So I
usually use this order:

standard C headers
std headers
boost headers
3rdparty libraries headers
my headers (here: GGL headers)

But as Barend said, GGL headers are meant to belong to Boost one day,
so they could be placed just after Boost headers...

BTW, thanks for the subscription to the GGL list :-) Sorry for my
absence this weekend about all that, I was a bit busy.

Regards
Bruno
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Convention of headers inclusion

Mateusz Loskot
Administrator
Bruno Lalande wrote:

> Hi,
>
>>> So I would propose the order is:
>>> 1) boost headers
>>> 2) geometry headers (because ggl might once belong to boost)
>>>  within geometry:
>>>    a) core
>>>    b) strategies
>>>    c) algorithms
>>> 3) std headers
>
> I agree except for the std headers, which I usually place in first.
> This avoids to have any other header influencing them in any way, such
> as macro definition, use of reserved names, or anything else.

Bruno,

This is a good point, indeed.

> So I usually use this order:
>
> standard C headers
> std headers
> boost headers
> 3rdparty libraries headers
> my headers (here: GGL headers)
>
> But as Barend said, GGL headers are meant to belong to Boost one day,
> so they could be placed just after Boost headers...

Sure, works for me. Can we accept it as convention used in GGL?

Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org
--
Mateusz Loskot
http://mateusz.loskot.net
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Convention of headers inclusion

Bruno Lalande
Hi Mateusz,

> Sure, works for me. Can we accept it as convention used in GGL?

This is something we don't have yet and which is very valuable, so I
vote yes :-)

Regards
Bruno
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Convention of headers inclusion

Barend Gehrels
In reply to this post by Mateusz Loskot



> Bruno,
>
> This is a good point, indeed.
>
>  
>> So I usually use this order:
>>
>> standard C headers
>> std headers
>> boost headers
>> 3rdparty libraries headers
>> my headers (here: GGL headers)
>>
>> But as Barend said, GGL headers are meant to belong to Boost one day,
>> so they could be placed just after Boost headers...
>>    
>
> Sure, works for me. Can we accept it as convention used in GGL?
>
>  
I checked more boost headers and I see both approaches. This works for
me as well. Actually it is like this in most sources. Will I ask the
boost-list if there is a recommendation?

Barend

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/ggl/attachments/20090415/c5d7c3c5/attachment.html
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Convention of headers inclusion

Mateusz Loskot
Administrator
In reply to this post by Bruno Lalande
Bruno Lalande wrote:
> Hi Mateusz,
>
>> Sure, works for me. Can we accept it as convention used in GGL?
>
> This is something we don't have yet and which is very valuable, so I
> vote yes :-)

OK.

One day, if there is a Wiki we can document it.
In the meantime, I'll consider what we are discussing as guidelines :-)

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