Boost logo

Boost :

Subject: Re: [boost] [process] Arguments and Context concepts
From: vicente.botet (vicente.botet_at_[hidden])
Date: 2011-01-21 02:21:56

----- Original Message -----
From: "Boris Schaeling" <boris_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Friday, January 21, 2011 12:01 AM
Subject: Re: [boost] [process] Arguments and Context concepts

> On Thu, 20 Jan 2011 08:21:43 +0100, vicente.botet
> <vicente.botet_at_[hidden]> wrote:
>> [...]We could have multiple implementations of the same concept and have
>> just one in a specific platform. In this case we have always the same
>> class and having a template parameter is not realy useful. If the
>> requirements are too close to the current context implementation, which
>> is the advantage to pass Context as template parameter then?
> Indeed, it's questionable if there is an advantage at all. I guess we left
> the template parameter just in case someone wants to use another type for
> reasons unknown to us.

Could you document the requirments i nthe reference section?
>> What about adding this overloading?
>> template <typename Context>
>> child create_child(const std::string &executable, const Context & ctx);
>> You should need enable_if and some way to recognize if the parameter is
>> a Context or some Arguments to disambiguate, but it should be possible,
>> and this avoids to have an additional args variable when no args at all
>> are needed.
> Yes, makes sense!


>> BTW, are you copying the parameters Arguments and Context now? Why not
>> pass by reference?
> One goal was to create multiple child processes with the same parameters.
> While the Arguments parameter is still changed by create_child() I see
> that Context isn't anymore (probably a side effect of another change to
> the context class when we redesigned the way streams are configured).

Then you could pass Context by cont& without any change on user code. You could commeback to pass by value if you need to modify it.

>> A see the change to the working directory as a really specific case. I
>> would pass it as an argument to the process creation and let the child
>> process make itself the change to the working directory. Could you tell
>> us why did you need to added it?
> Well, you might not have access to the source code for example and can't
> make the child process change the working directory.

This is too specific to be included in a Process library.

> A more important
> reason is though that I'd describe Boost.Process as a library trying to
> support as many high-level cross-platform concepts as possible. I guess
> that's the current goal after we gave up other ideas like trying to
> support as many platform-specific features as possible (that was when we
> had POSIX and Windows classes which could have grown endlessly and would
> still never have been complete; now we have extension points to provide
> the flexibility of using platform-specific features).

I don't find the answer to my question here.
>> An alternative to multiple overloading could be to use the essence
>> pattern of a child process creation and pass to the function a single
>> parametter:
>> child create_child(const creation_essence & );
> In my opinion our current context class is rather small that this isn't
> required (it was much worse before when we had POSIX and Windows context
> classes). I think something like this would help if the context class grew
> again. This again depends on high-level cross-platform concepts we might
> be able to identify to describe a process context. But if you look at
> things like uid on POSIX or SECURITY_ATTRIBUTES on Windows it's rather
> difficult to imagine how high-level cross-platform concepts could look
> like to support these things in Boost.Process. It looks like context is
> already pretty much complete.

The same interface arguments applies to the Context concept independently of whether you use an essence argument. If you require a more high level interface for the Context concept, you will be able to implement it as efficiente as posible on specific platforms. The current concept behind the Context parameter has a user interface that is not enough abstract. The use of specific fields depending on std::string forbids any possible optimisation.


Boost list run by bdawes at, gregod at, cpdaniel at, john at