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

From: Simonson, Lucanus J (lucanus.j.simonson_at_[hidden])
Date: 2008-05-19 12:53:41

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.  The struct is not templated so it makes a convenient
tag.  In the static functions of the struct the first argument is
usually the templated geometry type.  In this way the geometry concept
can be used as both a namespace and a tag for resolving which function
to call depending on what conceptual type the user's object has.

The need for registration of a type can probably be dispensed with using
something like enable-if, but this means I'm not allowed (by the
compiler) to provide a default traits because that would not work with
SFINAE.  Right now all type identification is explicit and I use default
traits for my own types.  I'm still putting some thought into this on
how it could be improved.

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

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

Thanks,
Luke