----- Original Message ----- From: "Boris Schaeling" <boris@highscore.de> To: <boost@lists.boost.org> 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@wanadoo.fr> 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!
Great.
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. Best, Vicente