Re: [boost] [GTL] proposal for geometry set operations

From: Fernando Cacciola (fernando.cacciola_at_[hidden])
Date: 2008-05-19 13:38:53

Hi Luke,

> Fernando,
>
> Please take a look at my post with subject "operator syntax proposal
> checked into sandbox" in which some of your questions are answered.
>
> I'll answer the questions you wont' find answers to in that post below:'
>
>>> The user must register their type as a polygon set type:
>>>
>>> template <>
>>> geometry_traits<std::list<UserPolygonType> > { typedef
>>> polygon_set_concept geometry_concept; };
>>>
>> This is probably explained somewhere but, could you state what a
>>
>> geometry_traits<T>::geometry_concept
>>
>> is?
>
> It is a struct that declares all functions that relate specifically to a
> geometry concept.
>
Sorry, I meant to as what a "geometry concept" is? at a entirely conceptual 
level.

I ask becasue I can't infer the meaning from the name (to it feels as it 
where "lucanus_concept" :)), nor from the particular polygon_set_concept 
example.

>> I would like better if the library used a general expression templates
>> framework instead of a custom mechanism so it can be used in much more
> than
>> just polygon set operations. But then of course, does boost has any of
> that
>> already?
>
> I'm not sure what you mean here.
>
I meant that lazy evaluation is the job of expression templates and that can 
(and should IMO) be intrumented by an *external* general framework for that 
purpose, like the pioneer PETE (http://acts.nersc.gov/pete/).
IOW, this shouldn't by just an ad-hoc mechanism within some portions of your 
library if possible.

>>> This proposed API is the most concise and intuitive way I can think
> of
>>> to provide these algorithms to the library user.
>>>
>> Do you mean the operator syntax or the lazy evaluation?
>> I don't care for the former, but I certainly do for the latter, and to
> a
>> broader extent.
>
> I meant the operator syntax.  The lazy evaluation is currently
> implemented as computing the full result of an operation only when it is
> used,
>
Indeed, which with a right framework becomes a property of any computation, 
not just clipping.

> but could be pushed further to have lazy iterator algorithms that
> produce the next increment of a result of an operation only when
> required.  Whether there is advantage in doing so, however, is currently
> unclear.
>
Right, I woudn't aim that far up now.

Best

-- 
Fernando Cacciola
SciSoft
http://scisoft-consulting.com
http://fcacciola.50webs.com
http://groups.google.com/group/cppba