[process] Some comments

Hi all, I tried to use the candidate Boost.Process library in one of my projects and found it a valuable piece of software helping me to write lesser code (and that's good!). A couple of issues came up when compiling the code on Windows (VC7.1SP1): - The library uses the MS specific safe string functions as strcpy_s. These are currently only available when using VC8. Other development environments as VC7.1, Borland etc. don't have these available. - Including the header file file_handle.hpp from more than one translation unit results in multiple symbol definitions for file_handle::INVALID_VALUE during linkage. - The functions children::get_stdin(), children::get_stderr(), children::get_stdout(), and children::wait() have to be defined inline for the same reason. Thanks! Regards Hartmut

On 9/1/06, Hartmut Kaiser <hartmut.kaiser@gmail.com> wrote:
Hi all,
Hi Hartmut,
I tried to use the candidate Boost.Process library in one of my projects and found it a valuable piece of software helping me to write lesser code (and that's good!).
A couple of issues came up when compiling the code on Windows (VC7.1SP1):
- The library uses the MS specific safe string functions as strcpy_s. These are currently only available when using VC8. Other development environments as VC7.1, Borland etc. don't have these available.
Hopefully fixed.
- Including the header file file_handle.hpp from more than one translation unit results in multiple symbol definitions for file_handle::INVALID_VALUE during linkage.
I don't know how to fix this yet... but hopefully this whole thing will go away when I address another suggestion that affects handles and identifiers.
- The functions children::get_stdin(), children::get_stderr(), children::get_stdout(), and children::wait() have to be defined inline for the same reason.
Fixed. Plus a test added to prevent this from happening again ;-) Thanks for your comments! -- Julio M. Merino Vidal <jmmv84@gmail.com> The Julipedia - http://julipedia.blogspot.com/

Hi Julio,
- Including the header file file_handle.hpp from more than one translation unit results in multiple symbol definitions for file_handle::INVALID_VALUE during linkage.
I don't know how to fix this yet... but hopefully this whole thing will go away when I address another suggestion that affects handles and identifiers.
You could use a (inline) function returning the INVALID_HANDLE_VALUE wherever required. Regards Hartmut
participants (2)
-
Hartmut Kaiser
-
Julio M. Merino Vidal