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

From: Aleksey Gurtovoy (agurtovoy_at_[hidden])
Date: 2006-02-20 23:39:03

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.

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

>
> * Language Enhancements - libraries that make the standard C++ core
>   language easier and safer to use, or extend its capabilities in
>   "language-like" ways.  Many relieve common frustrations of
>   programmers with the C++ language.
>
>     Datatypes: variant, optional/in-place-factories, tribool, integer
>
>     Language extensions: foreach, enable_if, parameter, ref
>
>     Safety: conversion, value_initialized, checked_delete,
>
> * 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?

>
>     Containers/data structures: 
>       assign, pointer container, array, bitset, multi_index,
>       multi-array, tuple

Graph library, no?

>
>     Iterators: iterators, next/prior, range
>
>     Algorithms: minmax

What about String Algorithms?

>
> * 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, or, for that matter, Signals and Python? Or Filesystem and
Pool?

IMO "Concurrent Programming", "Memory" and "Inter-language support"
were perfect names for their corresponding content (which you've all
bundled here).

>
> * Code Generation
>
>     Preprocessor, wave
>
> * Type information, synthesis, and computation
>
>     Type Traits, Call Traits, MPL

A bit too abstract for my taste, but I don't have better suggestions
at the moment.

>
> * Portability
>
>     compatibility, config

-- 
Aleksey Gurtovoy
MetaCommunications Engineering