Re: Ready to add dlw_oprs.zip?

From: Daryle Walker (darylew_at_[hidden])
Date: 2000-12-19 23:55:54

on 12/19/00 5:46 AM, David Abrahams at abrahams_at_[hidden] wrote:

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

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

OK.  More on this at the next break.

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

I was think about incorporating this, but would make the HTML file even
bigger.  Maybe it could be done if Aleksey's idea of splitting the library
is done.

[SNIP unit_steppable]
>>> 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

OK.  But I think the operator~ could be problematic.  For numbers with the
bigger-place digits having the value of the largest digit (9 for decimal, 1
for binary, etc.), the complement would change them to zero.  Those zeroes
could be removed without changing the numbers value, but doing that would
not give the original value if the new value is re-complemented.

Just a thought, it's not a matter for us here, but for me designing an
arbitrary-precision integer class....  -_^

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

Well, I did change the "integral" part to "integer," and changed the
"place_value" to "bitwise" as you suggested.

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

Was there anything in the documentation to give the impression of (standard)
multiple inheritance?  I'm not sure that the inheritance 'breaks' solve the
over-nesting problem that prompted me to make the grouped templates.  The
chaining was too long when I tried to incorporate my new single templates to
the operatorsX stuff, but I've never gone back to try incorporation again
using the group system!  I changed my mind and decided to keep the outer
services of operatorsX the same to not inconvenience current users, due to
the next point.  I guess we could try it one of these days....

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

Cleaned up and moved that paragraph.

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

Fixed the link text to make it clearer where it goes to.

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

I looked.  The operator tests are there.  As I told Beman, I changed those
sections to point to the compiler test page.

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