Uploaded experimental operators.hpp (was Re: Additions to operators.hpp?)

From: Daryle Walker (darylew_at_[hidden])
Date: 2000-07-08 19:48:18

on 7/8/00 1:00 AM, David Abrahams at abrahams_at_[hidden] wrote:

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

It encapsulates the unary + operator.  The operator just returns the value
of its object.  I used "idempotent" because "unary_plusable" sounds stupid
and I couldn't think of a good way to make "identity" an adjective.  The
word I used is slightly inaccurate; "idempotent" in my dictionary states
that the operation that the number is unchanged by is binary, I gave it to
an unary operation.  (Real examples would be addition by zero or
multiplication by one.)  A sample implementation would be:

//==========================================================================
template <class T, class B = ::boost::detail::empty_base>
struct idempotent : B
{
     friend T operator+(const T& x) { return x; }
};
//==========================================================================

[SNIP << and >>]
>> member_dereferenceable (have [unary]*, get member pointer for iterated type)
> 
> This one's opaque to me.

It represents the pointer-to-member operator (->*).  This one is hard, and I
still can't completely solve it.  First, I gave it the same signature as
dereferenceable, but that didn't work.  I found the official signature from
a copy of the C++ standard I have, but the code wouldn't compile.  I've used
a template version of this operator in the class.  I don't have a full
understanding of this rare, oddball operator.  And I can't get the example I
wrote to compile.

>> zero_default_quantifiable (default value equivalent to zero, get bool and !)

You didn't ask about this one, but I'll give an explanation.  It assumes
that the default value of your class is equivalent to zero, and all other
values are nonzero.  This struct lets you define a conversion to bool based
on your (non)zero representation.  The operator! is the reverse of the bool
conversion.  I forgot to mention that an operator== needs to be supplied.

>> 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 added my structs and their macros.  I've uploaded the changed
"operators.hpp," "operators.htm," "operators_test.cpp," and
"iterators_test.cpp" to the Boost vault on egroups.  The file is called
"dlw_oprs.zip."

Notes:
1.  "iterators_test.cpp" won't run due to problems with operator->*.  Maybe
someone else can get it working and/or have a better compiler.
2.  Unlike the above file, I had to add my other new structs manually to
"operators_test.cpp."  I couldn't attach them to operators(2) because my
compiler ran out of memory doing it.  We may have to rethink this weird
template base attachment scheme.
3.  I use Metrowerks CodeWarrior Pro 5 (with 5.3 update) on a Mac with 64 MB
memory.

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

I haven't looked at B&N.  Where can I find out about them?  Besides their
patterns, we can also do left-over operator patterns for the built-in types.

I didn't create and add the above classes to my "operators.hpp" because I
wanted to learn more about B&N, and I was burnt out by trying to make
operator->*.

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

I don't think you can do member pointers (member_dereferenceable) through
regular pointers (dereferenceable).  I don't know if my prototype is correct
for that operator, it has been my third attempt.

--