Date: 2000-11-30 06:00:12
--- In boost_at_[hidden], Lutz Kettner <kettner_at_i...> wrote:
> > I just wrote a little helper class that allows to define operator<
> > my own classes in a special way so that I can write
> > if( a < b < c ) ...
> > Of course it can't work with build-in types and that's why I'm not
> > sure if this helper class should better be locked away and someone
> > should lose the key or if it could be helpful to increase
> Lose the key ;-) It works of course with builtin
> types, such as bool or int (automatic conversion from
> bool expression (... < ...) to int.) And the result is
> probably not what you mean. Here is the snippet doing it.
Well, that's what I meant when writing that it doesn't "work" with
build-in types. Sure the compiler accepts it, but it does not do what
you want / expect. Probably a good compiler should issue a warning,
but mine (gcc) doesn't :(
OK, I think the general opinion here matches yours - and mine: I
should lose the key ASAP. I was just wondering if anyone could see a
use in it other than for theoretical cases. Even worse a colleague
immediately started to overload operators for his class to compare his
class to build-in types. This worked for 'a < 5' but not for '5 < a'.
You could make it work for that last case, but when it comes to
something like this:
int minVal = 5;
int maxVal = 95;
if( 0 <= minVal <= x <= maxVal <= 100 ) ...
you can't do anything, as the first operator<= will always be a
build-in comparison and so you're stuck - I don't see any way out of
this. And the case above looks as if it could very well be a real-life
example. I therefore suggest to ignore me (at least in this case ;)
and forget about 'a < b < c'. In most cases it's simply the best
solution to write 'a < b && b < c'.
PS: If such ideas/discussions are inappropriate for this group, please
let me know. I'm new to this group and I noticed that some other
discussions here have a more "formal" style and therefor I wonder if
I'm... well... changing things to the wrong direction.
Boost list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk