Subject: Re: [boost] boost::directx?
From: David Bergman (David.Bergman_at_[hidden])
Date: 2009-06-08 21:18:55
On Jun 8, 2009, at 8:47 PM, David Bergman wrote:
> The bulk are generic language-lifting tools, basically giving the
> programmer a greater vocabulary. And, even if I bashed math
> libraries a bit, I would classify the current (as of 1.39.0)
> libraries as (and I did go through each library, and might have
> counted wrong with a few units here and there):
> 1. Language Extensions - 60 (including Statechart and BGL, which
> are applicable much more often than the developer realizes)
> 2. Common Types & Features (often part of newer languages standard
> libraries) - 8 (Accumulate, Numeric Conversion, Date, Format,
> Random, Regex, Serialization, Xpressive)
> 3. OS Abstraction Layer - 8 (Filesystem, Asio, Interprocess,
> Iostreams, Pool, System, Thread, Timer)
> 4. Math - 8 (Interval, various Math libraries, Rational)
> 5. Other Specialized - 7 (CRC, GIL, MPI, Proto, Python, Spirit,
> uBLAS, Units)
> The first two categories can be characterized as bringing the
> language of C++ up to (and beyond) that of newer creations, where
> the third category is often part of such a standard library. The
> number of libraries belonging to those three categories is 76.
> The latter two categories are clearly domain-specific, though. The
> number of such libraries is 15.
> If you disagree with these figures, I welcome a revised table,
> otherwise we can clearly state that domain- and target-*agnostic*
> libraries constitute the bulk of Boost, by far.
>> We could say "OK, no more domain-specific libraries in
>> Boost!!!~!~1`~!!~111" but first we must formally define the domain of
>> libraries that are acceptable in Boost. Good luck with that. :)
> First of all, I do not understand why we would have to use profanity
> in stating that, but alright, I would definitely welcome such a
> decision, and it is quite easy; just see the table above. I would
> welcome exclusion of those 15 domain-specific libraries...
Looking even closer at the potentially domain-specific libraries
(those 15; I actually moved Spirit up to #2, I see now), we see tthat
12 of them belong to the domain of Scientific Computing.
So, if we state that "Boost is a set of language-enhancing libraries
along with the slight exception of one domain, scientific computing"
we are left with only three libraries. Three oucasts: CRC, Python and
GIL. The first one can easily be transitioned into category #2, and
then we are left with only two: Python and GIL. And the former one is
not even specific to any business domain. Let me put it this way: if
something like Boost.Python was suggested today, and by somebody
fairly new to the Boost community, it would not stand a chance to be
Going back to your challenge of formally defining the "admissible"
domains, where you even wished me good luck: there is only *one*
specific domain for which Boost includes support and that is
scientific computing, and even in such cases, the libraries should be
multi-platform as far as possible. This holds up to two tiny
exceptions, GIL and Python. And even those clearly exceptional cases
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk