Re: [boost] Proposal/InterestCheck: Boost.Geom

Subject: Re: [boost] Proposal/InterestCheck: Boost.Geom
From: Simonson, Lucanus J (lucanus.j.simonson_at_[hidden])
Date: 2009-01-29 14:23:14

Phil Endecott wrote:
> Anis Benyelloul wrote:
>> My purpose is to make the indirect approach as/more readable and
>> convenient
>> as the direct one so that the user's won't have to tie their code to
>> the
>> underlying framework's points and boxes (i.e they won't have to deal
>> directly
>> with QPoints at all).
>>
>> It seems that your [Barend's] purpose is rather: Provide lots of
>> algorithms and make them applicable to any type the user is
>> currently working with (the user will still
>> have to know/use QPoints before passing them to the algotithms).
>
> When I first talked about geometry on this list I felt much the same
> as
> you (Anis) about this particular choice.  Others (including Luke) felt
> that providing a library that users could apply to their "legacy" code
> was important.  I think I have now come around to that point of view:
> a
> boost geometry library shouldn't try to be a "master library" that
> hides all other libraries' interfaces, but rather it should be an
> "equal player" that can inter-operate with other code in whatever
> style
> the user wants.  My remaining concern about this is that it makes
> things more complicated: some of Luke's messages, for example, go way
> over my head!

Well, all the library proposals provide the ability to be a rossetta-stone of type conversion between all existing legacy geometric data types.  I'm not sure we abandoned the ability to be a master library.  In particular we can still apply the concepts based API to legacy code, the difference is that now it happens so transparently that users may not even notice that the library also works with everyone elses data types.

I'm also concerned that it makes things more complicated.  I literally have to tip toe around compiler bugs in all three: gcc, icc and MSVC.  ICC10 and earlier tries to instantiate operator templates for unnamed enum types instead of the built-in operator and throws syntax errors under certain circumstances of template meta-programming where it should SFINAE out.  ICC goes to 11 now, which fixes the problem, but I need to support the older versions too...

I worry that programming in this style is too hard.  I really hope Bjarne succeeds in making it easier, but I fear it will be 5 years after the new standard is ratified before we get to the point where we were at with last year's compilers and their support (or lack thereof) of the 03 standard.  I'll be 35 by then and ready to retire to management.  I really resisted adding all the complexity, but once I figured out what I would get for the work I put in it wasn't so bad to actually do it.  It is much harder to figure out why I need to use some metaprogramming tricks than to figure out how.  Every metaprogramming problem has a metaprogramming solution, you just add a layer of abstraction. ;)  Actually, if I didn't have the mantra "every metaprogramming problem has a metaprogramming solution" to keep me going I'd have probably given up porting to MSVC (which took two weeks) or providing generic operators that don't collide with std::operator+ on iterators etc.

Regards,
Luke