[boost] Re: a new version of geometry classes

From: Aleksey Gurtovoy (alexy_at_[hidden])
Date: 2000-01-05 20:39:45

Dave Abrahams (abrahams_at_[hidden]) wrote:

> >> 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.
> >>
[snip]
>
> OK, you're right. What about point #2 above, though?
>

Now you are right ;) I read your comment too quickly at the first time and
didn't catch your thought.. Now I've got you. I'll remove
'restore_invariant'.

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

I think #2 can be a reasonable compromise. A declaration of a pointer to
units_pair<..> is something like 'geometry::units_pair< long,
geometry::delta<long> >* ptr;' and if you wrote something like this, you
*must* expect some problems may occur, when you use it =).

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

We can provide generic version of classes with two template parameters (and
without indexability) and a specialization for case T1==T2 with operator[].
I think it will be reasonable solution.

-Alexy