Re: [boost] boost::directx?

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  
considered ;-)

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  
are multi-platform.

/David