Re: [boost] [GTL] - geometric template library - determininginterest

From: Joel de Guzman (joel_at_[hidden])
Date: 2007-10-05 19:22:31

Simonson, Lucanus J wrote:
> Joel wrote:
>> That's very good. I'm not quite sure about inheritance though.
> 
>>> P.S. my point2d data structure is a class encapsulated array of size
> 2.  
>>> You can override it with your own, of course, through the template 
>>> inheritance generic interface.
> 
>> With the restriction that it has to be indexable by a runtime int?
>> That is a severely limited concept of a point, I would say. And,
>> again, I find the need for inheritance dubious. Inheritance gives
>> you tight coupling. Something that you'd want to avoid when
>> adopting a 3rd party type. It is possible to adopt a 2d-point
>>from library A and library B without ever touching them. That's
>> the very essence of generic programming.
> 
> I put a lot of thought into the implications of inheritance, believe me.
> There is no restrition that it has to be indexable by a runtime int.

Hmm. I was confused by your earlier post, it seems:

 > Moreover, the technique you are proposing works fine at compile time,
 > but won't work if the axis of the coordinate you are accessing is a
 > runtime parameter:
 > int my_axis = 0;
 > get<my_axis>(pt);
 > will throw an error.  We specify the axis we access at run time.  If we
 > specify a constant it should compile away and be light weight.  gcc
 > 4.2.1 still needs us to play with the compiler flags to get decent
 > inlining.
 > pt.get(orient.getPerpendicular()); //orientation determined at run time.
 > My scanline algorithm actually parameterizes the orientation of the
 > scanline at runtime, so you can sweep left to right or bottom to top.

[snip]

> All this seems like overkill with simple point2d data types but when you
> have polygons that are sequences of vertices it becomes a Rosetta stone
> of type inter-compatibility and a mechanism for getting legacy data in
> and out of algorithms in a generic, zero cost of abstraction way that is
> minimal effort and very productive (not error prone.)  When you realize
> that my Polygon concept class uses my Point concept class to interact
> with its vertices the whole picture suddenly becomes clear.  Sometimes
> it is useful to have a polygon that is a linked list of points.
> Sometimes it is useful to have a vector, sometime it is useful to have a
> compressed storage for polygon data.  The polygon concept class is the
> glue that can really tie everything together and make it all work
> together as smooth as butter.
> 
> By the way if you have a 3D point you can view it as a 2D point (because
> conceptually it is a 2D point with extra semantics.)  I do that all the
> time, and use it to refactor my higher dimension code instead of
> templating the dimensionality.
> 
> It might have been better if I called it the Geometry Concepts Library,
> since the term template is too *ahem* generic.

I'll refrain on commenting on actual concept classes before I see
any real code. Seems like an interesting concept; pun intentional,
but I won't really know unless I see it and get to know the
pros and cons of such an approach. I still doubt the inheritance
approach, fwiw.

Regards,
-- 
Joel de Guzman
http://www.boost-consulting.com
http://spirit.sf.net