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

From: Simonson, Lucanus J (lucanus.j.simonson_at_[hidden])
Date: 2008-05-09 18:50:10

Bruno, I'm happy to hear from you again!

Luke wrote:
>> 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?

Bruno wrote:
>Yes it is. But in my opinion, showing up a concept class has the
>advantage of clearly communicating the intention to the community in
>order to validate / invalidate the design. Moreover, since two
>geometry-related libraries are currently being developed for Boost
>(even if they don't do the same things) I think comparing the concepts
>used would allow us to see exactly what are the convergences /
>divergences, and see what can or cannot be done to make them as close
>as possible. A certain level of consistency between those libraries
>would surely be appreciated.

In fact I am thinking much more along these lines than you may realize.
Given my proposed operator syntax for so-called Boolean operations I
could fold the arbitrary angle geometry provided by Berend's library
into mine (or visa-vera.)

manhattan + manhattan => manhattan result type by way of manhattan
algorithm
manhattan + 45-degree => 45-degree result type by way of 45 degree
algorithm
manhattan/45-degree + arbitrary angle => arbitrary angle result by way
of arbitrary angle algorithm

with all the concept checking and tag dispatching taken care of by the
API to select the correct algorithms and return types for the given
input arguments and operations.

Whether that arbitrary angle algorithm comes from Barend's library or
the geos library (C++ port of the famous JKT java geometry library)
seems like an open question to me.  Geos is attractive as an alternative
to cgal for those of us who cannot stomach cgal's qpl license.  geos'
lgpl is more restrictive than boost license, but I think we could
provide a generic framework for plugging in lgpl'd algorithms to my API
at link time to integrate the two.  It could then plug in cgal
algorithms for that matter, provided that the person doing the linking
was allowed to use them (paid for the privledge or is academic or
whatever.)  This whole issue becomes complex since there are many
libraries that do similar things to Barend's.  The last open source
library that did manhattan geometry operations was the fang library
written in 1980 in C.  It is next to worthless now that we've come so
far with algorithms and data structures (and C++).

Bruno wrote:
>Barend and me have written the following point concept (it's obviously
>open to criticism):
>
>template <class X>
>struct Point
>{
>    typedef typename point_traits<X>::coordinate_type ctype;
>    enum { ccount = point_traits<X>::coordinate_count };
>
>    template <class P, int I, int Count>
>    struct dimension_checker
>    {
>        static void check()
>        {
>            const P* point;
>            ctype coord = point_traits<X>::template get<I>(*point);
>            P* point2;
>            point_traits<X>::template get<I>(*point2) = coord;
>
>            dimension_checker<P, I+1, Count>::check();
>        }
>    };
>
>    template <class P, int Count>
>    struct dimension_checker<P, Count, Count>
>    {
>        static void check() {}
>    };
>
>    BOOST_CONCEPT_USAGE(Point)
>    {
>        dimension_checker<X, 0, ccount>::check();
>    }
>};
>
>It actually forwards everything to the point_traits class in order to
>check that everything needed is accessible through point traits for
>the point type begin checked. Since you rely on point traits too, I
>suppose you would have the same approach?

Yes, my own is very similar to what you show, except that I think
n-dimensional point classes are pointless exercise, if you'll excuse the
bad pun.  What exactly is the benefit of making the order of the point
data type generic?  Are we saving typing in the library by merging the
2D and 3D point concepts?  Do we pay a penalty for that?  In your case
you may not be paying a penalty because you are using compile time
integer to index the point.  You also provide compile time checking to
make source the index is valid, I see, which is good.

In my case, I have the rich language of isotropy that performs runtime
indexing.  There are separate index types for 2 and 3d geometry and type
safety prevents an invalid 3d index from being used with a 2d type.  The
language of isotropy provides a different kind of abstraction than what
you are doing abstracting away the order of the point.  The question
that leaves us with is which abstraction is more valuable to the user,
since they are mutually exclusive.  Isotropy is quite valuable to the
user, and we get very good results (in terms of code quality and
productivity) using it.  I doubt the user will parameterize the order of
their own code, so the benefit of doing so in your library will be
confined to the internal implementation of the library itself, unless I
am mistaken.

Bruno wrote:
>If you don't want to do that right now because you're afraid about the
>profusion of concept checking macros in your code, I think that
>putting a BOOST_CONCEPT_ASSERT in the point_traits class is sufficient
>with this approach, since any access to a point should be performed
>only through this class. This way, you don't have to rewrite the check
>in every algorithm, and the only job you have to do is writing the
>concept class. However, as I'm not used yet with the BCCL, I can be
>wrong...?

I don't know.  I was deferring adding the checks until the design is
finished, since they would change as the design changes.  Also, my
point_concept is a little more overloaded than yours might be.  I use
the concept type as a tag for tag dispatching purposes.  I also use it
as a sort-of namespace for holding all the functions related to the
point concept.  I pass it as a template parameter to select which
concept to apply and I return it as the result of a meta function call
to deduce the concept type for a given user type.  It is therefore much
more than a traditional "minimal" concept such as in the stl.  Moreover,
I want to allow partial modeling of the concept, for instance, if a data
type doesn't provide a default constructor, or even allow modification
of it's data through the traits it should still be allowed to work as a
read-only geometry type when those services are not needed.  It is,
therefore, improper to check that the data type conforms to the full
requirements of the concept, when in fact, it is not required for the
specific concept function being instantated.  For this the compiler
errors themselves provide the right level of protection, and the concept
check would simply provide a more concise error (which doesn't benefit
me since I have no problem reading the verbose template errors.)  I
would add it only at the end for the benefit of the library user.

Thanks,
Luke