On Thu, 02 Sep 2010 22:58:27 +0200, Ilya Sokolov <ilyasokol@gmail.com> wrote:
On 03.09.2010 0:27, Boris Schaeling wrote:
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.
Sorry for my obscure explanations, I meant that we could have the following kinds of pipe:
- pipe (i.e. anonymous pipe) - named_pipe (requires a name as an argument, no need to generate it) - async_pipe - POSIX: typedef'ed to pipe - Windows: derived from named_pipe, uses UuidCreateSequential() for the random name
Ah, I see - makes sense. If you agree that boost::function<> makes even more sense (see my other posting today) I'll update Boost.Process accordingly. Boris