On Thursday, July 31, 2003, at 9:58 AM, Daniel Frey wrote:>> [snipped two possible implementations]
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.
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: [EMAIL PROTECTED], web: http://www.aixigo.de
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
