[Review] GGL review starts today, November 5th

[Hartmut Kaiser]

Hi all,

The formal review of the Generic Geometry Library (GGL) starts today,
November 5, 2009 and will finish November 15, 2009.
GGL is being developed by Barend Gehrels, Bruno Lalande and Mateusz Loskot,
with substantial input from this Boost mailing list.

------------------------------------------------

About the library:

GGL defines concepts for geometries and implements some algorithms on such
geometries.

GGL is header-only, and can be applied in all software where geometry plays
a small or a larger role. Users of the library can use just only one
function, such as distance:

    int a[2] = {1,1};
    int b[2] = {2,3};
    double d = ggl::distance(a, b);

Library users can also use the library in combination with std::vector,
boost::tuple's and boost::ranges, such as:

    std::vector<boost::tuple<double, double, double> > line;
    line.push_back(boost::make_tuple(1, 2, 3));
    line.push_back(boost::make_tuple(4, 5, 6));
    line.push_back(boost::make_tuple(7, 8, 9));
    double length = ggl::length(line);

GGL can also be used in combination with custom or legacy geometries,
adapting them to the library specializing traits classes or using
registration macro's.

Formally, GGL contains a dimension-agnostic, coordinate-system-agnostic and
scalable kernel, based on concepts, meta-functions and
tag-dispatching. On top of that kernel, algorithms are built: area, length,
perimeter, centroid, convex hull, intersection (clipping),
within (point in polygon), distance, envelope (bounding box), simplify,
transform, convert, and more. The library is also designed to support high
precision arithmetic numbers, such as GMP.

The GGL might be used in all domains where geometry plays a role: mapping
and GIS, gaming, computer graphics and widgets, robotics,
astronomy... The core is designed to be as generic as possible and support
those domains. However, for now the development has been mostly
GIS-oriented.

The GGL team proposes an extension model, very similar to what is used by
GIL.

The proposal as it is in the Boost Sandbox included three extensions:
- SVG because it is used in the samples and to generate the documentation
- WKT because it is used in the tests
- The geographic coordinate system because it is used in some of the
  examples, also showing how other coordinate systems can be implemented

There are more extensions, not included now, a.o.:
- Spatial index
- Map projections

The proposed GGL has seen four previews, many discussions and many changes
in design and implementation, based on those discussions.
Previews were published on this list January '08, March'08, October'08 and
February'09.

GGL can be found in the sandbox
https://svn.boost.org/svn/boost/sandbox/ggl/formal_review, including source
code, examples, unit tests and documentation. Documentation can also be
found online: http://geometrylibrary.geodan.nl/formal_review

-------------------------------------------------------

Everybody on this list is invited to participate in this formal review. I
hope to see your review of this library, including your vote, and I welcome
your participation in the discussions on the Boost mailing list.

Please always state in your review, whether you think the library should be
accepted as a Boost library.

Additionally, please consider giving feedback on the following general
topics:

- What is your evaluation of the design?
- What is your evaluation of the implementation?
- What is your evaluation of the documentation?
- What is your evaluation of the potential usefulness of the library?
- Did you try to use the library?  With what compiler?  Did you have any
problems?
- How much effort did you put into your evaluation? A glance? A quick
reading? In-depth study?
- Are you knowledgeable about the problem domain?

Regards Hartmut
Review Manager

-------------------
Meet me at BoostCon
http://boostcon.com



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Paul A. Bristow-2]

> -----Original Message-----
> From: boost-bounces@... [mailto:boost-bounces@...] On
Behalf Of
> Hartmut Kaiser
> Sent: Thursday, November 05, 2009 2:20 PM
> To: boost-announce@...; boost@...;
boost-users@...
> Subject: [boost] [Review] GGL review starts today, November 5th

> Please always state in your review, whether you think the library should be
accepted as a Boost library.

Yes.

It is mature, refined, has a user base (including a commercial product - a good
sign), and is well documented.

(Although Boost has recently accepted another somewhat similar library, I have
no hesitation in recommending accepting both.  They are sufficiently orthogonal
- one very generic, one problem focussed.  Users can decide which suits them
best.)
 
> Feedback on the following general topics:
 
> - What is your evaluation of the design?

Generic.  Extendable.

> - What is your evaluation of the implementation?

Looks nice.  (And this usually indicates quality code!). Test package looks
plausible.

> - What is your evaluation of the documentation?

Excellent. Looks very nice. Only an index is missing - but extensive
Doxygenation including Doxygen comments are far above what passes for
documentation in many packages.

There are many fine examples.

I noted that only VS 2008 Express edition was mentioned.  I feel sure that
someone has used the 'Standard' version with full optimisation. And perhaps the
VS 2010 beta?  The latter may be especially useful if it overcomes the
difficulty Intellisense has in handling such a complex package without its
intelligence circuits melting ;-)

> - What is your evaluation of the potential usefulness of the library?

Invaluable in many problem domains.

> - Did you try to use the library?  No.

> - How much effort did you put into your evaluation?

 A quick read of documentation and glance at examples.

> - Are you knowledgeable about the problem domain?

Negligibly.

Paul

---
Paul A. Bristow
Prizet Farmhouse
Kendal, UK   LA8 8AB
[phone], mobile [phone]
pbristow@...







_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Barend Gehrels]

Hi Paul,

Thanks for reviewing, and for your positive reactions on our library.


> I noted that only VS 2008 Express edition was mentioned.  I feel sure that
> someone has used the 'Standard' version with full optimisation. And perhaps the
> VS 2010 beta?  The latter may be especially useful if it overcomes the
> difficulty Intellisense has in handling such a complex package without its
> intelligence circuits melting ;-)
>  
Yes, until now we only used VS 2005 and 2008 (both Express) (besides
gcc). I'll ask around for other versions as well, and try 2010.
If anyone on this list tries, feedback is welcome.

Regards, Barend



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Vicente Botet Escriba]

Hi,
this is not a review.

Note that I have just read the introduction of the documentation and I find the it quite clear.

Some words about SNIFAE and partial specialization:
At the end of the introduction you say that

>This SFINAE:
>* can be done on functions but not on structs (meta-functions). So the coordinate_type meta-function would still have to use tag dispatching"

