On Thu, 2008-09-04 at 14:27 -0500, Matt Griswold wrote: > * Andrew Stitcher <[EMAIL PROTECTED]> [09/04/08 12:49]: > > Also pthreads is well documented (in books even), and boost is still > > subject to change. If these things make it into the C++ standard lib as > > has been threatened then I'll argue strongly to use that, but I don't > > see any value in changing from pthread to boost for those platforms that > > are sufficiently posix. > > I was using sys/boost as a generic base for making the port(s), not > necessarily as a replacement to native or posix implementations. I included > the boost mutex stuff from Steve's windows port, and did time, socket, and > asyncIO/Poller also from boost lib. It's a quick and easy way for me to get a > cross compilable, portable qpidclient, and I figured if/when boost components > make it to libstdc++ it'll be a bonus. > > That aside, I tend agree with Alan, if it's as fast as the native > implementations, it seems like it would be easier to just have one version, > but that's up to you guys :) In my application performance isn't key for the > client side, I just need to have it working in Windows and OSX.
That's assuming we are starting from scratch! Our previous experience with some younger boost libraries is that they have not been sufficiently stable or functional and we've spent far too much time compensating for their deficiencies/changes (particularly program_options). Parts of boost are excellent, particularly the stuff that has now been accepted into C++0x, but parts are too immature to use in a project aiming for some stability. We need to distinguish these bits of boost. I'm not saying anything about the boost threading library, but we already have a pthreads solution, lets just use it on platforms that support it. Andrew
