On 15.06.2013 10:10, John Maddock wrote:
I used to see Boost as an empowering library, enhancing and evening out the playing field among the compilers out there.
Some seem to see it as a playground to gain recognition and fast-track things into the coming standard libraries, instead of producing something usable in the real world.
Ouch. Boost has always been about championing the "next thing" and always been ahead of the compiler curve, if that wasn't the case we'd still be targetting VC6. Yesterdays bleading edge is tomorrows mainstream.
Just a few cents from a "Boost user", as a "core dev" in a small but active open source project. The short version: I don't mind new Boost libraries being C++11-only, if they are clearly marked as such. The long version: The "bleeding edge" you talk about is why Boost is a painful dependency to have, at least in our experience. It's monolithic structure does not help either. That said there's a lot of really nice and useful libraries in Boost, so we accept the pain. Since I also work on a volunteer basis on this open source project, I appreciate that maintaining compatibility is a difficult balancing act, given the potentially high opportunity cost vs implementing new, useful features. So, as a Boost user, what I'd like to see is a clear status for each project, concerning - Compiler support: I wouldn't mind C++11-only "leaf libraries" (that's not a dependency of a non-C++11 library) if they are clearly marked as such. Also is any effort spent on supporting a wider set of compilers and platforms, or "just the usual suspects"? I don't have big issues with limited compiler/platform support as long as it's not a core library and it's clearly marked. - Maintenance: Is the library maintained, and if so, at what level? Are only supplied patches applied? Or is there a maintainer who will actively try to fix bugs. IOStreams for example seems a bit lost at sea at the moment, with issues lingering. I didn't know how bad it was until I ran into a few serious issues after writing considerable code relying on IOStreams some time ago. I ended up having to replace the IOStreams code with my own. - Inter-depdendencies: A list of which other Boost libraries a given library depends on, so I could check the above for the dependencies. Ideally a brief version of the first two points would be listed in the main "Boost Libraries" overview. With this information it would be easier to determine if a Boost library is suitable to be used by us for our project. Anyway just my 2 cents, and in any case thanks to all the devs here for their great work. Cheers - Asbjørn