Subject: Re: [boost] [GSoC] pipelines questions
From: Thaler Benedek (thalerbenedek_at_[hidden])
Date: 2014-03-01 10:32:42
Then n3534 shows the following example: 
pipeline::parallel(read_file | grep_fn | vgrep_fn | sed_fn, 8) |
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?
On Tue, Feb 25, 2014 at 12:01 AM, Vicente J. Botet Escriba <
> Le 24/02/14 21:58, Thaler Benedek a écrit :
>> I'm interested in the Boost.Pipelines proposal of GSoC 2014.  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? 
> 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  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
>> I think about things like using Boost libraries (e.g: Boost.Atomic)
>> 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
>> 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.
>> : https://svn.boost.org/trac/boost/wiki/SoC2014#Boost.Pipelines
>> Unsubscribe & other changes: http://lists.boost.org/
> Unsubscribe & other changes: http://lists.boost.org/
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk