[boost] Re: Reversed operator helpers?

From: Daniel Frey (daniel.frey_at_[hidden])
Date: 2003-08-01 03:51:15

Daryle Walker wrote:
> On Thursday, July 31, 2003, at 9:58 AM, Daniel Frey wrote:
> 
>> Daryle Walker wrote:
>>
>>> In <boost/operators.hpp> we have helper classes that can generate 
>>> "operator OP" from "operator OP=", where "OP" can be "+", "/", ">>", 
>>> etc.  What about types and algorithms where the non-assignment 
>>> version is easier than the assignment version?  Should we have 
>>> reverse helpers?
>>
>>
>> Sounds like a good idea in general.
>>
 >> [snipped two possible implementations]
>>
>> What about the naming of the new classes? Do you have something in mind?
> 
> 
> I just thought up the basic idea, but nothing like the formats and 
> such.  You've gotten ahead of me.

I started to think about it when I read your post, so I can't be that 
much ahead :) Just brainstorming right now...

Also, I asked about the names because I don't have a convincing idea for 
them. I thought about adding the word "reverse" somewhere, but that 
sounds like a bad idea as it reflects some internal design of the 
operators library and is thus only confusing for the user (IMHO).

When looking at the current:

class X : boost::addable< X >
{
    X& operator+=( const X& );
};

I wonder if addable is a good name. I thought that the classes are named 
by the operator that is provided by the user and that they add the 
operators that are based on it. Like here:

class Y : boost::less_than_comparable< Y >
{
    friend bool operator<( const Y&, const Y& );
};

That given, the new class should be called 'addable', the current class 
should probably be called 'add_assignable' or something like that. But 
that would break the interface :(( Thoughts, anyone?

>> Do we need to prevent the user from deriving from both forms, creating 
>> infinite loops that only show up at run-time (+ calling += calling + 
>> calling += ...)? How shall we accomplish it without to much burden, 
>> possibly breaking the code for weaker compilers?
> 
> Wouldn't this only happen if the user explicitly coded it that way (i.e. 
> the user added the "OP from OP=" _and_ the "OP= from OP" helper classes)?

I think so. But I would like to prevent the errors to show up at 
run-time if I can catch them at compile-time. For weak compilers, this 
extra security can be disabled, so we won't run into a 
compatibility-problem with this. But this is an issue which should IMHO 
be addressed at the end as it is not needed for the rest.

Regards, Daniel

-- 
Daniel Frey
aixigo AG - financial training, research and technology
Schloß-Rahe-Straße 15, 52072 Aachen, Germany
fon: [phone], fax: [phone]
eMail: daniel.frey_at_[hidden], web: http://www.aixigo.de