Re: geometry classes proposal

Dave wrote:
> If you want to be fully general, you parametrize. The issue is one of
ranges
> (another simple concept that should be covered by boost) and whether they
> are represented as closed or half-open.
>
> But I don't want to be fully general. I believe that the half-open
approach
> (coordinates are grid lines) is the correct one for the bitmapped graphics
> problem.
>
> Furthermore, if you really intend to represent geometry and not pixel
> graphics, the half-open approach is the only correct one. If you have a
> rectangle<double> and its left side is at 0 and its right side is at 5,
how
> wide is it? There can be only one reasonable answer: 5
>
You are right, Dave, and you've soothed me about this question ;) In fact I
just didn't try to think about implementation any of member function in
these classes in case of a non-integer template parameter. So your thought
have opened  my eyes - thanks ;)

> I don't believe that size is a neccessary separate concept for pure
> geometry, though there are some cases in graphics APIs where a distinction
> between size and point would reduce errors (certain blitting code). The
case
> you're mentioning can be handled thus:
>
> point topleft, extent;
> rectangle r( topleft, topleft + extent );
>
> BTW, the 2-point constructor for rectangle should allow you to specify any
2
> diagonally opposite corners in any order.
>
Probably I agree with you, we just need to insert call the 'normalize'
member function in the constructor.

> I don't know why. In mathematics no distinction is made between the vector
> representing a location and a vector representing an offset (e.g. a
'size').
> I like to call this function 'extent()', BTW.
>
> So what do you get when you subtract 2 points? A size?

exactly =) and when you add 'size' to 'point' you always receive a point. I
know all these rules may seem too complicated, but then I actually have
implemented all of them in code, they seem to work ;) I suggest to play some
time with current implementation and see, if this issue will cause any
problems. I still see some attractive sides of this approach and want to
insure in its waning before we drop it off ;)

>
> I don't think I believe in supplying write access to data members through
> functions. They may as well be fully exposed. Is there a reason why not?
>

Well, actually there are some reasons. First, an using of access wrappers
hides implementation details ;). I prefer to implement rect class using two
points (origin_ and corner_ ) for presenting rectangle location and with
access wrappers I can still provide the usual 'left()', 'top()', 'right()',
'bottom()' to you. And what is more, this way you get a kind of uniformity
in interface - either you ask about a 'built-in' property of object (used in
implementation - e.g. top-left point), or about a computational property -
e.g. center or left-bottom point, you are using the (almost) same
interface - member function. It's convenient and allows you to change
something in implementation later.
You may even create an illusion of existence such a computational property -
by returning from the member function some kind of proxy object, who behaves
like an ordinary point, but indeed it translates all its method calls to
method calls of his owner. I'm kidding a little, but I think you've got my
point. I still prefer member functions.

Thanks for response Dave... Did you take a look at the code?
Just curious ;)

-Alexy