Boost logo

Boost :

From: Christoph Koegl (yahoo_at_[hidden])
Date: 2001-07-19 07:54:54


kevlin_at_[hidden] said:
> One of Boost's aims is to establish interfaces as opposed to
> implementations. If the only difference between any and any2 were to
> be in the representation, then it would simply be a quality of
> implementation issue, and not, I would submit, a case for a separate
> class.

I always thought that Boost's main objective was "to provide free peer-reviewed
portable libraries" and "provide reference implementations." In my opinion if there
are tradeoffs in terms of space/time complexity of possible implementations of some
interface it is simply careless to not clearly document these complexities in the
library interface, because performance characteristics are as important as "pure"
functional requirements. So, if a/the reference implementation of some interface is
biased in some way wrt. runtime/space complexity it is only fair to have competing
implementations that are biased in some other way. There may be the "average program-
mer" who is content to have just "some" implementation of a given interface, but
equally often (at least in my experience) one needs as much control over the concrete
performance of the implementation as possible (see various discussions about a heavily
parameterized smart pointer suite vs. THE smart pointer). Therefore I would love to
see alternative implementations for Boost interfaces whenever there are clear per-
formance tradeoffs (as is the case with D. Kuehls priority queue (beta) library).
The C++ standard also recognizes this and refrains from simply specifying some Set
interface, providing instead a much more fine-grained view on the abstract Set data
type (in terms of various refinements of the Set datatype, like sequences or
associative containers). The performance requirements of the C++ standard often very
narrowly limit the choices of underlying data structures conforming library implemen-
tations may make, so the boundary between "interface" and "implementation" is blurry
at best.

Cheers, Christoph


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk