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)