On Sun, 06 Aug 2006 21:03:14 +0200, Ion Gaztañaga <igaztanaga@gmail.com> 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 ]