Boost logo

Boost :

Subject: Re: [boost] Proposal/InterestCheck: Boost.Geom
From: Phil Endecott (spam_from_boost_dev_at_[hidden])
Date: 2009-01-29 12:30:47

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!

But as I said before, these details are less important than the
question of functionality: once I've wrapped up my GUI library's points
(etc), what can I actually *do* with them? Provide us with some
compelling algorithms (etc) and then we'll go along with whatever
stylistic decisions you have made.

You asked about previous submissions. Barend and Luke replied; there
has been one other recent one, by Brandon Kohn, announced here: This has
the disadvantage compared to the other two of a lack of documentation.

Cheers, Phil.

Boost list run by bdawes at, gregod at, cpdaniel at, john at