First for structs (meta-functions) you can apply partial template specialization, so no need of SFINAE. Even if you neded SFINAE, and if I'm not wrong enable_if can also be applied to structs. From enable_if docummentation "
Enabling template class specializations
Class template specializations can be enabled or disabled with enable_if. One extra template parameter needs to be added for the enabler expressions. This parameter has the default value void. For example:
template <class T, class Enable = void>
class A { ... };

template <class T>
class A<T, typename enable_if<is_integral<T> >::type> { ... };

template <class T>
class A<T, typename enable_if<is_float<T> >::type> { ... };"
>*gives often compiler troubles and headaches: if a user makes an error somewhere, the compiler will not select any of the methods, and/or it will give completely incomprehensible error listings, just because of this SFINAE"

I thought that this was and advantage not a liability. The message is short: method not found.
What errors do you get when a user makes an error somewhere with tag dispatching? Are they clearer?

> * does not support partial specializations because it is a function. The tag-dispatching function is of course also not supporting that, but it forwards its call to the dispatch struct where partial specializations (and member template functions) are possible. The SFINAE could do that as well but then: why not just add one tag more and have tag dispatching instead?"

Could you clarify which is the tag you add?

> * is a trick to deceive the compiler. "As a language behavior it was designed to avoid programs becoming ill-formed" (http://en.wikipedia.org/wiki/Substitution_failure_is_not_an_error), while tag dispatching is based on specialization, a core feature of C++
>* looks more ugly

You know that this is a matter of taste, and the way you do force the user to share your taste.

> *is simply not necessary because we have tag dispatching :-)

Not necessary do not meens that it is not good.

Recently I have added some stuff to take care of ADL in the Boost.Conversion library base on the Boost.Swap library. The idea been to define a function that calls an internal function introdicing the default behavior by ADL. Thus when the user has provided some functions found by ADL they will take precedence as more specific. When not found the introduced default behavion take place.

Next follows how I have defined convert_to:

namespace boost {
    // trick to ensure specialization is always possible
    namespace dummy {
        template <typename T> struct base_tag {};
        template <typename T> struct type_tag : public base_tag<T> {};
    }
    // default behavior ussin gthe specialized tag type_tag
    namespace conversion {
        namespace partial_specialization_workaround {
            template < typename To, typename From >
            struct convert_to {
                inline static To apply(const From& val)
                {
                    return To(val);
                }
            };
        }
       
        template < typename To, typename From >
        To convert_to(const From& val, dummy::type_tag<To> const&) {
            return conversion::partial_specialization_workaround::convert_to<To,From>::apply(val);
        }
    }
    // specialized implementation
    namespace conversion_impl {
            template <typename Target, typename Source>
            Target convert_to_impl(Source const& from) {
                using namespace boost::conversion;
                //use boost::conversion::convert_to if ADL fails
                return convert_to(from, boost::dummy::type_tag<Target>());
            }
    }
    // generic function calling to the ADL introduction
    template <typename Target, typename Source>
    Target convert_to(Source const& from, boost::dummy::base_tag<Target> const& p=boost::dummy::base_tag<Target>()) {
        return conversion_impl::convert_to_impl<Target>(from);
    }
}

Note that using the dummy trick we ensure that there are no infinite cycles.
The default behavior could correspond to what you have already done.

If there is nothing wrong on my design, do you think that this could be also applied to the GGL library at least for the concepts?

Good work anyway :)

Best,
Vicente



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Rutger ter Borg-2]

Hartmut Kaiser wrote:
>
> Everybody on this list is invited to participate in this formal review. I
> hope to see your review of this library, including your vote, and I
> welcome your participation in the discussions on the Boost mailing list.
>

Hello,

without doing a full review, I have a question.

In GGL, coordinate systems are assigned to points. However, one can compute
stuff like length, angle, area, etc., with having only a proper inner
product operator, without necessarily attaching that operator to each
point.
It then becomes easy to project some data in different spaces, and still
being able run a quick hull. Think of geometric interpretations of non-
coordinate data such as dictionaries, medical images, etc..

So, my question would be: is it that generic to assume that all points
have a coordinate system?

Cheers,

Rutger


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Barend Gehrels]

Hi Vicente,


Thanks for diving into our library.


> Note that I have just read the introduction of the documentation and I find the it quite clear.
>  

Good to hear.

> Some words about SNIFAE and partial specialization:
>  
I've no problem to rephrase the documentation-section about SFINAE or
even to omit it. The section documents our choice for tag dispatching,
but it might be not necessary to do it in this detail. I've also no
problems with SFINAE in general, it is just a preference for usage in
more complex libraries like GGL.

We've used SFINAE in the past, for about half a year, in GGL. However,
we did have much problems with it, getting it all right and compiling it
on all compilers. We especially did have troubles with the boost concept
checking in combination with sfinae (maybe I should add that). Dave
Abrahams wrote about this (I quote here from a mail in january 2009):

>
> > Barend: (...) This works perfectly and distinguishes all geometry types at compile
> > time, as long as the library or the developer provides the meta function
> > geometry_type<T>::type which is currently implemented as an enumeration
> > of TYPE_POINT, etc.
>  
>
> Dave: Seems like you might be better off using tag dispatching...
We went over to tag dispatching and all those problems disappeared.

Maybe I should add (if the section is not going to be omitted) that the
combination of SFINAE and the BCCL using boost-concept-requires was
quite difficult. I Just rechecked  some things and I think this still is
the case. I checked using a small source with things as "apple", "pear",
"banana", so you'll see them in my answers.

> [snipped] Even if you neded SFINAE, and if I'm not wrong enable_if can also be applied to structs. From enable_if docummentation "
> Enabling template class specializations
> Class template specializations can be enabled or disabled with enable_if. One extra template parameter needs to be added for the enabler expressions. This parameter has the default value void. For example:
> template <class T, class Enable = void>
> class A { ... };
>
> template <class T>
> class A<T, typename enable_if<is_integral<T> >::type> { ... };
>
> template <class T>
> class A<T, typename enable_if<is_float<T> >::type> { ... };"
>  

That is indeed possible, just tried it with enable_if.

But, technically speaking, I don't think this is SFINAE. I think it is
partial specialization, and specialization is done here on
enable_if<...>::type, finding matching candidates and if no one is
found, using the unspecialized class. We don't have the real
"Substitution Failure" here, where one or more overloads are discarded
from the candidate set based on failing substitution.

So these classes with enable_if work about the same way as tag
dispatching does, though no tag is necessary. But also here I prefer tag
dispatching because (my personal opinion) I find it resulting in more
readable code.


>> *gives often compiler troubles and headaches: if a user makes an error somewhere, the compiler will not select any of the methods, and/or it will give completely incomprehensible error listings, just because of this SFINAE"
>>    
>
> I thought that this was and advantage not a liability. The message is short: method not found.
> What errors do you get when a user makes an error somewhere with tag dispatching? Are they clearer?
>  
The messages you get depend on the type or error, in both cases.

When I try to use a function based on sfinae, when there is no match,
is: the message I get
- from MSVC is: Failed to specialize function template..., for all
overloads.
- from gcc is: no matching function for call to.... (one)

On tag dispatching you'll get:
MSVC: 'type' : is not a member of 'tag<T>' with [T=banana]
gcc, similar

or (if the banana-tag is implemented)

MSVC: 'apply' : is not a member of 'dispatch<T>' with [T=tag<banana>::type]
gcc:  'apply' is not a member of 'dispatch<banana_tag>'

sfinae is based on overloads, and the problem I encountered with it (and
with its messages) that in case of errors I often don't understand where
the error originates from. I remember having to number several times all
overloads (of e.g. "eat") to e.g. eat1, eat2, eat3, etc, to see what is
actually going wrong and why the overload was not called in that
specific case.

With tag dispatching you can also get pages of messages, but it is more
clear where they come from, e.g. a missing specialization, a wrong input
type.


>  
>> * does not support partial specializations because it is a function. The tag-dispatching function is of course also not supporting that, but it forwards its call to the dispatch struct where partial specializations (and member template functions) are possible. The SFINAE could do that as well but then: why not just add one tag more and have tag dispatching instead?"
>>    
>
> Could you clarify which is the tag you add?
>  

If I understand your question: we're adding a geometry-tag. So for a
point it specializes to point_tag, etc.

What is meant by this section is that for some cases, code is similar.
For example the "num_points" algorithm, the number of points of a
linestring is the same as the number of points of a linear ring. The
dispatch function can specialize partially on this similarity. I now
realize, by just doing some re-checking that for SFINAE you can do the
same, using SFINAE on a specific property to define an overload which
applies to more than one geometry.

So this sentence probably can go, it is possible in both cases.

>  
>> * is a trick to deceive the compiler. "As a language behavior it was designed to avoid programs becoming ill-formed" (http://en.wikipedia.org/wiki/Substitution_failure_is_not_an_error), while tag dispatching is based on specialization, a core feature of C++
>> * looks more ugly
>>    
>
> You know that this is a matter of taste, and the way you do force the user to share your taste.
>  
I can rephrase this. What I mean is that a function

template <typename T>
void eat(T const& fruit)
{
    // tag dispatch on apple-tag
}

looks better than:

template <typename T>
void eat(T const& fruit
#ifdef DOXYGEN_SHOULD_SKIP_THIS
    , typename boost::enable_if<typename is_apple<T>::type>::type* = NULL
#endif
    )
{
    // (call) apple implementation
}

Maybe I should state "makes the main free function declarations shorter"
to be more objective.


>  
>> *is simply not necessary because we have tag dispatching :-)
>>    
>
> Not necessary do not meens that it is not good.
>  
Right, I agree.

I still find (but that is an opinion indeed) that using tag dispatching
results in clean and readable code, and cause less compiler troubles.
Besides that, as far as I can tell, in combination with  
BOOST_CONCEPT_REQUIRES, a solution based on SFINAE alone is not possible
using SFINAE. This set does not compile:
template <typename T>
BOOST_CONCEPT_REQUIRES(  ((concept::Apple<T> )), (void) )
eat(T const& fruit, typename boost::enable_if<typename
is_apple<T>::type>::type* = NULL)
{...}

template <typename T>
BOOST_CONCEPT_REQUIRES(  ((concept::Pear<T> )), (void) )
eat(T const& fruit, typename boost::enable_if<typename
is_pear<T>::type>::type* = NULL)
{...}

With messages: 'sourness' : is not a member of 'pear' or in gcc: no type
named 'sourness' in struct pear
But the expected type "sourness" was defined for apple, in this case,
and checked by the apple concept... the code IS right.... Combinations
are listed in the errors (so apple/pear, pear/apple), if we add more
fruit we would get much more.


Using tag dispatching, it is not possible to phrase it like this,
because there is only one free function, we cannot check the Apple
concept here. But concepts can be dispatched as well, resulting in:
template <typename T>
BOOST_CONCEPT_REQUIRES(  (( dispatched_concept<typename tag<T>::type, T>
)), (void) )
eat(T const& fruit)
{...}

and this compiles.

Tag dispatching of the concept, or a solution using enable_if in a
struct, can also be used in the SFINAE solution but... then it is not
pure SFINAE (if I'm right), it is (at least partly) based on tag
dispatching or other partial specializations. But OK, you can combine
SFINAE and tags, of course that is possible.

By the way, we're currently using BOOST_CONCEPT_ASSERT (where concept
checking is dispatched), but as found out here, we have the choice



> [snipped] Do you think that this could be also applied to the GGL library at least for the concepts?
>  
Interesting, I'll react on the convert_to in another e-mail later.


Regards, Barend


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Barend Gehrels]

Hi Rutger,

> In GGL, coordinate systems are assigned to points. However, one can compute
> stuff like length, angle, area, etc., with having only a proper inner
> product operator, without necessarily attaching that operator to each
> point.
> It then becomes easy to project some data in different spaces, and still
> being able run a quick hull. Think of geometric interpretations of non-
> coordinate data such as dictionaries, medical images, etc..
>
> So, my question would be: is it that generic to assume that all points
> have a coordinate system?
>  

