On 01.09.2010 2:41, Boris Schaeling wrote:
On Tue, 31 Aug 2010 14:48:43 +0200, Ilya Sokolov <ilyasokol@gmail.com> wrote:
On 25.08.2010 23:36, Boris Schaeling wrote:
In general Boost.Process depends on these header files from other Boost C++ libraries:
boost/algorithm/string/predicate.hpp
I don't think its use is justified.
Quickly checked what is used where: find_executable_in_path() uses boost::algorithm::ends_with() and boost::algorithm::iends_with().
Both usages could be replaced with two or three lines, while boost/algorithm/string/predicate.hpp depends on Boost.Range, which depends on Boost.TypeTraits, Boost.MPL and so on.
boost/filesystem/path.hpp boost/lexical_cast.hpp
ditto
find_executable_in_path() throws boost::filesystem::filesystem_error() if a program isn't found in PATH.
IMO, it doesn't matter what find_executable_in_path() throws, it could be any other class without any pain for users.
boost::lexical_cast is used by named_pipe to convert the UUID (from Boost.Uuid) to a std::string.
boost/lexical_cast.hpp includes almost everything.
boost/preprocessor/stringize.hpp
BOOST_STRINGIZE (from Boost.Config) could be used instead of BOOST_PP_STRINGIZE
Changed.
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?
"Negative effects of coupling become obvious when one library uses a second library which uses a third, and so on. The worst form of coupling requires the user understand each of the coupled libraries. Coupling may also reduce the portability of a library - even in case when all used libraries are self-sufficient..." http://www.boost.org/development/reuse.html