Re: [boost] [geometry] area, length, centroid, behavior

Subject: Re: [boost] [geometry] area, length, centroid, behavior
From: Simonson, Lucanus J (lucanus.j.simonson_at_[hidden])
Date: 2009-02-24 12:48:15

>> and for an invalid polygon (e.g. no points at all, or not closed)?
>> - exception
>> - return "false" (if centroid is passed as a reference parameter)
>> - ? (we've not always the compiler error option here because points
>> are usually stored in a runtime collection)
>
> Undefined behaviour.
> An invalid polygon shouldn't be allowed in the first place.
>
> Ideally, that should be prevented by the type system.

We are not defining the type system, we are defining a system of concepts.  It places an unreasonable restriction on the definition of polygon to insist that it can't be default constructable and empty.  I'm OK with undefined behavior being the result of calling area() on a default constructed legacy polygon type, but preferablly the undefined behavior should be deterministic.

I'd also like to point out that roughly half the legacy polygon types floating around are invalid if you insist that they are "closed" because the last edge may be implied and it is more memory efficient to omit the redundant point.  In such cases it is better to assume the implied edge that closes the polygon and produce the correct result rather than throw exceptions.  It is also unreasonable to assume a winding direction convention.  If your polygon concept requires these three conditions (not empty, closed and CC winding) you are excluding 7/8 legacy data types if we assume each decision is made arbitrarily.  Making algorithms invariant to these conditions takes some extra coding and testing, but isn't too difficult.

Luke