Re: [boost] [GTL] redesign checked into sandbox

From: Simonson, Lucanus J (lucanus.j.simonson_at_[hidden])
Date: 2008-05-08 13:25:41

John,

First, let me thank you for taking a look at the code in the sandbox.  I
have made great strides so far with the community's help.  Your input is
greatly appreciated.

John wrote:
>I am still a bit unsure about the 'concept' word that is being thrown
>around. ... The reason I mention this is that the point_concept.h file
has >no constraints, so it cant be used with BCCL, as far as I know.
>
>I dont know if I have a narrow opinion here, but this is what I am
>interested in even more than algorithms or actual models of
>'PointConcept' or whatever.

I think your interest is the same as that of the rest of the boost
community.  Whatever the library does, it has to do it the right way to
be considered for acceptance into boost.  I'm not entirely sure I
understand what you mean by point_concept.h has no constraints on the
point data type.  It references a point_traits<T>::coordinate_type.  Any
data type that does not provide a typedef to coordinate_type, or
specialize point_traits<> with a typedef for coordinate_type will not be
allowed to compile with the point concept.  Similarly there are the
point_traits<T>::get() and set() functions, which must either work with
the given data type, or be specialized to work with the given data type.
Are these not constraints on T?  I suppose I could have named
point_traits as point_concept_map instead to be a little more explicit
about it.  Would that name change make things more clear?  I am
restricting myself from making explicit requirements of the user data
type (except that it have a default constructor) and instead use the
concept mapping traits struct for all interaction with the data type.
In this way, all data types defined before the library was written and
can still be adapted to work with it without being modified to conform
to its expectations.  

You do raise a valid point, there is currently no concept checking
included in the design and implementation I checked into the sandbox.
Is it valid to call something a concept if there is no concept checking?
I think so, but I could be taking too broad a view.  Once the design is
finalized and implementation is mostly completed I was planning on
adding some concept checking, but in fact, the only benefit of such
checking is earlier and less verbose compiler errors when incorrectly
using a template.  This is of little benefit to me while authoring the
library, and only marginally beneficial to the library user.  The error
they will get if they fail to specialize the traits for their legacy
point type is that their point doesn't provide a get() function, which
they can fix by providing one.  I was also planning on translating the
library to use the new c++0x language features once available, so it is
my intention to use concepts, even if I'm not now technically doing so
if that implies compile time concept checking when taking a narrow view
of concepts.

Thanks again,
Luke