Good grief. [LWN.net]

Good grief.

Posted Mar 29, 2013 9:31 UTC (Fri) by oldtomas (guest, #72579)
In reply to: Good grief. by HelloWorld
Parent article: A look at C++14, part 1

Actually I wasn't complaining about the | (still: for me it's not clear whether it's wise to overload operators this way. I mean: overloading + to add complex, quaternions or polynomials would work for me, but this seems borderline). It's mnemonic enough, at least for shell programmers.

I was rather complaining about this (pipeline::from() ... ).run(&threadpool) business. Actually (for me, at least: I know it's a matter of taste), it's the juxtaposition of this very idiomatic | sugar to that very C++ish (...).run(&foo) what conjures up images of Komodo dragons with lipstick on them. Shudder.

(Log in to post comments)

Good grief.

Posted Mar 29, 2013 14:07 UTC (Fri) by tchernobog (guest, #73595) [Link]

But that final "run (threadpool)" is exactly the beauty of the whole thing. The pipeline can be stored and ran at a later time; it is an object which retains a closure, and it can be further composed, transformed, etc. before being executed.

This programming style has been adopted in a lot of different languages and situations. Ruby on Rails uses something akin to this with AREL SQL queries. Haskell uses monads and monad transformers everywhere; every program starts in the IO monad and is just the composition of action, that are not evaluated unless needed due to the lazy nature of the language.

This allows, as already explained, for massive parallelisation and memoization, enforcing a good design from the developer to allow for maximum benefit and least effort. Calling:

std::pipeline p = std::pipeline::from (input) | std::bind (sed, "...") | ... | ... ;
run_in_parallel (p);

would be the other less object oriented option, but I'm sorry if I don't see the point.