Re: [boost] [interprocess] New snapshot and some explanations

From: Gennaro Prota (gennaro_prota_at_[hidden])
Date: 2006-08-08 15:49:43

On Sun, 06 Aug 2006 21:03:14 +0200, Ion Gaztañaga
<igaztanaga_at_[hidden]> wrote:

>> Since there are already synchronization primitives in Boost.Thread and 
>> in numerous other Boost libraries which roll their own, would it not be 
>> efficacious for Boost to develop a separate synchronization primitive 
>> library which then could be used by all other Boost libraries.
>
>Well, Boost.Thread and Boost.Interprocess aren't the libraries where 
>this synchronization should go?

I think Edward was just proposing more coordination between library
authors. I second that. Many times useful components are buried down
into a detail/ subdirectory somewhere, waiting for someone to refine
them and bring them to light. That usually never happens. When I come
upon similar situations (components which might be useful on their
own) I try to put them in the pending/ subdirectory, which at least
makes them a bit more visible; but in fact that has not proven to be a
solution.

>[...]
>
>Other libraries use their own synchronization primitives because they 
>don't want to link an external library or they don't want to have 
>dependencies. The first reason can be solved with a header only 
>implementation of Boost.Thread utilities, but the second reason will 
>always be there, I'm afraid. Anyway, I think that all Boost libraries 
>should try to use already developed Boost components,

I strongly disagree. It is IMHO a cost/benefits issue. If I just want
to output three or four messages to std::cout I don't bring in
boost::format, even if it comes handy; the main cost indeed is adding
another breakage source to my code, which largely outweighs the
syntactical benefit. Similarly I won't use boost::program_options just
to parse a few command line switches (typical in the facilities of our
tools/ subdir). OTOH, if my code largely deals with files and
directories then boost::filesystem is the preferred component to use;
of course I won't go re-implementing things which are already better
implemented there.

--
[ Gennaro Prota, C++ developer for hire ]