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

From: David Abrahams (abrahams_at_[hidden])
Date: 2000-12-17 15:38:21

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

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

I love having the TOC at the top of the documentation!

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

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

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

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

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

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

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?

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?

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?

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.

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

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.

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?

-Dave

----- Original Message -----
From: "Daryle Walker" <darylew_at_[hidden]>
To: "Boost" <boost_at_[hidden]>
Sent: Tuesday, December 12, 2000 12:45 PM
Subject: [boost] Ready to add dlw_oprs.zip?

> I was wondering if the "operators.hpp" and assorted documentation in my
> "dlw_oprs.zip" file in the Boost vault at eGroups, now at version 14, was
> ready to go.  It seems that a lot of other stuff is getting checked lately
> and I hope this can get sneaked in before the next millennium (in 3 weeks,
> not 999 years).
>
> --
> Daryle Walker
> Mac, Internet, and Video Game Junkie
> darylew AT mac DOT com
>
>
>
>