Re: [boost] A design for geometric objects

Subject: Re: [boost] A design for geometric objects
From: Simonson, Lucanus J (lucanus.j.simonson_at_[hidden])
Date: 2008-11-15 19:22:19

Simonson, Lucanus J wrote:
>> Clearly if a rectangle output is expected you cannot pass it a mutable
>> square to hold the result, but making such syntax illegal by preventing >> the generic API from modifying objects seems like a drastic measure.  It >> eliminates more than half the utility of the mechanism.

>I require any type fulfilling a concept to be constructible from an
>object of any type which fulfills that same concept.
>So I can simply return any object, which will then be copied into the
>structure of the user.
>If the object is light and the compiler is good, there shouldn't be any
>penalty.
>
>I personally strongly dislike the idea of providing output as arguments,
>so I suppose I'm quite biased on that limitation.

I don't like it either, but I have little choice.  I can't require that any type fulfilling a concept be constructible from any object that also fulfills that concept and I cannot overload the copy constructor or assignment operator of unknown geometry type T.  Also, geometry objects can be arbitrarily heavy.  One polygon has the potential to be many megabytes in my application domain.  While it is possible to return by value for light objects and pass outputs as arguments for heavy objects, it would make for a highly inconsistent and unintuitive API.  I also like to write API with an accumulate semantic where possible so that the output argument appends to rather than overwriting its contents.

Luke