Boost logo

Boost :

From: David Abrahams (dave_at_[hidden])
Date: 2006-02-21 08:19:26


Aleksey Gurtovoy <agurtovoy_at_[hidden]> writes:

> David Abrahams writes:
>> Aleksey Gurtovoy <agurtovoy_at_[hidden]> writes:
>>
>>> David Abrahams writes:
>>>> Okay, let me take a shot at this. The category I'm least sure about
>>>> is "system-level." It feels right, but I can't justify it. This is
>>>> an attempt to fit everything into a single category, unlike Boost's
>>>> current list.
>>>
>>> With a specific rational in mind, or just because it seemed doable?
>>
>> Yeah, it seemed doable without really shortchanging any libraries.
>>
>>> Personally, I agreed with Beman at the time and still do
>>> (http://article.gmane.org/gmane.comp.lib.boost.devel/54545/):
>>>
>>> Incidentally, there is no law that says a library couldn't appear
>>> in more than one category. Remember that the objective isn't the
>>> categories themselves, but to help users locate libraries which
>>> might meet their need.
>>
>> I agree, but as it turns out, with the right categories I don't think
>> the cross-listing is helpful overall.
>
> I disagree, please see below.

OK.

>> I actually think it makes
>> things a little more confusing. Too much information.
>
> How is it "too much information", specifically, in the typical usage
> scenario the list tries to cover (user searching for a library in a
> particular domain)?
>
>
>> * 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.

>> * 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.

>>
>> 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.

>> Iterators: iterators, next/prior, range
>>
>> Algorithms: minmax
>
> What about String Algorithms?

Okay, you have a point there.

>>
>> * Functional Programming - libraries for working with functions and
>> function objects. Especially useful in conjunction with STL
>> algorithms, but any program can benefit from functional programming
>> idioms.
>>
>> lambda (see also bind), bind/mem_fn (see also lambda), functional
>> (deprecated), function
>>
>> * Numerics, number crunching, high-performance computing.
>>
>> CRC, functional/hash, random, rational, graph/property map,
>> interval, math, ublas
>>
>> * Testing and debugging
>>
>> timer, static_assert (see also MPL assert), concept check, test,
>>
>> * Parsing and Text Processing
>>
>> Regex, XPressive, Spirit, tokenizer, string_algo
>>
>> * 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.

> 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. 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.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk