Boost logo

Boost :

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: +49 (0)241 936737-42, fax: +49 (0)241 936737-99
eMail: daniel.frey_at_[hidden], web:

Boost list run by bdawes at, gregod at, cpdaniel at, john at