On Sat, 18 Aug 2012 20:27:04 +0200, Klaim - Joël Lamotte <mjklaim@gmail.com> wrote:
[...]Making it non-copyable would force the user to use shared pointers to achieve the same, but it would then make it obvious that an instance of child is the unique representation of a child process, and that if you want to share it, like std::thread, you have to share references to it in a way or another, like with a shared_ptr.
Maybe the name child is a bit misleading. It should really be a PID (POSIX) and process and thread handle (Windows) only. And as you can copy PIDs and handles as much as you want (and no one has a problem with those being copyable), child should work the same. From this point of view, I think boost::noncopyable would be an overkill.
[...]By the way, in this example:
#if defined(BOOST_WINDOWS_API) typedef boost::asio::windows::stream_handle pipe_end;#elif defined(BOOST_POSIX_API) typedef boost::asio::posix::stream_descriptor pipe_end;#endif
boost::asio::io_service io_service; pipe_end pend(io_service, p.source);
Can't there be a utility function that would provide the right type depending on the target platform?
I wonder whether this should be done in Boost.Asio? But if I compare windows::stream_handle or posix::stream_descriptor there are some slight differences. Then we are at the core problem again we struggle with in Boost.Process for several years: What do we do with differences between platforms if we don't like #ifdefs? Either we support the minimum set of cross-platform features or implement no-ops on those platforms a feature is not supported on or invent a new high-level layer abstracting the differences away?
[...]If this library is proposed to the standard later, removing any macro use for the user would be mandatory anyway.
Thanks for the encouragement! I'd already be happy if we can get something into Boost after six years. ;) Boris