Geometry Boost List: [ggl] Reviewing GGL against Boost requirements

Subject: [ggl] Reviewing GGL against Boost requirements
From: Barend Gehrels (Barend.Gehrels)
Date: 2009-04-30 16:23:55

Hi Mateusz, Bruno,

Mateusz Loskot wrote:
> Bruno Lalande wrote:
>> Hi Barend,
>>
>>> 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 reshaping...
>
> 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)...
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.

> I practice it myself and I like it
> (http://liblas.org/svn/trunk/include/liblas/)
Interesting!

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

Regards, Barend