On Sat, Jan 1, 2011 at 15:52, spir <[email protected]> wrote: > On Sat, 1 Jan 2011 09:56:25 +0100 > Philippe Sigaud <[email protected]> wrote: > >> As I said in the docs, I got stuck at comparison operators. a < b is >> automatically transformed by the compiler into a.opCmp(b) < 0. >> a.opCmp(b) becomes another lambda and the '< 0' part triggers another >> expansion, ad infinitum... > > Is this a good design choice? I mean opCmp looks like a good idea (wrapping > all comparisons in a single one instead of having to implement all > separatedly), but is it really one? It currently annoys me for a custom sort > where what I need is just less-than. opEquals is already apart: I would vote > +++ for opLessThan. Then, a programmer can get rid of opCmp alltogether (I > don't mean it should be deprecated, may have uses).
I don't know if it's good design or not. All I can say is that's the point where C++ can continue and one can have Boost::lambda. Whereas I was stuck. Anyway, that was a small foray into expression templates, which was interesting and such... But I went back to string templates. For small expressions, they are quite palatable. I just developed a n-args version of UnaryFun/BinaryFun, which was one of the most useful little helper I ever did in D.
