David Abrahams writes:
* Class definition utilities
operators, noncopyable, base_from_member, compressed_pair
Wouldn't you like to have Iterators library here well?
Not particularly. I might look here for iterator definition tools but I'd also be inclined to look in a category for stuff related to the standard library.
Well, yeah, but do we really want to pretened that the library doesn't fit here when it clearly does, and make the user with whom the category "clicked" go rounds just because she will probably be willing to?
* Standard Library Enhancements - libraries that make the standard C++ library easier and safer to use or extend its capabilities in evolutionary ways. Many relieve frustrations commonly encountered when using the standard library (see also Functional Programming)
IO: io state saver, iostreams, format
What about Serialization?
Yeah, maybe.
Wouldn't it be the first place you'd look for it in?
Containers/data structures: assign, pointer container, array, bitset, multi_index, multi-array, tuple
Graph library, no?
IMO, there's no huge advantage in using the BGL if all you're looking for is a graph data structure. Coding one up by hand will probably give you something that's easier to work with. The strong reason to use the BGL is the algorithms.
I'd say that's up to the user to decide, but in any case you are right, having it listed in Algorithms as well is IMO a must.
Iterators: iterators, next/prior, range
Algorithms: minmax
What about String Algorithms?
Okay, you have a point there.
[..]
* System-level libraries
Program options, date-time, filesystem, threads, serialization, signals, pool, Python
I don't see the logic behind putting all these together (nor does the name speak for any of them). What's common between Threads and Date-time,
time :^)
or, for that matter, Signals and Python?
Often used to glue together large systems while keeping parts decoupled.
Or Filesystem and Pool?
Management of system resources.
Well, OK, I'm sure we can find _something_ common between any two libraries :). The question is, is this categorization helpful to people who are looking for, say, a date-time library? IMO, no. At least I would have never guessed to look for it under this category.
IMO "Concurrent Programming", "Memory" and "Inter-language support" were perfect names for their corresponding content (which you've all bundled here).
The problem is that categories with only one library in them are no help to the navigator.
FWIW, "Memory" currently has three entries: pool, smart_ptr, and utility/checked_delete. Perhaphs more importantly, a category can be helpful even if it only contains a single entry: it adds context to the library name. "Pool" might not necessarily have something to do with memory, but place it under a telling category and it's enough information to save the user from diving in just to find out that it's not what she thought it is. Same with the just accepted "Shmem". And then there is the factor of precedent: put Python on the list without categorizing it, and hardly anybody will give it a second thought beyond "Hmm, interesting". Put it as a single entry under "Inter-language support", and you've got people thinking about other language binding libraries they've used/developed/heard about and why they are not in Boost.
We might as well just move these libraries up to the top level. As I said, I was least convinced by this category, but I'm still not sure there's a better grouping.
I would: 1) Put Program Options and Serialization under "Standard Library Enhancements" / "Input/Output" and Program Options alone under "Standard Library Enhancements" / "Operating System Services" (see below). 2) Put Signals under "Functional Programming" (they _really_ should be present in the same category as Function). 3) Put Pool under "Standard Library Enhancements" / "Memory Management". 4) Put Threads under "Standard Library Enhancements" / "Concurrent Programming" and "Standard Library Enhancements" / "Operating System Services". 5) Put Date-time and Filesystem under "Standard Library Enhancements" / "Operating System Services" (admittedly borrowed from Python docs here: http://docs.python.org/lib/lib.html) 6) Put Python under "Inter-language support". 7) Get rid of the "System-level libraries" category. -- Aleksey Gurtovoy MetaCommunications Engineering