On Thu, 02 Sep 2010 00:36:33 +0200, Ilya Sokolov <ilyasokol@gmail.com> wrote:
On 02.09.2010 2:09, Boris Schaeling wrote:
On Wed, 01 Sep 2010 23:51:07 +0200, Ilya Sokolov <ilyasokol@gmail.com> wrote:
I quote then the paragraph starting with "The benefits of using components from other libraries...". ;)
Anyway, while it all sounds good in theory how many developers are out there trying to use single Boost libraries without installing the others?
Actually, I wasn't thinking about such developers, but about compilation time (lexical cast and algo.str), portability and stability (filesystem).
It sounds like a bit too much effort reinventing what has been implemented in other Boost libraries for what I expect is a relatively small group of developers?
The dependencies I object to are easy to avoid.
Regarding boost::lexical_cast: There is to_string() in Boost.Uuid in 1.44 but not in 1.43. Or what were you thinking of?
I was thinking about sprintf or ostringstream. If you add async_pipe, there will be no need for Boost.Uuid
I don't want to give up named_pipe entirely as we don't know if someone has a need for it. I see then three possibilities: 1) Macro to exclude named_pipe 2) Move named_pipe to another header file 3) Move all behavior types to a subfolder called behavior and create a header file for each type Any preference? Or is it possible to detect whether a library is available? Are there somewhere (eg. in Boost.Config) macros defined like BOOST_LIBRARY_UUID? If it's not defined Boost.Process would know it shouldn't try to include boost/uuid.hpp. Boris