Re: Ready to add dlw_oprs.zip?

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

on 12/17/00 3:38 PM, David Abrahams at abrahams_at_[hidden] wrote:

> This version is much, much better. We're almost there, I think. Remarks:

I just put up a new version (15) in the vault, based on some of these
comments.

> Why doesn't integer_multiplicativeX supply the operations of dividableX in
> addition to multipliableX and modableX? This doesn't seem to make sense.

It does supply division, you're misreading it.  I took a second look at the
code, you're confusing multipliableX with multiplicativeX.

multipliableX: multiplication operator
multiplicativeX: multiplication and division operators
integer_multiplicativeX: multiplicativeX and modableX -> multiplication,
division, and modulus operators

The words just look very similar.

A while after taking a look I realized: if you were right, then
"operator_test.cpp" would have choked when compiling the division tests!

[SNIP]
> In the rationale section, it says
> x >= y ≡ !(x < y)
> On my machine, ≡ looks like 3 parallel bars. I think I wanted the
> two-headed implication symbol <=> here. Is are the two symbols equivalent
> (no pun intended)?

I think they're close.  However, I looked at the entity list, and there is a
code for your original symbol ("&hArr;").  I changed the HTML there.

> Some minor English usage mistakes:
> "These templates are "simple" since they provide operators based from a
> single operation..."
> That should be "based on", not "based from".

Fixed.

> Operations Given from Template/Requirements Needed for Template
> Should be "Operations Supplied by Template/Requirements of Template" or,
> preferably,
> "Supplied Operations/Requirements" (users already know it's a template!)

Fixed.

> "needs the requirements of" should be "has the requirements of"

Fixed.

> In the key sections of the tables, you have:
> T: the instantiating type    U: another type, should be numeric
> What does "the instantiating type" mean? What information does it supply to
> the user. I think none, thus it should be removed, or replaced by "an
> operator argument type". Why should "U" be numeric? I don't believe that's
> neccessarily true. There's no reason one shouldn't use
> addable2<Collection<U>, U>, for example.
> So, I suggest that the description of T and U be removed or replaced by
> "operator argument types".

Cleaned up the writing there.

> In the documentation for grouped arithmetic and archetype operators, it
> would be very helpful to see the operations supplied by each template listed
> in a synopsis. For example, totally_ordered<T> might list:
> t <= t, t != t, t > t, t >= t
> It's just that by the time you get to the archetypes, it's pretty hard to
> keep track of what you're actually getting from, e.g., floating_operators<>

That's why I have HTML link cross-references.

> I don't love the name "unit_changeable", though it's an improvement over
> what you had before. I also can't think of a perfect name, but I think some
> of the following may get us even closer than we are now:
> bidirectional<>
> bidirectional_steppable<>
> steppable<>
> unit_steppable<>
> I rather like the first and last ones. Thoughts?

I tried out the last one.

> What's the rationale behind the name "place_value_integral_operators"? It
> doesn't make much sense to me. It seems like "bitwise_integral_operators"
> would do better. Furthermore, why distinguish integral_operators from this
> class?

A while ago I realized that the "bitwise" operators could be generalized to
any place-value representation numeric type with radix besides two.  For
other bases, we could have:

AND: minimum digit
OR: maximum digit
XOR: (absolute) digit difference
NOT: difference between highest digit and current digit

For example, with a decimal base and three-digit numbers:
    564 & 901 == 501
    564 | 901 == 964
    564 ^ 901 == 463
    ~564 == 435
    ~901 == 098

Note that the definitions stay consistent for binary.

As for distinguishing, not all integral types could support the bitwise
operators.  An arbitrary-precision integer would have problems with them (if
two numbers have different digit lengths, what happens to the extra digits),
so it may not bother defining them.  Or the user may want to skip having to
define them.

> Changing operators<T> to use higher-order operator templates is a good
> example of code reuse, but it does cause multiple inheritance which will
> bloat class instances on almost all compilers. I realize few people are
> probably using operators/operators2, but are you sure this is a good idea?

Uh, the new operatorX templates still use the base chaining technique, not
multiple inheritance.

> The portability note below the "Final Arithmetic Operator Template Classes"
> table actually applies to ALL of the tables, and should probably be moved up
> to precede all of the sections. It is an important caveat which any user of
> the library should be aware of.

I was about to fix this, but I think there is a major problem with the text.
It says:

> <p id="portability"><strong>Portability Note:</strong> many compilers
> (e.g. MSVC6.3, GCC 2.95.2) will not enforce the requirements in this
> table unless the operations which depend on them are actually used.
> This is not standard-conforming behavior.  If you are trying to write
> portable code it is important not to rely on this bug.  In particular,
> it would be convenient to derive all your classes which need binary
> operators from the <code><a
> href="#operators1">operators&lt;&gt;</a></code> and <code><a
> href="#operators2">operators2&lt;&gt;</a></code> templates, regardless of
> whether they implement all the requirements in the table.  Even if this
> works with your compiler today, it may not work tomorrow.</p>

There is the minor problem about mentioning operators1 and operators2 (I
should also mention the new combination templates).  The main problem is
that the text contradicts itself.

1.  Some compilers only check the operators actually used for their
presence.
2.  This partial checking is wrong; even unused operations have to have
their presence confirmed by the compiler.
3.  So use the operatorsX templates to aid in portability.

If you're only defining some of the operations that operatorsX uses,
wouldn't it be _wrong_ to use that template, contradicting [3]?  A
conforming compiler would see that some of the operations are missing and
give an error.  The right solution would be to use the individual operator
templates, or smaller group templates (like my new stuff).

> The Caveat and Note to Borland Users in the section "base class chaining and
> object size" should really follow the Usage example.

Why?  Moving them would split that section in half.  (The Usage example is a
sibling section.)

> I wonder if we should make claims on the doc page about what compilers the
> test program works with. It seems to me that job is covered by the compiler
> status page and we're just creating an opportunity for the information to
> become out-of-date.

I agree.  I think the information is already out-of-date.  I could remove
the information from the docs, but is updated stuff ready for the compiler
status page?

> In the key section for the Dereference Operators and Iterator Archetypes, I
> would like to see, e.g.
> &quot;difference&quot; type of the iterator
> replaced with:
> <code>difference_type</code> of the iterator
> Also, since Dereference Operators are, as the docs say, useful in
> non-iterator contexts, should we say "of the iterator" in this table at all?

Cleaned up.

-- 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com