RE: [boost] Is allowing 'if( a < b < c )' useful?

From: Gary Powell (Gary.Powell_at_[hidden])
Date: 2000-11-29 13:44:08

Hi,
  This is cute, but I won't be using it anytime soon in production code.
Reasons are that being non standard code its going to confuse the junior
members of the staff. Also if I'm not mistaken because of the implementation
it might not do things as I would expect.

  if (fn1() < fn2() < fn3() )

In this case if fn1() < fn2() fails, I would prefer that fn3() never be
called. With expression templates (i.e. a lot more templates) I think this
could be made to work, but I don't see it being worth it.

  Also having native types fail is going to be a hassle, which could be
overcome with another proxy object, but then it stops looking so clear.

  if (var(i) < j < k )

  And the simple replacement is "if (withinRange(a,b,c) ) " or using
operator()()
   if (withinrange(a)(b,c) )  also not particularly clear. 

And if you are using variables anyway
  if (a < b && b < c) really isn't all that hard to read.

  I may however play around with it. As it looks like fun and games with
proxy objects. And I've always been a sucker for proxy objects.

   Yours,
  -gary-

gary.powell_at_[hidden]

> -----Original Message-----
> From:	Daniel Frey [SMTP:d.frey_at_[hidden]]
> Sent:	Friday, November 24, 2000 3:12 AM
> To:	boost_at_[hidden]
> Subject:	[boost] Is allowing 'if( a < b < c )' useful?
> 
> Hi,
> 
> I just wrote a little helper class that allows to define operator< for
> 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 readability.
> In the latter case, it could be added to Boost - if you like. Before I
> talk to much, the helper class and a small example:
> 
> --- code ---
> 
> #include <iostream>
> using namespace std;
> 
> template< typename T > class comp_result
> {
> private:
>    const bool result_;
>    const T& value_;
>    
> public:
>    comp_result( const T& value )
>       : result_( true ), value_( value ) {}
>    comp_result( const bool result, const T& value )
>       : result_( result ), value_( value ) {}
>    ~comp_result() {}
>    
>    operator bool() const { return result_; }
>    const T& value() const { return value_; }
> };
> 
> class A
> {
> private:
>    int i_;
> 
> public:
>    A( int i ) : i_( i ) {}
>    ~A() {}
>    
>    friend comp_result<A> operator<( const comp_result<A>& lhs,
>                                     const A& rhs )
>    {
>       return comp_result<A>( lhs && lhs.value().i_ < rhs.i_, rhs );
>    }
>    
>    friend comp_result<A> operator>( const comp_result<A>& lhs,
>                                     const A& rhs )
>    {
>       return comp_result<A>( lhs && lhs.value().i_ > rhs.i_, rhs );
>    }
> };
> 
> int main()
> {
>    A a = 1;
>    A b = 2;
>    A c = 3;
> 
>    if( a < b < c ) cout << "y";   
>    if( b < a < c ) cout << "n";
>    
>    if( !(a < c < b) ) cout << "y";   
>    
>    if( c > b > a ) cout << "y";
>    if( c < a < b ) cout << "n";   
> 
>    if( b < c > a ) cout << "y"; // Doh!
> 
>    cout << " <- should equal 'yyyy'" << endl;
>    
>    return 0;
> }
> 
> --- end code ---
> 
> I am aware that this might cause a lot of problems, including
> overhead, newbie's transfering this pattern to build-in types,
> boost/operators.hpp may not be usable with it, etc. - this is why I
> want some feedback. Any comments on this are welcome...
> 
> Regards, Daniel
> 
> 
> 
>