We've implemented the hull as an "agnostic" strategy because it is not
dependant on coordinate system itself. It is however dependant on two
underlying strategies, "side" and "compare". So in cartesian coordinate
systems the "side" is implemented differently from how it would be
implemented in a spherical coordinate system. Same for compare
(spherical compare assumes that the coordinates do not span more than
halve of the sphere).

So yes, for points we need to know in which coordinate system they are
placed, in order to get the calculation strategy. Note that the
point-type does not have to have one, but the Point Concept. So using a
traits class you can bind a coordinate system to a point type.

So if you define a "dictionary coordinate space" where the "side" is
probably still as defined as it is now for cartesian in the library (it
can just register the same calculation class), you can call the convex
hull for it.


If that answers your question...

Regards, Barend



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Vicente Botet Escriba]

Hi,
----- Original Message -----
From: "Barend Gehrels" <barend@...>
To: <boost@...>
Sent: Sunday, November 08, 2009 2:34 PM
Subject: Re: [boost] [Review] GGL review starts today, November 5th


>
> Hi Vicente,
>
>
> Thanks for diving into our library.

You are welcome.
 

>> Note that I have just read the introduction of the documentation and I find the it quite clear.
>>  
>
> Good to hear.
>
>> Some words about SNIFAE and partial specialization:
>>  
> I've no problem to rephrase the documentation-section about SFINAE or
> even to omit it. The section documents our choice for tag dispatching,
> but it might be not necessary to do it in this detail. I've also no
> problems with SFINAE in general, it is just a preference for usage in
> more complex libraries like GGL.
>
> We've used SFINAE in the past, for about half a year, in GGL. However,
> we did have much problems with it, getting it all right and compiling it
> on all compilers. We especially did have troubles with the boost concept
> checking in combination with sfinae (maybe I should add that). Dave
> Abrahams wrote about this (I quote here from a mail in january 2009):
>
>>
>> > Barend: (...) This works perfectly and distinguishes all geometry types at compile
>> > time, as long as the library or the developer provides the meta function
>> > geometry_type<T>::type which is currently implemented as an enumeration
>> > of TYPE_POINT, etc.
>>  
>>
>> Dave: Seems like you might be better off using tag dispatching...
> We went over to tag dispatching and all those problems disappeared.
>
> Maybe I should add (if the section is not going to be omitted) that the
> combination of SFINAE and the BCCL using boost-concept-requires was
> quite difficult. I Just rechecked  some things and I think this still is
> the case. I checked using a small source with things as "apple", "pear",
> "banana", so you'll see them in my answers.

If there is a clear justification that SFINAE and BCCL do not matches, his should be added in the rationale. But don't we use SFINAE to support concepts? I don't see the need to combine them. Remember that there was a Concept Traits library that was intendedd to replace the BCCL. The library was abandoned because C++0x should include concepts and because some concepts couldn't be managed by traits. Maybe this library should be relaunched as Concepts are not part of C++0x now.
 

>> [snipped] Even if you neded SFINAE, and if I'm not wrong enable_if can also be applied to structs. From enable_if docummentation "
>> Enabling template class specializations
>> Class template specializations can be enabled or disabled with enable_if. One extra template parameter needs to be added for the enabler expressions. This parameter has the default value void. For example:
>> template <class T, class Enable = void>
>> class A { ... };
>>
>> template <class T>
>> class A<T, typename enable_if<is_integral<T> >::type> { ... };
>>
>> template <class T>
>> class A<T, typename enable_if<is_float<T> >::type> { ... };"
>>  
>
> That is indeed possible, just tried it with enable_if.
>
> But, technically speaking, I don't think this is SFINAE. I think it is
> partial specialization, and specialization is done here on
> enable_if<...>::type, finding matching candidates and if no one is
> found, using the unspecialized class. We don't have the real
> "Substitution Failure" here, where one or more overloads are discarded
> from the candidate set based on failing substitution.
>
> So these classes with enable_if work about the same way as tag
> dispatching does, though no tag is necessary. But also here I prefer tag
> dispatching because (my personal opinion) I find it resulting in more
> readable code.
>
>
>>> *gives often compiler troubles and headaches: if a user makes an error somewhere, the compiler will not select any of the methods, and/or it will give completely incomprehensible error listings, just because of this SFINAE"
>>>    
>>
>> I thought that this was and advantage not a liability. The message is short: method not found.
>> What errors do you get when a user makes an error somewhere with tag dispatching? Are they clearer?
>>  
> The messages you get depend on the type or error, in both cases.
>
> When I try to use a function based on sfinae, when there is no match,
> is: the message I get
> - from MSVC is: Failed to specialize function template..., for all
> overloads.
> - from gcc is: no matching function for call to.... (one)
>
> On tag dispatching you'll get:
> MSVC: 'type' : is not a member of 'tag<T>' with [T=banana]
> gcc, similar
>
> or (if the banana-tag is implemented)
>
> MSVC: 'apply' : is not a member of 'dispatch<T>' with [T=tag<banana>::type]
> gcc:  'apply' is not a member of 'dispatch<banana_tag>'

This message could be clear to you, but what the user is intendeed to do to correct the error?
 

> sfinae is based on overloads, and the problem I encountered with it (and
> with its messages) that in case of errors I often don't understand where
> the error originates from. I remember having to number several times all
> overloads (of e.g. "eat") to e.g. eat1, eat2, eat3, etc, to see what is
> actually going wrong and why the overload was not called in that
> specific case.
>
> With tag dispatching you can also get pages of messages, but it is more
> clear where they come from, e.g. a missing specialization, a wrong input
> type.
>
>
>>  
>>> * does not support partial specializations because it is a function. The tag-dispatching function is of course also not supporting that, but it forwards its call to the dispatch struct where partial specializations (and member template functions) are possible. The SFINAE could do that as well but then: why not just add one tag more and have tag dispatching instead?"
>>>    
>>
>> Could you clarify which is the tag you add?
>>  
>
> If I understand your question: we're adding a geometry-tag. So for a
> point it specializes to point_tag, etc.
>
> What is meant by this section is that for some cases, code is similar.
> For example the "num_points" algorithm, the number of points of a
> linestring is the same as the number of points of a linear ring. The
> dispatch function can specialize partially on this similarity. I now
> realize, by just doing some re-checking that for SFINAE you can do the
> same, using SFINAE on a specific property to define an overload which
> applies to more than one geometry.
>
> So this sentence probably can go, it is possible in both cases.

