Aleksey Gurtovoy <agurtovoy@meta-comm.com> writes:
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?
Yeah, I sorta do. It fits here about as well as oil paints belong in a category called "things that come in colors." Yeah, it is accurate, but everything else in the category is completely general-purpose, and this one has a very specific purpose. If someone else had written the library I would have no problem allowing them to put it in as many categories as they wanted, but my sense is that the library and its users will be best served by putting it in one category that's closely associated with its purpose.
* 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?
If IO were a top-level category, yes, but no, I wouldn't look in "standard library enhancements/IO" for serialization.
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,
Absolutely. I don't object to cross-listing it here, but I am averse to "maximal cross-listing," at least for people trying to get a sense of what's in Boost.
* 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.
Yeah, maybe this goes to what Beth meant about "browsing vs. searching." My page is oriented toward browsing. And, IMO, if we don't do too much cross-listing there are still few enough libraries that the searcher can do all his work fairly efficiently with a browsing-oriented page. Once the list grows a lot, that will no longer be true.
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.
Good points.
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).
Huh, program options a standard library enhancement? Serialization an OS service? I guess, if you see it that way, it must fit for some fraction of people, but I don't get it.
2) Put Signals under "Functional Programming" (they _really_ should be present in the same category as Function).
Really? This is another one of those "it fits technically, but doesn't speak to the purpose of the lib" things for me.
3) Put Pool under "Standard Library Enhancements" / "Memory Management".
Okay.
4) Put Threads under "Standard Library Enhancements" / "Concurrent Programming" and "Standard Library Enhancements" / "Operating System Services".
Okay.
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)
Yep, good.
6) Put Python under "Inter-language support".
7) Get rid of the "System-level libraries" category.
Sounds like a good direction, though some of the individual choices don't make any sense to me. -- Dave Abrahams Boost Consulting www.boost-consulting.com