Hi, Then n3534 shows the following example: [0] pipeline::execution task( pipeline::from(filenames) | pipeline::parallel(read_file | grep_fn | vgrep_fn | sed_fn, 8) | output_queue).run(&thread_pool); 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? Thanks, Benedek [0]: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3534.html#Parallel On Tue, Feb 25, 2014 at 12:01 AM, Vicente J. Botet Escriba < vicente.botet@wanadoo.fr> wrote:
Le 24/02/14 21:58, Thaler Benedek a écrit :
Hi,
Hi,
I'm interested in the Boost.Pipelines proposal of GSoC 2014. [0] I'd like to ask the stakeholder (Vicente J. Botet Escriba ?) the following:
* Is this supposed to be built from scratch or rather to be some kind of improvement over the already existing google implementation? [1]
from scratch using whatever C++11 library (or Boost). The Google implementation is just one implementation that can be inspected.
* If the former is true, should be n3534 [2] considered as a strict
requirement or as a vague suggestion?
I'm open to any design that improves the proposal.
* If the later is true, which features should be the main distinctive ones? I think about things like using Boost libraries (e.g: Boost.Atomic) instead of custom solutions, cross platform support, comply to Boost coding standard, etc. Are there any areas of improvement identified in the reference implementation?
I have not inspected too much the Google implementation :(
I would prefer to have an implementation that takes advantage of any C++11 feature that make the user interface more friendly. Only once we have this implementation we would move to a portable implementation to C++98 compilers using Boost.
* I understand it might take quite a long time for a proposal to make it to Boost, therefore it's not a requirement. Is there any objective milestone that a successful project should reach anyway?
I would prefer that the project delivers something that can be included into boost at each step. That is the project would be iterative and so there would be something useful at the end. Boost.thread contains already most of the building blocks (thread safe queue and executors), so I don't think that the project will take too long. The time given by GSoC should be enough.
Best, Vicente
Thanks, Benedek
[0]: https://svn.boost.org/trac/boost/wiki/SoC2014#Boost.Pipelines [1]: https://code.google.com/p/google-concurrency-library/ source/browse/include/pipeline.h [2]: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/ n3534.html#Proposal
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/ mailman/listinfo.cgi/boost
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/ mailman/listinfo.cgi/boost