Re: [boost] Re: Ready to add dlw_oprs.zip?

From: David Abrahams (abrahams_at_[hidden])
Date: 2000-12-19 05:46:46

----- Original Message -----
From: "Daryle Walker" <darylew_at_[hidden]>
> on 12/17/00 3:38 PM, David Abrahams at abrahams_at_[hidden] wrote:

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

That, in itself, might be a problem. And I think the fact that I misread it
this way may be enough to support the idea that cross-links are not
sufficient to make the grouped and archetype template behaviors clear.

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

Imagine you're a user browsing the menu of available templates, and you're
looking for just the right archetype template. How do you know when you've
found it? Either:
1. You remember /everything/ that came before so you can understand the
archetypes in terms of their component parts
2. You navigate through a /tree/ of cross-reference links until you find all
the leaf components. How many internal nodes must you visit which you don't
care about?

> > unit_steppable<>
> > I rather like the first and last ones. Thoughts?
>
> I tried out the last one.

Thanks.

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

Simple: they're 0 in the "shorter" number, i.e. 98 == 098 == 0098

> so it may not bother defining them.  Or the user may want to skip having
to
> define them.

Okay... my feeling is that since these operators may legitimately be used
for completely different semantics (e.g. | <=> Set union, & <=> Set
intersection) it isn't worth bending over backward to describe a
generalization of the semantics for built-in types. I think
"place_value_integral_operators" is so long as to discourage use, and hard
enough to grasp (it required several paragraphs of exposition which aren't
in the HTML to explain it to me) to be alienating.

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

That wasn't the impression given by the documentation...or do the archetype
templates still use base class chaining while solving the nesting issue? If
so, I missed that, and I congratulate you on an elegant design!

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

I never meant [3]! That's a pretty spectacular misreading of the paragraph's
intent!
Try this instead, which means the same:

    In particular, though
    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, this shortcut
isn't portable.
    Even if this works with your compiler today, it may not work
tomorrow.</p>

I guess one good misreading deserves another ;-)

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

Okay, I see your point. I just find that when I read the document from the
top and get to the phrase "following example", and then I see the snippet of
code in the Borland Users: section, I get confused. Maybe we should just
change "following example" to "the Usage Example below".

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

If it's in the test, it will show up there automatically.