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

From: Simon Buchan (simon_at_[hidden])
Date: 2005-09-25 18:56:12

David Hall wrote:
<snip>
>>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.
> 
We've all done it ;)
>>* 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...
> 
Heck, just a note, I'm not the layout police :D
>>* 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.
> 
No no, jump right in!  I'm not sure I could spend enough time on a 
library like this to give it all the luv'n it would need!
> 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.
> 
Well, op expr -> op(expr) is not _nearly_ as bad as expr op expr -> 
op(expr, expr), so I dont have too much trouble with function call.  If 
we can get nice clean syntax worked out for a cohesive library, that 
would be cool, though.
> 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?
> 
If you want, I don't own you, or the idea (it was your idea for the 
concept, remember? :D)