I agree.
 

>>  
>>> * is a trick to deceive the compiler. "As a language behavior it was designed to avoid programs becoming ill-formed" (http://en.wikipedia.org/wiki/Substitution_failure_is_not_an_error), while tag dispatching is based on specialization, a core feature of C++
>>> * looks more ugly
>>>    
>>
>> You know that this is a matter of taste, and the way you do force the user to share your taste.
>>  
> I can rephrase this. What I mean is that a function
>
> template <typename T>
> void eat(T const& fruit)
> {
>    // tag dispatch on apple-tag
> }
>
> looks better than:
>
> template <typename T>
> void eat(T const& fruit
> #ifdef DOXYGEN_SHOULD_SKIP_THIS
>    , typename boost::enable_if<typename is_apple<T>::type>::type* = NULL
> #endif
>    )
> {
>    // (call) apple implementation
> }

Why the user can not define eat on the namespace the apple class is defined

namespace apple_ns {
    void eat(apple const& fruit)
    {
        // do apple implementation
    }
}
 
Do you see a problem with this approach?

> Maybe I should state "makes the main free function declarations shorter"
> to be more objective.

[snipped]

>> [snipped] Do you think that this could be also applied to the GGL library at least for the concepts?
>>  
> Interesting, I'll react on the convert_to in another e-mail later.

Happy to hear,
Vicente


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Joel Falcou-3]

vicente.botet wrote:
> If there is a clear justification that SFINAE and BCCL do not matches, his should be added in the rationale. But don't we use SFINAE to support concepts? I don't see the need to combine them. Remember that there was a Concept Traits library that was intendedd to replace the BCCL. The library was abandoned because C++0x should include concepts and because some concepts couldn't be managed by traits. Maybe this library should be relaunched as Concepts are not part of C++0x now.
>  
I'm really fond of this idea. What's the current status of the Concept
Traits library tough and where are the source file located ?


--
___________________________________________
Joel Falcou - Assistant Professor
PARALL Team - LRI - Universite Paris Sud XI
Tel : [phone]


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Vicente Botet Escriba]

Hi,
----- Original Message -----
From: "joel" <joel.falcou@...>
To: <boost@...>
Sent: Sunday, November 08, 2009 4:06 PM
Subject: [boost] Ressurecting BCCL (was GGL review)


>
> vicente.botet wrote:
>> If there is a clear justification that SFINAE and BCCL do not matches, his should be added in the rationale. But don't we use SFINAE to support concepts? I don't see the need to combine them. Remember that there was a Concept Traits library that was intendedd to replace the BCCL. The library was abandoned because C++0x should include concepts and because some concepts couldn't be managed by traits. Maybe this library should be relaunched as Concepts are not part of C++0x now.
>>  
> I'm really fond of this idea. What's the current status of the Concept
> Traits library tough and where are the source file located ?

You can as always see the LibrariesUnderConstruction wiki page. I try to maintain here all the libraries related to Boost.

https://svn.boost.org/trac/boost/wiki/LibrariesUnderConstruction#Boost.ConceptTraits

Best,
Vicente


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Mateusz Loskot]

Barend Gehrels wrote:

> Hi Paul,
>
> Thanks for reviewing, and for your positive reactions on our library.
>
>
>> I noted that only VS 2008 Express edition was mentioned.  I feel sure
>> that
>> someone has used the 'Standard' version with full optimisation. And
>> perhaps the
>> VS 2010 beta?  The latter may be especially useful if it overcomes the
>> difficulty Intellisense has in handling such a complex package without
>> its
>> intelligence circuits melting ;-)
>  
> Yes, until now we only used VS 2005 and 2008 (both Express) (besides
> gcc). I'll ask around for other versions as well, and try 2010.
> If anyone on this list tries, feedback is welcome.

Barend,

With GGL, I use Visual C++ compiler from Visual Studio 2005 Professional.
I have also access to Visual Studio Team System 2008
and I build GGL using it from time to time.

Actually, I would expect that GGL builds fine using
Visual C++ 8.0 or later. I would not be surprised if it builds with
Visual C++ 7.1 too. However, I doubt it can compile using 7.0 or earlier.

Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Barend Gehrels]

Hi,

> If there is a clear justification that SFINAE and BCCL do not matches, his should be added in the rationale. But don't we use SFINAE to support concepts? I don't see the need to combine them. Remember that there was a Concept Traits library that was intendedd to replace the BCCL. The library was abandoned because C++0x should include concepts and because some concepts couldn't be managed by traits. Maybe this library should be relaunched as Concepts are not part of C++0x now.
>  
I agree that it is very good to consider it to be relaunched.  But I
don't know the details of that library.

However, we currently have to use (or at least, I was encouraged to use)
BCCL. I don't state that there is no way to combine it with SFINAE-based
code. I explained that the BOOST_CONCEPT_REQUIRES is not working with
SFINAE overloads.
It can be added in the rationale.

That BCCL is using SFINAE internally (I didn't know) is no problem for
me, it is a different subject.

>>>  
>>>      
>> The messages you get depend on the type or error, in both cases.
>>
>> When I try to use a function based on sfinae, when there is no match,
>> is: the message I get
>> - from MSVC is: Failed to specialize function template..., for all
>> overloads.
>> - from gcc is: no matching function for call to.... (one)
>>
>> On tag dispatching you'll get:
>> MSVC: 'type' : is not a member of 'tag<T>' with [T=banana]
>> gcc, similar
>>
>> or (if the banana-tag is implemented)
>>
>> MSVC: 'apply' : is not a member of 'dispatch<T>' with [T=tag<banana>::type]
>> gcc:  'apply' is not a member of 'dispatch<banana_tag>'
>>    
>
> This message could be clear to you, but what the user is intendeed to do to correct the error?
>  

Messages originating from template code are often difficult, I agree,
and if you know the library it is easier to solve them, I agree.

Let me try to state it differently.

With SFINAE the real error is hidden behind the phrase "Failed to
specialize". The compiler discards all overloads, because of an error
somewhere, and you get this error with no clue how to go on. What you
get is the error that it is just failing. All overloads are gone, the
compiler is not wrong, there is an error somewhere, but the only visible
error message which makes sense for the compiler to give is something
like "failed to specialize" or "no matching function call".

With tag dispatching you get the real error message. That can also be
difficult, but the message(s), sometimes a whole list, give at least a
clue of what's wrong. In this case: add the banana-tag or add an
implementation for banana. The usage of concepts should reduce the
length of the list and give a clearer error message.

So the essence is: /compiler errors in code based on tag dispatching are
easier to find than compiler errors in code based on SFINAE, because the
SFINAE-case is based on discarding overloads and *meaningful error
messages are discarded as well*./

>  
>  
>  
>> I can rephrase this. What I mean is that a function
>>
>> template <typename T>
>> void eat(T const& fruit)
>> {
>>    // tag dispatch on apple-tag
>> }
>>
>> looks better than:
>>
>> template <typename T>
>> void eat(T const& fruit
>> #ifdef DOXYGEN_SHOULD_SKIP_THIS
>>    , typename boost::enable_if<typename is_apple<T>::type>::type* = NULL
>> #endif
>>    )
>> {
>>    // (call) apple implementation
>> }
>>    
>
> Why the user can not define eat on the namespace the apple class is defined
>
> namespace apple_ns {
>     void eat(apple const& fruit)
>     {
>         // do apple implementation
>     }
> }
>  
> Do you see a problem with this approach?
>  

No, but I don't see the relation to tag dispatching vs. sfinae.


Regards, Barend

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Barend Gehrels]

Hi Vicente,

I promised to react on this part:

> Recently I have added some stuff to take care of ADL in the
> Boost.Conversion library base on the Boost.Swap library. The idea been
> to define a function that calls an internal function introdicing the
> default behavior by ADL. Thus when the user has provided some
> functions found by ADL they will take precedence as more specific.
> When not found the introduced default behavion take place.
>
> Next follows how I have defined convert_to:
>
> namespace boost {
>     // trick to ensure specialization is always possible
>     namespace dummy {
>         template <typename T> struct base_tag {};
>         template <typename T> struct type_tag : public base_tag<T> {};
>     }
>     // default behavior ussin gthe specialized tag type_tag    
> namespace conversion {
>         namespace partial_specialization_workaround {
>             template < typename To, typename From >
>             struct convert_to {
>                 inline static To apply(const From& val)
>                 {
>                     return To(val);
>                 }
>             };
>         }
>                 template < typename To, typename From >
>         To convert_to(const From& val, dummy::type_tag<To> const&) {
>             return
> conversion::partial_specialization_workaround::convert_to<To,From>::apply(val);
>
>         }
>     }
>     // specialized implementation     namespace conversion_impl {
>             template <typename Target, typename Source>
>             Target convert_to_impl(Source const& from) {
>                 using namespace boost::conversion;
>                 //use boost::conversion::convert_to if ADL fails
>                 return convert_to(from,
> boost::dummy::type_tag<Target>());
>             }
>     }
>     // generic function calling to the ADL introduction
>     template <typename Target, typename Source>
>     Target convert_to(Source const& from,
> boost::dummy::base_tag<Target> const&
> p=boost::dummy::base_tag<Target>()) {
>         return conversion_impl::convert_to_impl<Target>(from);
>     }
> }
>
> Note that using the dummy trick we ensure that there are no infinite
> cycles. The default behavior could correspond to what you have already
> done.
>
> If there is nothing wrong on my design, do you think that this could
> be also applied to the GGL library at least for the concepts?
>
>  

I assume this does not have anything to do with SFINAE?

I like the idea of this conversion library and I think it is also
applicable to geometry. Actually we have a "convert" function which
converts e.g. a box to a polygon (so from min/max go to a polygon with
the points of the box). So if Boost has a generic convert_to function,
we're happy to support geometries there.

After reading your documentation I tried your code to my "fruit"
test-classes for sfinae/tag dispatching, and was able to convert apples
to pears. Tried it using two ways, one using the
partial_specialization_workaround, one overloading the convert_to with
the dummy-tag. Added namespace to check ADL and all is working nicely.

To refer to your question. "At least for the concepts", you probably
mean the geometry concepts. Adapting geometries to concepts is not done
using free functions. It is implemented using traits classes they should
be implemented in namespace ggl::traits.

If you refer to the algorithms, like area, yes, I think it could be done
like this in GGL, also combined with tag dispatching. But it is
currently not done like this. Example c04_a and c04_b show how
functionality can be overriden by specializing either the function or
(partly) specializing the dispatch structure. This is all in namespace
GGL. You're adding a possibility to be able to specialize in your own
namespace, and I think it would be feasable, though I'm not sure if it
is really expected.

Regards, Barend



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Simonson, Lucanus J]

Hartmut Kaiser wrote:
> The formal review of the Generic Geometry Library (GGL) starts today,
> November 5, 2009 and will finish November 15, 2009.
> GGL is being developed by Barend Gehrels, Bruno Lalande and Mateusz
> Loskot, with substantial input from this Boost mailing list.

This library looks like a very good example of generic interfaces for geometry objects and several well known and useful geometry algorithms.

This is not a review.

I found it difficult to answer my questions about the library based on the documentation.  I am having difficulty coming up with a complete list of features for the library.  It seems there is more implemented than documented.  Specifically, I'd like to know more about the ggl::algorithms::overlay namespace, which appears to contain algorithms of interest to me, but is not documented.

I'll ask my questions on the list to help me identify which header files I should look at to understand the interfaces and implementation of interesting algorithms in the GGL.

1. Does the library support other Boolean operations between pairs of polgyons than intersection?
        Union
        XOR
        AND NOT
