Re: [Boost-users] Python 'in' keyword-like in C++

From: David Hall (dlwh_at_[hidden])
Date: 2005-09-23 12:55:47

Simon Buchan wrote:
> David Hall wrote:
> > Tzu-Chien Chiu wrote:
> >
> > > Any boost library can make me write the expression like
> > >
> > >  int x = 3;
> > >  if ( x in list(3, 5, 6, 7) ) {
> > >   ...
> > >  }
> > >     
> > I don't know about the boost libraries, but I quickly sketched out 
> > something you might be interested in, based on something I saw on one of 
> > the news groups. All you have to do is to write a binary predicate 
> > functor with bool operator()(int,<whatever your list type is>). It's 
> > untested, but a quick syntax check with g++ 3.4.2 works fine.
> >
> > Usage will be
> > if (x <in> list(3,5,6,7) ) { ... }
> >
> > I hope that's more or less what you're after; I don't know if you want 
> > that list type/function as well.
> >
> > The code itself is attached. Be sure to fix the template parameter in 
> > the unnamed namespace..
> >
> > David Hall
> >   
> Huh.. I never thought to overload them that way, I like it!
> Some small issues with the implementation:
> * in operator_t<F>: your ctor init is... dodgy at best. Rename the 
> parameter _f or something (ie: operator_t(F _f = F()) : f(_f) {})
My bad, it was a coding guideline at some point for some class.
> * Cleaner layout! indent evenly, return types and init lists on their 
> own lines, not seperating & from types, spaces after comma's in 
> parameter lists, etc... Makes comprehension easier, for you _and_ your 
> readers.
> * related note: more meaningful template parameter names: BinFn instead 
> of F, ValueT instead of T, etc...
Again, my bad. I sketched it out in about 5 minutes...
> * It should be designed as an expression template library, 'in' is 
> something that operator< can recognise as an infix op, and generate some 
>   binder functional that when it sees an operator> can call the op on 
> the values to its left (stored) and right. I'd have to take a look at 
> what some of the expression template functions do to come up with an 
> implementation. This way <in> works for everything, and, if you are 
> careful, you could generalise to pretty much operator that you want, and 
> the same operator< template function can create the right thing. I'll 
> play around with it over the weekend and see what I can come up with.
> Boost.Infix?
I like your version a lot better, and I like the name. :)  Let me know
if you want me to help with anything; if you do, I promise to be
neater. That said, I doubt you need it/want it. 

Also, I think you can make unary operators work too, though you'd
probably need to use $my_unary_op$ (expression) instead, where $ is one
of *, -, +, and &. The only problem is that they would have lower
precedence than -> and ., meaning that the semantics of  "op
ptr->field" would change if you used a builtin unary operator versus
one of these. 
Another option would be to use either () or [], but then I suppose you
might as well be writing a function.

If you still think it's worth it, I'd lean towards * or +, but that's
just me. Perhaps one might even change the entire naming scheme to one
of those so that unary and binary operators are consistent. Using &
might run into (worse) problems because of its binary precedance, and I
think - is ugly. Shall I write up a (clean) version of unary named
operators, based on your code?

David Hall