Boost logo

Boost :

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

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

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


Fernando Cacciola

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