Re: [boost] [gsoc] Boost.Process done

Subject: Re: [boost] [gsoc] Boost.Process done
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2010-09-01 08:37:23

Wolfgang Fertsak wrote:
> On 01.09.2010 01:03, Boris Schaeling wrote:
>
> I think the current implementation can cause problems on POSIX
> too. When an executables closes its stdin/out/err file
> descriptors (e.g. a demon), inheriting these handles will also
> fail (and I guess exceptions will be thrown).
> So regardless of what the default behavior is, POSIX and
> Windows developers should be able to change it.
> IMO another constructor with the 3 parameters for the stream
> behaviours would do. The documentation should state clearly
> that the default behavior is inheritance and will fail if the
> application has no console or its stdin/out/err file
> descriptors have been closed.

Here are a couple of thoughts on how you might solve the dilemma:

Try the Named Constructor Idiom.  One can choose which behavior one wants by invoking a static member function with a suggestive name and requiring whatever arguments are appropriate and returning an instance of the class.  That's often clearer than overloading constructors.

If it is possible to determine whether a Windows app is being built as a console app versus a GUI app, then you could conditionally compile for one or the other, thus keeping a Windows developer from choosing incompatible behavior.

_____
Rob Stewart                           robert.stewart_at_[hidden]
Software Engineer, Core Software      using std::disclaimer;
Susquehanna International Group, LLP  http://www.sig.com

IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.