On 1 Mar 2014 at 16:32, Thaler Benedek wrote:
pipeline::execution task( pipeline::from(filenames) | pipeline::parallel(read_file | grep_fn | vgrep_fn | sed_fn, 8) | output_queue).run(&thread_pool);
If you're going down the road of adding pipelined i/o, do look into proposed Boost.AFIO which already implements chainable asynchronous file i/o for you. Should save you a ton of work. Failing that, Boost.Iostreams also provides a huge amount of chainable i/o implementation already written and tested. Boost.Iostreams can't do async easily though.
I can't figure out how to create a segment from "read_file | grep_fn | vgrep_fn | sed_fn" without overloading the free function operator|(function, function). Is this really we want to do? Shouldn't we use pipeline::make() here?
I would look at Google's proposal as merely a suggestion. Microsoft have their own proposals for (mis)using the C++ operator syntax as a DSL for specifying asynchronous operations. Just because Google proposed it doesn't mean it's special. You're right that overloading global functions is generally to be avoided unless you absolutely control the implementation of the types entering the global function. I personally think that the "Improvements to future<T>" proposal is far safer and much more likely to get standardised. Niall -- Currently unemployed and looking for work in Ireland. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/