[boost] Re: a new version of geometry classes

From: Dave Abrahams (abrahams_at_[hidden])
Date: 2000-01-05 18:55:08

>> Oh, and another thing:
>>
>> 1. Why not use std::swap() in restore_invariant?
>> 2. It would be lots more efficient just to use std::min()/std::max() and
>> never use restore_invariant at all.
>>
>
> I've tried ;) But you can't do it with current interface of 'point' and may
> be this is a problem we need to solve some way. In order to restore class
> invariant you need to swap corresponding coordinates of rectangle edges
> (e.g. left and right), not whole corner points. And the only form to assign
> a new value to any point coordinates (x or y) is to write something like
> p.x( new_value ) - this is not a form with which std::swap can deal...

OK, you're right. What about point #2 above, though?

>> And finally:
>>
>>     ~delta() {} // empty, just for enabling deletion through pointer to
>> 'delta'
>>
>> There is no logic to the comment, and functions like this will actually
>> result in significant 'pessimization' on many compilers (e.g. gcc, CW).
>>
>
> May be comment is indeed unclear, but actually there was a reason for this
> destructor - as I used public inheritance for 'units_pair' in 'point' class,
> and 'units_point' destructor is not virtual (and must to stay such), so I've
> tried to prevent deletion of points through units_pair<...>* - by declaring
> 'units_pair' destructor as protected. On the other hand, I want to allow
> deletion points through point<...>*, so I've just  made destructor 'public'
> by declaring empty one in point... Am I missed something? And may be you can
> offer something much better - I'll be glad to learn something new and
> exciting ;)

Hmm. You are correct, of course. The choices seem to be:
1. The way you've got it
2. Make base class destructor public, but put the base class in namespace
detail and don't tell people about it.
3. Give up on sharing much code using the base class.

I don't know which is best.

> By the way, Dave (and others ;), what are you think about idea to make all
> geometry classes to depend on two template arguments - one for x-coordinate
> type, and other fo y one? I know people who prefer to distinguish x and y
> types in order to prevent silly errors like r.assign( p1.y(), p2.x(),
> p2.x(), p1.y() ). They do it by using two inheritance-unrelated template
> wrappers for x and y coordinate types. I think we can allow such the
> technique with our classes - we need just add the second template argument
> and assign T2 = T1 by default. Your thoughts?

To me it smacks of overdesign, but having seen Beman's comment I am
open-minded on the issue.

Oh, here's another feature I like for my points: indexability (I like to be
able to access the coordinates by index). That allows programmatic selection
of orientation for things like scrollbars. Indexability is of course
unusable when the types of x and y differ. OTOH this is definitely a corner
case. I have no strong opinion on the topic.

-Dave