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: Volker Schöch (vschoech_at_[hidden])
Date: 2012-02-16 03:57:14

Barend,

> > 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.

> 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.

As always, thanks for your replies!
   Volker

--
Volker Schöch | vschoech_at_[hidden]
Senior Software Engineer
think-cell Software GmbH | Chausseestr. 8/E | 10115 Berlin | Germany
http://www.think-cell.com | phone [phone] | US phone [phone]
Amtsgericht Berlin-Charlottenburg, HRB 85229 | European Union VAT Id DE813474306
Directors: Dr. Markus Hannebauer, Dr. Arno Schoedl