From: Dan'l Miller (optikos_at_[hidden])
Date: 2002-06-12 22:12:06
from Jeremy Siek <jsiek_at_[hidden]>
> I would appreciate it if you refrained from using Stepanov's name to back
> up your arguments, unless you have in fact talked with him about
> boost::dyn_bitset and can quote him.
I would appreciate it if you were to negotiate each of your incremental post-C++98 evolutions of STL with either someone at SGI (or even STLport) in a team-oriented approach. I would apprecieate it if either 1) dyn_bitset were to appear as part of SGI STL or 2) an SGI STL alternative displaced boost::dyn_bitset. Prior to my defect report during this review, did you or did you not consult with Alexander Stepanov regarding boost::dyn_bitset? Prior to my defect report during this review, did you or did you not consult with Alexander Stepanov regarding whether post-C++98 evolution of STL should be housed in only SGI STL or in only Boost or in both?
STL is a great achievement for humankind. If STL were to fork into various competing pseudo-normative factions, it would be a loss. Boost and SGI (and STLport) must keep all post-C++98 evolutions of STL in sync so that we continue to have one lineage of STL.
> I'm glad that you are concerned about new libraries conforming to the "STL
> vision". I agree that when considering new libraries we should take a
> serious look at how well they interact with the STL, and whether they make
> use of generic programming when appropriate. I feel that I have a fairly
> good grasp of what is the "STL vision". I worked for Alex Stepanov at SGI,
> in the C++ compiler and libraries group, and Alex was a big supporter of
> my master's thesis work, the Matrix Template Library. Further, he recently
> endorsed my book about the Boost Graph Library by writing the foreward.
None of these relationships prior to boost::dyn_bitset is the same as any progenitor of STL endorsing boost::dyn_bitset as part of the intended post-C++98 evolution of STL.
The question which comes to mind is:
Is the Boost community attempting to wrest control of the post-C++98 evolution of STL away from SGI STL?
If not, then Boost must work together with SGI STL as an overtly-cohesive team.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk