
Boost : 
From: Douglas Gregor (gregod_at_[hidden])
Date: 20020904 08:49:16
On Wednesday 04 September 2002 06:07 am, Guillaume Melquiond wrote:
> I didn't say I had to reinvent the wheel. I just wanted to say that the
> complexity of such an implementation should be the object of a library
> built on the top of this one rather than added to the library (which is
> already quite complex).
That's fine. However, the ability for an interface to work well with multiple
data types is the essence of generic programming. We don't need to have a
data type that implements a list of intervals, but by considering the effect
of such a data type on the interface we can ensure that the interface would
be ready if someone were to write that data type.
The Graph library really shines in this area. The graph interface applies to
all of the Graph library classes, of course, but it can also be used with
graphs from other graph libraries and many other data structures that have
some graphlike view.
> > 4. It's obvious that if we use list of pairs instead of one pair all the
> > operation with intervals will take more time. But what if problem require
> > namely multiinterval values.
>
> Just use a specialized library. :)
> You don't expect this library to directly be able to do the static
> analysis of a program, or have functions able to solve a 100x100
> inequations system, do you?
I'd expect the library to give me an interface I can use to solve tasks using
intervals and to give me some concrete model of that interface. With such an
interface, I can write a static analysis that is parameterized by the
interval type:
template<typename Interval>
class interval_based_analysis
{
// ...
};
Actually, with a resolution of the comparison policies issue (such that we can
use tribool with the , I can implement most of generalized constant
propagation (a simple static analysis) in just a few lines of code. Maybe if
I get a chance to do this before the end of the review it will prove how
close the interval library is to supporting these other domains.
> Sorry, I don't understand your question. But I suppose you have understood
> that I think it is really not the job of this library to support such a
> monster (on the implementation point of view, and on the interface point
> of view!).
To summarize my view: it isn't the job of this library to provide an
implementation of the interval list that Gennadiy proposed, but we should
consider this type and its impact on the interface of this library.
Doug
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk