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