Subject: [ggl] Header inclusion guards
From: Mateusz Loskot (mateusz)
Date: 2009-04-17 05:27:39
Barend Gehrels wrote:
> Hi Mateusz,
>> As it was discussed and agreed off-list, I've started refactoring
>> existing inclusion guards. I decided to follow MPL and other Boost
>> libraries and generate guards based on physical path to a file
>> instead of the logical one - namespaces.
>> So, here is the convention I'm applying:
>> Example, header
>> is gaurded with:
>> I don't append _INCLUDED suffix, because such guards are long
>> enough to consider them as (pseudo-)unique.
> I realize that you already started (I see about 15 updates in
> arithmetic, strategies). The GGL_GEOMETRY seems a bit redudant to me.
> Don't know how far you are besides the commits. Is it still possible
> to change it in GGL_STRATEGIES_DISTANCE_RESULT_HPP? Makes it somewhat
> shorter and less redundant.
I've applied fixes only to a few files so far, so it's not too late.
However, thinking of Boost'ification, I'm not sure, but we may need
to change it again.
Layout of Boost libraries is as follows:
- translation units, tests, examples, doc
So, we may need to re-layout GGL as follows:
- no .cpp units, but we have tests, examples, doc
This way it will be very easy to integrated ggl headers and
libs/ggl into Boost tree.
Given that, if we agree to re-structure ggl, then inclusion guards will
look exactly as you are suggesting:
Perhaps it seems a cosmetic, but I wouldn't be sure if it is.
Many of Boost conventions have been already applied to GGL,
so why not to apply Boost structure too, especially if GGL
is going to be merged into Boost one day.
Shortly, the point is to not to do the same work twice :-)
What do you think?
-- Mateusz Loskot, http://mateusz.loskot.net
Geometry list run by mateusz at loskot.net