Re: comments on dlw_oprs.zip

From: Daryle Walker (darylew_at_[hidden])
Date: 2000-09-12 00:06:53

on 9/9/00 4:49 PM, David Abrahams at abrahams_at_[hidden] wrote:

> Overall, it looks good. These incremental improvements should help to
> complete the picture.

Thanks.

> Problems:
> 
> IMO, the names you've chosen for null_default_quantifiable,
> zero_default_quantifiable, and idempotent are too obscure.

Do you have better names?

> Documentation:
> 
> In the table you claim that operators<T, U> adds "idempotent<T>, and
> zero_default_quantifiable<T>" to the capabilities of the operators<T>
> template, but looking at the code it seems that it does not do that.

Those templates, with left_shiftable<T> and right_shiftable<T>, are there,
but commented out.  The problem is that my compiler (Metrowerks CodeWarrior
Pro 5 [with 5.3 update] for the Mac OS) can't handle too many nested
templates.  By changing from direct bases to nested template bases just
changed the problem from (potential) empty base class pessimization to
over-nesting.  I guess this system needs some more work.  A solution would
be to use intermediate classes.  Fortunately, the operator helper classes
can be divided that way (additive, multiplicative, integer multiplicative,
comparison, ordered comparison, shiftable, bit-manipulative, sequencable,
boolean).

> In the Notation section, you write:
> MTis the type of the pointer to member of V in member_dereferenceable.
> 
> I think it would be much clearer to say that
> MTis the type of some member of V.
> 
> You also write:
> 
> m is a member of type MT for class V (or an unambiguous base class of V
> [applied recursively]).
> 
> I think it would be much clearer and more accurate to say that
> 
> m is a pointer-to-member-of-class V of type MT.

I guess I could do those.

> I don't think I agree with the idea of adding operator void*() const and
> bool operator!(const T& x) to the forward_iterator_helper. These are not
> part of the requirements for forward iterators. Furthermore, there are
> plenty of (standard) iterators for which the default-constructed value is
> unusable, even for comparisons (e.g. std::set<T>::iterator()).

I was thinking about how a lot of iterators (especially Boost ones) use the
default value as equivalent to the end() pointer.  But that's not
guaranteed, so I should remove them.

--