Subject: Re: [boost] [gsoc] Boost.Process done
From: Ilya Sokolov (ilyasokol_at_[hidden])
Date: 2010-09-01 10:32:58
On 01.09.2010 14:51, Stewart, Robert wrote:
> Boris Schaeling wrote:
>> On Tue, 31 Aug 2010 14:48:43 +0200, Ilya Sokolov wrote:
>>>> In general Boost.Process depends on these header files
>>>> from other Boost C++ libraries:
>>> I don't think its use is justified.
> You should clearly state your grounds for the objection.
Ok, see my other reply.
>> Quickly checked what is used where: find_executable_in_path() uses
>> boost::algorithm::ends_with() and boost::algorithm::iends_with().
>> find_executable_in_path() throws
>> boost::filesystem::filesystem_error() if a program isn't found in
>> PATH. boost::lexical_cast is used by named_pipe to convert the
>> UUID (from Boost.Uuid) to a std::string.
> That code from the included headers is used is, indeed, justification
> for their inclusion.
> Any argument against that functionality should include an alternative
> implementation of the required functionality
> and a justification for choosing the alternatives.
>> Regarding the header files above: I wonder whether it makes
>> sense to get rid of actual helpful functions like
>> boost::algorithm::ends_with() only to remove a dependency on
>> another Boost library. I understand the case about
>> Boost.Filesystem which requires to be built. But it's a kind
>> of strange goal for Boost libraries to reuse as little code
>> as possible from other Boost libraries?
> I agree. This has reared its head before. While gratuitous
> and superfluous dependencies should be avoided, the whole point
> of Boost is to provide ready made, well tested libraries of
> reusable code. If one Boost library cannot use another,
> why would we expect anyone else to use Boost libraries?
Why would we expect anyone to use some Boost library, if its usage
is impossible without all other Boost libraries?
> A dependency on Boost.Filesystem is reasonable to avoid, if
> possible, because it means Boost.Process could no longer be
> considered header only. However, filesystem_error seems
> a perfectly logical choice and, I presume, it would be
> expected by anyone already using Boost.Filesystem. More significantly,
> there was some mention of using boost::filesystem::path, IIRC,
> so the dependency exists independent of that error type.
"some mention of using boost::filesystem::path" doesn't mean
that "the dependency exists independent of that error type".