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

Subject: Re: [boost] [Review] ITL review starts today, February 18th
From: Paul A. Bristow (pbristow_at_[hidden])
Date: 2010-03-01 13:58:11

> -----Original Message-----
> From: boost-bounces_at_[hidden] [mailto:boost-bounces_at_[hidden]] On
Behalf Of
> Phil Endecott
> Sent: Monday, March 01, 2010 5:54 PM
> To: boost_at_[hidden]
> Subject: Re: [boost] [Review] ITL review starts today, February 18th
> 
> 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).

OK - grovel - sorry - I've not been following the list carefully enough :-(

In this case my 'accusation' is entirely wrong - but it has occurred before.

Hopefully, there may still be potential for this optimisation in future - but I
doubt it's a trivial task.

Paul

Paul A. Bristow
Prizet Farmhouse
Kendal, UK   LA8 8AB
[phone], mobile [phone]
pbristow_at_[hidden]