Re: [boost] Dynamic Bitset Formal Review June 8-17

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.