Subject: [ggl] Reviewing GGL against Boost requirements
From: Mateusz Loskot (mateusz)
Date: 2009-04-30 19:24:28
Barend Gehrels wrote:
> Mateusz Loskot wrote:
>> Bruno Lalande wrote:
>>>> The CamelCase template parameters are fine for me. Indentation
>>>> makes it (my opinion) a bit less readable but is OK for me,
>>>> I'll get used to it.
>>> About this: I think the most disturbing source of unreadability
>>> once namespaces de-indented comes from namespaces such as "impl"
>>> that tend to pollute the files. In this case maybe we could
>>> isolate them in a "impl" directory when it's possible. If find my
>>> sources more readable when I do that with the "detail"
>>> namespaces. Don't know if it helps for the code you're
>> I strongly agree. Many of Boost libs put implementation details
>> into detail namespace with its components physically separated in
>> dedicated directory, unsurprisingly, called details ;-)
> Sure. The only thing is that we'll get 4 (or more) files with the
> same name: algorithms/distance.hpp, algorithms/detail/distance.hpp,
> multi/algorithms/distance.hpp, multi.../detail..., and maybe also
> strategy/cartesian/distance.hpp (now cart_distance.hpp)...
Yes, it's true, but files are smaller and the structure helps to
work with maintainable modules. However, it has some drawbacks,
as everything ;)
> Personally I find that you'll loose the overview (today I'd two
> distance.hpp in my editor).
> But it is true, Boost libs have it often like that.
> I'll think about it.
OK. For me, no rush, we've been going through number of revolutions
>>>> What I really find hard is the 80 characters. Even if
>>>> namespaces are not indented. I tried to adapt and nearly all
>>>> lines get broken in the most weirdest places, and/or spread
>>>> over four lines. I just checked the Boost libraries and all the
>>>> libraries I checked (mpl, lambda, proto, variant, spirit) do
>>>> NOT follow it.
>>> Indeed some sources don't follow the rule, but much efforts are
>>> made to follow it if you look carefully. I think it can be broken
>>> but the writer has to keep this limit in mind in order to avoid
>>> running over it too much.
>> I agree. I don't mind extending 80 up to 100 but without forgetting
>> there is a limit, so 120 lines are forbidden.
>>> I'm OK to not be too strict about that, but let's at least stick
>>> to a 100-character rule.
>> ...and not more.
> OK, having read Bruno's mail I'll still try to have it like that (80,
> in rare cases more, but never more than 100), using Mateusz template
> indentation which is looking good.
I've updated guidelines in development_notes.txt.
-- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org
Geometry list run by mateusz at loskot.net