|
Boost : |
Subject: Re: [boost] Library categories
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2011-11-29 16:22:50
Le 29/11/11 19:37, Stewart, Robert a écrit :
> Vicente J. Botet Escriba wrote:
>> I was wondering if we can add other categories to the library catalog
>> (http://www.boost.org/users/history/version_1_47_0.html).
>>
>> Here is a proposal
>>
>> Domain Specific
>>
>> crc
>> units
>> uuid
> There have been complaints about "domain specific" being too vague, but code that is, by its nature, not as general as you'd expect to see in the Standard Library, fits. Having said that, Units seems to be more miscellaneous than domain specific. However, if "Math and Numerics" were just Math, then Units would fit there.
I agree that Units is less specific.
>
>> State Machines
>>
>> meta state machine
>> statechart
> That seems too small a group. Isn't a state machine a pattern?
Yes it is. We could move them.
>
>> System: libraries that are close to the underlying system
> Good
>
>> I would add also the following to exixting categories
>> Data structures
>>
>> optional - Discriminated-union wrapper for optional values, from
>> Fernando Cacciola.
>> tribool - 3-state boolean type library, from Doug Gregor.
> Perhaps "Simple Data Structures" would be a better name to disambiguate between data structures and containers.
Why not.
> Should Graph be in Containers? There aren't any containers in that library, are there?
Yes Graph fall better in Data structures IMO.
> I was going to state that a category with just one entry is unjustified, and one with but two entries is questionable. However, there's some value in having more categories, even with just one entry, since a searcher may not pick the same category as we do for a given library's functionality. Thus, while "Parsing" has just one entry, it is an important category and Spirit would be missed by someone looking for a parsing library.
>
>
>
Maybe we could just name the "String and Text Processing", "Text
Processing".
Best,
Vcente
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk