Subject: Re: [boost] [Review] ITL review starts today, February 18th
From: Joachim Faulhaber (afojgo_at_[hidden])
Date: 2010-03-01 12:13:07
thank you again for reviewing my library.
2010/2/28 vicente.botet <vicente.botet_at_[hidden]>
> ----- Original Message -----
> From: "Hartmut Kaiser" <hartmut.kaiser_at_[hidden]>
> To: <boost_at_[hidden]>; <boost-announce_at_[hidden]>; <
> Sent: Thursday, February 18, 2010 2:22 PM
> Subject: [boost] [Review] ITL review starts today, February 18th
> > The formal review of the Interval Template Library (ITL) starts today,
> > February 18th, 2010 and will end February 27th, 2010.
> > ITL is being developed by Joachim Faulhaber.
> > ------------------------------------------------
> > - What is your evaluation of the design?
> I think the library must made a clear distinction between continuous and
> discrete intervals, as we are unable to iterate on continuous interval_set
> using the element iterators.
> As other have suggested, the template parameter domain must follow some
> basic interval requirements, in particular the separation between compile
> time and run-time bound checking.
> I am not completely sure, if I understand you correctly here. But in any
case, in the discussion with Jeff Flinn I already wrote, that I can simplify
the usage of own interval class templates, particularly interval types that
require an integral element_type with static bounds, no dynamic bound
setting and without memory overhead for dynamic bound_types. I hope that
this will make you happy as well ;-)
> I have taken some time to undesrstand the subtilities of the different
> interval combining styles. Once understood I think all these are useful
> > - What is your evaluation of the documentation?
> Even if the examples show a lot of things, a tutorial will allow you to
> explain how to do specific things, starting from basic uses cases and going
> to more advanced ones.
> As noted off-list, the hint parameter of the map insert function is
> will be done shortly.
> > - What is your evaluation of the potential usefulness of the library?
> In particular I had two uses cases of this library
> * Storage of sparse free local unique identifiers (see Boost.LUID on the
> * Map memory areas (representing variables) to the transactional cache (in
> Boost.STM). The memory areas can not overlap as the represent
> the memory occuped by variables, but a memory area can be embedded on
> another, the memory of a field is embedded
> on the struct variable.
> The variable stored in the maps contains already the size of the variable,
> and the interval are all of the same type, so the run-time check about the
> bound types could be avoided in this case.
> Both use cases can be implemented using the library.
> > - Did you try to use the library? With what compiler? Did you have any
> > problems?
> I have tryed to implemented the map memory area without not too much
> issues, but I had no time to comile and test :(.
> > - How much effort did you put into your evaluation? A glance? A quick
> > reading? In-depth study?
> I've followed the library evolution since its first announcement, and I
> have do a quick reading of the last documentation.
> > - Are you knowledgeable about the problem domain?
> I have never need to work with continuous intervals, so I don't knwo the
> subtilities of this doamin. However I have already
> implemented maps and set of intervals and I find that Boost.ITL do this
> task much better than my in house implementation.
> +1/2. I consider that Boost.ITL must be accepted provisionaly and should be
> accepted after a fast review once
> the modification I and others have suggest are taken in account.
I hope you can benefit from the ITL in your projects, specifically
Boost.STM. This seems to be a very interesting use case.