Re: [boost] [website] Proposal for new page - Libraries By Type

From: Aleksey Gurtovoy (agurtovoy_at_[hidden])
Date: 2006-02-22 04:39:16

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