Geometry Boost List: Re: [geometry] Default model for Ring Concept should *be* Container, not inherit from it

Subject: Re: [geometry] Default model for Ring Concept should *be* Container, not inherit from it
From: Barend Gehrels (barend_at_[hidden])
Date: 2012-02-16 09:10:11

Hi Volker,

On 16-2-2012 9:57, Volker Schöch wrote:
>
>>> I wonder why you bothered to make boost::geometry::model::ring a type of its own, merely wrapping the Container type.
>> [...]
>>
>> Now in C++11 it is (maybe) possible. I'm not really sure if the template alias gives you possibilites for specialization. Did not try yet. Is an alias named ring such different from a similar alias named linestring that you can make two specializations? Don't know that.
> No, certainly not. It's the point of a typedef -- templated or not -- to provide the identical type under a different name. If there are two containers with identical base types (and allocators) but different semantics, then yes, they must be types in their own right to allow for specialization. (Whether that type should inherit from the container, or own the container as member, is a different question, as Mateusz pointed out.)
>
> Assuming that boost::geometry::model::ring cannot be eliminated as I suggested, then I would in fact suggest adding a move ctor and move assignment to its interface. See Mateusz' post and sample code. Or in Mateusz' words: "The base class of ring is already perfectly moveable type, so I'm not actually adding this behaviour, just making use of it." Whatever you want to call it.

OK, it's no problem at all to add the move ctor/assignment operators.

The sample of Mateusz can directly been taken over to our ring, 
linestring and 3 multi's.

>> I'm indeed puzzled ;-) The TPolygon is derived from a vector of polygon? Besides that I don't understand that, is that not doing a similar thing as we did? Or is this a show how it should not be? Maybe I miss the point.
> _TPolygon is a legacy type (which also explains its unconventional name) that originally did not derive but instead had a member which was an STL list of STL vector of our point type, very much in the spirit of GGL's multi-polygons. It was a concession to GGL's requirements for multi-polygons that we changed the implementation from member to inheritance. I'd be glad if GGL would not have this requirement; that's certainly possible in principle but would of course require a couple more traits for the multi* concepts. The same would obviously apply for making the container a member of ring rather than inherit ring from the container.
>
> We use our own implementation of multi-polygon instead of the model provided by GGL because _TPolygon offers a whole lot of interface (not present in the cut out sample I pasted to Codepad) that provides glue to legacy code and some conveniences that GGL does not (yet) offer.

OK, I see.

What is exactly the requirement for multi-polygon that is the problem? 
Sorry if I missed that point earlier somewhere. A MultiPolygon (the 
concept) should behave as a range, that is basically all. Our 
multi_polygon derives from a std::vector, but that is not necessarily 
the case - you can also contain it and adapt it to Boost.Range.

Regards, Barend