Re: [boost] Core libraries should separated from experimentallibraries

Subject: Re: [boost] Core libraries should separated from experimentallibraries
From: Christian Schladetsch (christian.schladetsch_at_[hidden])
Date: 2009-11-26 04:51:35

Coming from a game-dev background I think I have something to add here.

It may be surprising, but traditional game development, rather than being
all glamorous and using the latest technology, is quite the opposite. Sure,
we use the latest hardware and API's, but those API's are often written in
C, or, lately, very conservative C++.

No game middleware that I am aware of uses even STL let alone boost. I
worked at EA for a while, and they had their own version of STL called
EASTL.

Why?

Because it is all about the known versus the unknown. C is known. Basic C++
(without vtbls and templates) is known. You can get any super-smart kid off
the street with a C background and he'll be very comfortable with the latest
and greatest game software. No meta required (or desired).

Again; Why is that? Why is it that the game development community, lauded
for being on the bleeding edge, rejects what we would call modern C++? How
can we build all this quite obviously complicated software without the
latest and greatest methodologies?

Thanks for bearing with me to my punchline: the gamedev community only cares
about results and deadlines. They don't have time to risk new things until
and unless they have become ubiquitous.

As an aside, back in 94 when I started, I remember having an argument with
my seniors about the use of C in gamedev. Apparently, C was too high-level;
it used the stack too much for 'every single function call'. Later I had a
similar argument about using C++ virtual methods; and later still and far
more recently I've had arguments about RTTI and exceptions. Sometimes I've
been swayed.

Back to my point and this thread. Adding new things has a cost. This cost is
not always obvious.

Boost has suffered from the opposite of the game-dev scenario: rather than
being too conservative, boost has been too liberal and academic. Where
gamedev eschews fancy meta-programming for a basic bison or ANTLR script or
fast and accurate and specific solutions, and while it does actually care
for cross-platform support[1], boost is necessarily confined to the pure C++
model and genericity.

Again, it seems plausible for boost to introduce a formal staging namespace
such as boost::stage or boost::sandbox. Everything in boost:: would be known
and correct across all tested configurations. boost::stage would be known to
contain experimental or less-than-two-releases-old source.

Call it boost::t_minus_2 or something; the main point is that change is
costly, and it is good practice to stage it.

Regards,
Christian

[1] This may be a surprising sentiment; but game-dev is not really concerned
with cross-platform development in general. Rather, we either make a
platform that you use or more likely just #idef the two platforms supported.
Yes, it gets ugly. But it's uglier to try to create a synthesised platform
that tries to expose the properties of both without compromising either.

On Thu, Nov 26, 2009 at 2:56 AM, Raymond Wan <r.wan_at_[hidden]> wrote:

>
> Hi all,
>
>
>
> Stefan Seefeld wrote:
>
>> In short: There is a great variability in technical and non-technical
>> aspects of boost components, which IMO suggest that running them as
>> individual projects would be beneficial to everybody. I believe this could
>> all be done within the Boost.org umbrella, but with more autonomy to
>> sub-projects.
>>
>
> Perhaps just stating the obvious, but in response to earlier comments by
> others about how other languages have many libraries, Perl's CPAN has the
> modules all separated and can handle dependencies well so that only they are
> downloaded.  I've actually heard people say that they do not want to use
> boost because "it is so large" and "I don't want to download it all just to
> use one part of it".  Actually, the more likely comment is "I don't want to
> use it so that my users will have to download all of it"
>
> Personally, there are many boost libraries that I know I will never use but
> I don't mind installing them since the space they occupy is nothing compared
> to my core files :-P .  But for many others, I wonder if this monolithic
> nature of boost could hurt it as it gets larger and larger...
>
> Of course, this is hard to do...but maybe in the short run, it would be
> nice to:
>
> * indicate for each library what other library it depends on or recommends
>
> * assign a status to each library indicating how well it is maintained or
> its stability and if it needs help
>
> Is there some kind of "gantt chart" on boost.org that has the version
> numbers along the x-axis and each library on the y-axis and a dots showing
> when it was updated [perhaps colored to show if the updates are minor or
> major -- could break software that uses it].  Might be an interesting first
> step?
>
> Ray
>
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>