2. If so, does the library support the union of more than two overlapping polygon simultaneously (three or more mutually overlapping polygons)?
3. Does the library support map overlay operations of two layers?  Of more than two layers simultaneously?
4. If the non-self-intersecting invariant is violated at the input of the polygon pair intersection algorithm what does the algorithm do?
5. Is there a way to check self-intersecting invariant before attempting an intersection operation?
6. Is there a way to fix a polygon that is self-intersecting to be non-self intersecting?
7. When intersection points are snapped to the floating point grid at the output of the polygon pair intersection algorithm edges may move laterally some small distance which may introduce self intersection artifacts.  How is this handled by the polygon intersection algorithm?
8. What is the algorithmic complexity of the polygon intersection algorithm?
9. Could you please provide the community with a description of the polygon intersection algorithm?
10. Is the polygon intersect bounding box algorithm linear time?
11. When a polygon is intersected against a bounding box the same problem can happen that self intersections are introduced in the output polygon(s) when intersection points are snapped to the floating point grid.  These artifacts cannot be addressed by a linear time algorithm.  Are the output polygons of the polygon intersects bounding box algorithm implemented by this library potentially self intersecting?
12. Is the distance algorithm implemented for linestring pairs?  For polygon pairs?  If so, what algorithmic complexity does it have, and can you describe the algorithm for the community?
13. Why is there no custom polygon example in the documentation?
14. Why do you need interior_type for the polygon concept traits?  What requirements does the interior_type need to satisfy?  Is it expected to be an stl container?
15. What happens if you instantiate the polygon pair intersection algorithm with integer coordinates?
16. What is required for a data type to satisfy the requirements of a coordinate type?
17. Can you tell us more about the support and usage of high precision numerical datatypes?

With enough time and effort reading the code and exercising it I can answer all of these questions for myself, but a little help from the library author would be greatly appreciated.  If the answers to some of my questions can be found in the documentation please let me know where.

It is unfortunate that Fernando's buisness success leaves him so little time recently--hopefully he will be able to conduct a review.  I think that as a CGAL author and user of both GPC and CGAL in his consulting work his review of the polygon intersection algorithm in GGL would be insightful.

Thanks,
Luke
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Barend Gehrels]

Hi Luke,

First, congratulations with the acceptance of your library.


> This library looks like a very good example of generic interfaces for geometry objects and several well known and useful geometry algorithms.
>  
> [questions snipped]


Thanks for your interest and reading our documentation.

You ask a lot and I'll answer a lot, but give me a day or two.

Regards, Barend




_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Joachim Faulhaber]

2009/11/5 Hartmut Kaiser <hartmut.kaiser@...>:
>
> Hi all,
>
> The formal review of the Generic Geometry Library (GGL) starts today,
> November 5, 2009 and will finish November 15, 2009.

Hi Barend,

I am currently reading your docs and I think your design is *very* good.
I will take more time to investigate the lib and send a review at the end
of the review period.

Thanks to you, Bruno and Mateusz for this contribution.
Joachim
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Barend Gehrels]

Hi Joachim,


> I am currently reading your docs and I think your design is *very* good.
>  
Thanks, good to hear.

> I will take more time to investigate the lib and send a review at the end
> of the review period.
>
>  
OK, perfect, looking forward to it.

Regards, Barend


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Thomas Klimpel]

Hi,
This is not yet a review. (There will be a real review, and I see no reasons why it should not be positive.)


1)

I wonder whether it would be possible to change the name "GGL" to "Boost.Geometry". Sure, it is no problem for the initialized to know what "GGL" can do, but the newcomer is just confronted with yet another acronym that tells him nothing.

I first thought that this change of name would disturb existing users of the library, but found out that they will have to change their code anyway:
using namespace ggl;
must be replaced with
using namespace boost::ggl;
and
#include <ggl/ggl.hpp>
must be replaced with
#include <boost/ggl/ggl.hpp>
after the library has been accepted into boost.

The same is true for the library itself, so the change from "ggl" to "boost::geometry" or "boost/geometry" is probably not more work than the change from "ggl" to "boost::ggl" and "boost/ggl"

Then I thought that the name GGL might be a reference to GIL. So I looked into the GIL library to find out why it emphasizes the "generic" part so much. It turned out that there is not a single best representation for images, and that GIL itself provides multiple different representations. This is a bit similar to STL that provides multiple containers, because there is not a single best container. GGL on the other hand provides just one point, linestring, linear_ring, polygon, box and segment class template, because the representation isn't really the challenge in the context of geometry. This is all perfect, but I just think that the "generic" in case of GGL refers to all the different "legacy" classes that essentially all use the same underlying representation of the geometry (point, box, ...), but are incompatible because of different names and conventions, whereas the generic in GIL and STL refers to fundamentally different representations of the underlying object that is
  unavoidable in principle.

The bottom line is that I think a real name should be preferred over an acronym if there is not a very good reason to use an acronym. I just tried to explain why I can't see this very good reason in this case.



2)

A second remark concerns the OGC names. Let's take the following code from 07_graph_route_example.cpp to illustrate:


    // Init a bounding box, lateron used to define SVG map
    ggl::box_2d box;
    ggl::assign_inverse(box);

    // Read the cities
    typedef boost::tuple<point_type, std::string, vertex_type> city_type;
    std::vector<city_type> cities;
    read_wkt<point_type>("data/cities.wkt", cities, box);

...

// Read an ASCII file containing WKT's, fill a vector of tuples
// The tuples consist of at least <0> a geometry and <1> an identifying string
template <typename Geometry, typename Tuple, typename Box>
void read_wkt(std::string const& filename, std::vector<Tuple>& tuples, Box& box)
{
...
 
               ggl::combine(box, ggl::make_envelope<Box>(geometry));
...
}


What does "ggl::assign_inverse" and "make_envelope" do? These are apparently OGC names, but I spend quite some time trying to verify that this is indeed the case. In fact, I just ended up accepting that this is probably indeed that case. These OGC names are OK, but ask yourself the question whether you would be able to understand the quoted code if you would not already know what "ggl::assign_inverse" and "make_envelope" do (I know it's easy to look it up in the documentation, but that is not the point). In fact, I will not tell you now, but I tried to be fair when quoting the source code, so as not to remove potentially clarifying comments or context.

The bottom line is that when the OGC conventions already force me to accept confusing names, it would at least be nice to know how I can verify that these are indeed OGC names. What are the reference documents I have to read to learn this?


Regards,
Thomas
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Mateusz Loskot]

Thomas Klimpel wrote:
> 1)
>
> I wonder whether it would be possible to change the name "GGL" to
> "Boost.Geometry".
 > [...]
> I first thought that this change of name would disturb existing users
>  of the library, but found out that they will have to change their
> code anyway:
> [...]

The layout of GGL source tree follows Boost convention.
In spite of that, you are right, users will likely have to update
their GGL-based source code

> Then I thought that the name GGL might be a reference to GIL.

That's how I personally refer to name GGL.

> GGL on the other hand provides just one point, linestring,
> linear_ring, polygon, box and segment class template, because the
> representation isn't really the challenge in the context of geometry.

Not really. GGL proposes some definitions of types for basic
fundamental geometries. However, user does not have too stick to them.
Moreover, it is expected that users may want to not to touch
these (pre-)defined types but define their own types.
It is presented in examples with "custom" word in name
http://geometrylibrary.geodan.nl/formal_review/examples.html

In other words, GGL works well with user-defined types for geometries
and such geometries shall be assumed to be first-class citizens.

> This is all perfect, but I just think that the "generic" in case of
> GGL refers to all the different "legacy" classes that essentially all
> use the same underlying representation of the geometry (point, box,
> ...), but are incompatible because of different names and
> conventions, whereas the generic in GIL and STL refers to
> fundamentally different representations of the underlying object that
> is unavoidable in principle.

As I've explained above, I believe, the genericness that can be observed
in GIL and STL is also observable in GGL

> 2)
>
> A second remark concerns the OGC names. Let's take the following
 > code from 07_graph_route_example.cpp to illustrate:

>
>
>     // Init a bounding box, lateron used to define SVG map
>     ggl::box_2d box;
>     ggl::assign_inverse(box);
>
>     // Read the cities
>     typedef boost::tuple<point_type, std::string, vertex_type> city_type;
>     std::vector<city_type> cities;
>     read_wkt<point_type>("data/cities.wkt", cities, box);
>
> ...
>
> // Read an ASCII file containing WKT's, fill a vector of tuples
> // The tuples consist of at least <0> a geometry and <1> an identifying string
> template <typename Geometry, typename Tuple, typename Box>
> void read_wkt(std::string const& filename, std::vector<Tuple>& tuples, Box& box)
> {
> ...
>     ggl::combine(box, ggl::make_envelope<Box>(geometry));
> ...
> }
>
>
> What does "ggl::assign_inverse"

It performs a kind of default-initialisation on the box, so the box
may be considered as not valid in terms of domain:

"the min corner is very large, the max corner is very small"

Obviously, zero-initialisation would not be appropriate here, so the
inverse one is performed

http://geometrylibrary.geodan.nl/formal_review/group__access.html

> and "make_envelope" do?

It calculates envelope of given geometry:

http://geometrylibrary.geodan.nl/formal_review/group__envelope.html

> These are apparently OGC names,
 > but I spend quite some time trying to verify
 > that this is indeed the case.

Strictly speaking, they are not accurate OGC names.
However, "envelope: refers to concept described in OGC specifications.
AFAIK, the "assign_inverse" is a custom concept, not OGC.

> In fact, I just ended up accepting that
> this is probably indeed that case. These OGC names are OK, but ask yourself
 > the question whether you would be able to understand the quoted
> code if you would not already know what "ggl::assign_inverse" and "make_envelope"
 > do (I know it's easy to look it up in the documentation, but that
 > is not the point). In fact, I will not tell you now, but I tried to
 > be fair when quoting the source code, so as not to remove potentially
 > clarifying comments or context.

The make_envelope follows convention like make_pair utility.
I agree that purpose of assign_inverse may not be obvious from its name.

Perhaps, name like make_inverse would be more clear and consistent.

Good naming is an art on it's own :-)

> The bottom line is that when the OGC conventions already force me to accept
 > confusing names,

As far as my own understanding is considered, GGL does not aim to
force OGC conventions. However, it uses some of OGC definitions,
those that are applicable to general geometry problems.
For example, envelope is a short but still descriptive name of MBR

http://en.wikipedia.org/wiki/Minimum_bounding_rectangle

 > it would at least be nice to know how I can
 > verify that these are indeed OGC names.
 > What are the reference documents I have to read to learn this?

Regarding use of OGC elements in GGL, the basic documents are those
directly related to OGC Simple Features

http://en.wikipedia.org/wiki/Simple_Features

It is "OpenGIS Simple Features Specification", specifically
"OpenGIS Simple Features Specifications For SQL" (99-049)

Thomas, thank you for comments.


Barend,

I think it would be good to give precise references here:
http://geometrylibrary.geodan.nl/formal_review/ogc.html

Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Stefan Strasser-2]

Hi,

this is not a review, and there won't be one because I'm not "knowledgable
about the problem domain", but some some quick comments about the traits
classes after reading the design rationale and looking at some code.

 - first of all, I'm curious why you chose to use one traits class for
each "agnosticism". this differs from the standard library, so I guess there
is a specific reason for it?
e.g. std::iterator_traits defines iterator_category, pointer, reference and so
on. the equivalent in a GGI Point concept is tag, coordinate, dimension...,
which are defined in 5 different traits classes.

 - is there a default implementation of the traits classes? I haven't found
one in code/coordinate_dimension.
this would simplify writing concept models in many cases, especially with 5
different traits for a Point.

e.g., the iterator_traits default implementation looks like this:

template<typename _Iterator>
    struct iterator_traits
    {
      typedef typename _Iterator::iterator_category iterator_category;
      typedef typename _Iterator::value_type        value_type;
      typedef typename _Iterator::difference_type   difference_type;
      typedef typename _Iterator::pointer           pointer;
      typedef typename _Iterator::reference         reference;
    };

 - on a minor note, tag<> seems a little non-descriptive, compared to
iterator_category in the STL.
Boost.Iostreams and Boost.PropertyMap both use "category", which might also be
suitable for GGI, since it has its own namespace and there are no other
categories I assume.
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost