Re: [boost] [Review] ITL review starts today, February 18th

Subject: Re: [boost] [Review] ITL review starts today, February 18th
From: Phil Endecott (spam_from_boost_dev_at_[hidden])
Date: 2010-03-01 12:53:53

Hi Paul,

Paul A. Bristow wrote:
> I note some reservations and discussion about the underlying storage that might
> be a problem with large scale projects.
>
> It doesn't seem to be practical problem for some reasonably large scaled
> projects, and a different framework might very well have other disadvantages.
> So I don't think this is a reason to put the library on hold now.
>
> (Aside - I note that this is yet another example of a reviewer coming up with a
> fundamental objection that would been very much better aired a very long time [ago?]

I first raised my concerns in March 2009 when Joachim announced 
"preview 4" and asked for feedback.  I was one of only two people to 
post comments at that time.  See 
http://lists.boost.org/Archives/boost/2009/03/149365.php .

Prior to that, in July 2008 Dave Abrahams mentioned an interval tree 
that he had written 
(http://lists.boost.org/Archives/boost/2008/07/140452.php) and in 
reply, Joachim wrote 
(http://lists.boost.org/Archives/boost/2008/08/140653.php) :

  "You [Dave] mention your own implementation of an interval map using rb-trees.
   As you might have noticed my library implements interval sets finally
   via std::sets and interval_maps via std::maps. I am well aware that a
   specifically tailored interval tree has an optimization potential over
   a std::container implementation. So this is also on my todo list. Yet
   I wanted to focus on design, clarity and correctness first before
   improving performance using a more optimally tailored implementation."

So as you can see, this fundamental issue was indeed raised a very long 
time ago (in fact just 3 months after the library was first mentioned), 
and Joachim re-assured us that he knew about the issues with his design 
and that he intended to rectify them.

> OK.  I believe this would be less likely to happen if 'candidate libraries' were
> more exposed to public view, and acquire more users who could spot weaknesses.

More users can certainly help to spot problems, but in this case the 
issue is not that the problem was not spotted.

> I also can be very sympathetic to authors who won't want to go back to square
> one at this point in the process.  They or others (Phil? ;-) - are more likely
> to do this with real uses and real uses waiting).

Regards,  Phil.