Boost logo

Boost :

From: Aleksey Gurtovoy (alexy_at_[hidden])
Date: 2000-01-05 15:05:33


Dave Abrahams (abrahams_at_[hidden]) wrote:
>
> Just quickly perusing:
>
> bool contains( const point_type& p ) const {
> return !( p.x() < left() || p.x() >= right()
> || p.y() < top() || p.y() >= bottom()
> );
> }
>
>
> What is wrong with:
>
> bool contains( const point_type& p ) const {
> return p.x() >= left() && p.x() < right()
> && p.y() >= top() && p.y() < bottom();
> }
>
>
> ??
>
Nothing, Dave =). I've took these function from my old version of rectangle
class and in fact I have a no idea why some (long ;) time ago I wrote it in
that way ...

> 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...

> 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 ;)

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?

-Alexy


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk