|
Boost : |
Subject: Re: [boost] A design for geometric objects
From: Simonson, Lucanus J (lucanus.j.simonson_at_[hidden])
Date: 2008-11-14 14:21:11
Thank you, Mathias and Bruno for your helpful and frank feedback on my design. You'll no doubt have noted that I came to the same conclusion as you in my 2nd reply to Mathias yesterday. I came into work this morning planning to eliminate all inheritance relationships from the implementation.
Mathias wrote:
>No compile-time solution can possibly be as wasteful as a runtime linear
>branching (that even requires you to state all cases) as you gave in
>your example.
The runtime case was for selecting algorithms based on whether the data stored by the object is simpler than what the object is capable of storing, which can only be known at runtime. It was not an alternative to static selection of algorithms, but in addition to it. A polygon with holes can degenerate into a polygon without holes, a convex polygon, an axis-parallel polygon, a rectangle, a single segment, a single point or nothing at all. The need to identify degeneracy at runtime should be obvious. I'm introducing runtime degeneracy dependent optimizations into the code, which is a requirement coming from my users. This means I have to select an algorithm based on the runtime characteristics of the data in an object in addition to that object's static type.
In my type system, arbitrary-angle polygon set is the most general concept and all others are special cases of it. Any object could represent itself as a read-only polygon set. I have been thinking for some time that I should separate the mutable and immutable traits of an object type. A rectangle would want to provide immutable traits for all the more general types that are capable of representing a rectangle, but provide the mutable traits for rectangle only. It would be onerous to provide all those specializations explicitly, so I would like to use a template to auto-generate them based upon the immutable traits of the rectangle concept alone.
Regard,
Luke
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk