Re: [boost] Additions to operators.hpp?

From: David Abrahams (abrahams_at_[hidden])
Date: 2000-07-08 00:00:54

----- Original Message -----
From: "Daryle Walker" <darylew_at_[hidden]>

> Hi.  This is my first post to the list (I joined 1 Jul 2000).
>
> I wonder how to propose changes to a file someone else is already working
> on?  Do I just post the changes to the list?  Or do I upload an altered
file
> to the vault?  Or do I try to contact the current people working on it?

Yes ;)

Any of those approaches would work. I'm official the maintainer of
operators.hpp but you can see from the change log that Alexy Gurtovoy,
Jeremy Siek, and Mark Rodgers have all made very significant contributions.
You can talk to any of us.

> The basic changes I want to make are to "operators.hpp."  I want to add
the
> extensible operators that weren't included.  The list of my proposed
classes
> are:
>
> idempotent (no requirements, unary +)

Needs more explanation.

> left_shiftable (have <<=, get << for self or other type [non-commutative])
> right_shiftable (have >>=, get >> for self or other type
[non-commutative])

These sound good

> member_dereferenceable (have [unary]*, get member pointer for iterated
type)

This one's opaque to me.

> zero_default_quantifiable (default value equivalent to zero, get bool and
!)
>
> I wrote implementations of the above structs.  The current maintainer can
> add the appropriate BOOST_*_TEMPLATE? macros.  (The *_shiftable classes
are
> really in *able1 and *able2 versions.)

I would like it very much if you'd add the macros yourself to operators.hpp,
update the documentation (operators.htm), and post the changes to the vault.
You could also try to enlist help from other boost members with this, if
neccessary. History shows that if you post something to the vault, help is
likely to appear as if by magic ;)

> I also have suggestions for new operator policy struct templates
>
> 1.  binary_integral2 and binary_integral
>     + like operators(2)
>     + adds idempotent, left_shiftable, right_shiftable,
>        and zero_default_quantifiable
>     + should act like the built-in integral types
>       (actually, you would also need ~ and possibly unary -)
>
> 2.  place_value_integral2 and place_value_integral
>     + like binary_integral(2)
>     - but removes bit operators (& | ^)
>     + keeps << and >>, with shift by the radix instead of 2
>     + (you would still have to add unary -, but not necessarily ~)
>     - no built-in type acts like this, AFAIK
>
> 3.  floating_number2 and floating_number
>     + like place_value_integral(2)
>     - but removes modulus (%) and shift (<< >>) operators
>     + should act like the built-in floating types
>       (actually, you would also need unary -)
>
> 4.  unordered_number2 and unordered_number
>     + like floating_number(2)
>     - but removes ordered (< > <= >= ++ --) operators
>     + should act like std::complex (floating) types
>       (actually, you would also need unary -)
>
> You could use inheritance here (4->3->2->1 or (4->3 and 2->1)).  That
funky
> empty-base setup in operators.hpp could be used instead of inheritance.

These are interesting, though I think the names could use some improvement.
Have you looked at Barton & Nackmann? They have hierarchies of operator
templates that include mathematical concepts like abelian semigroup, etc. It
might make sense to draw a bit on prior art for the general approach here.
Also, higher-order uses of operators maybe should go in a different but
related library o(operators and operators2 are mostly just useful as test
cases).

> The member_dereferenceable struct should be added to the iterator helper
> classes.

I'm still curious to see what this means; are you sure it's not covered by
dereferenceable?

-Dave