Boost logo

Boost :

Subject: Re: [boost] GSoC 2010: Heaps and Queues
From: Dan Larkin (danielhlarkin_at_[hidden])
Date: 2010-04-09 11:36:14

Andrew Sutton wrote:
> Developing concepts is not a top-down process, nor is it a "chicken and the
> egg" problem. One way to look at concepts is that they describe common
> features of related kinds of types, although there is a much more precise
> way of saying this. How do you know the commonalities of heaps and/or queues
> if you haven't implemented any?
> It's always possible to guess, but why spend the time? The project is to
> implement data structures, not describe them.

Well, maybe I'm taking a non-standard development approach, but for me
the design process goes something like this:

- Research algorithm/structure
- Determine required functionality
- Design interface to reflect the relationship between the theory and
the implementation

If the previously established theory (which describes the structure)
groups a set of structures into a concept and group of "models" (sure,
they're still concepts themselves, but...) that all have a well defined
set of commonalities, it's not much of an issue to determine what they
are, is it? And doesn't a good design from the beginning make the
development process easier as time progresses? You end up with a much
more coherent library if you have a well-designed interface to which the
implementation conforms rather than an implementation that has an
interface slapped on top. And of course you can then define an
interface later and adapt all the pre-existing structures to match it,
but again - if you know at least approximately what the interface should
look like, why not start with it in mind? It keeps the code much cleaner.

I know that I can't say I've implemented all the heaps. Nor can I say
that I know exactly line for line how I will do so. But I can say that
I know approximately what functionality I want out of them, and this is
what I am trying to reflect with the abstract base class. It is still a
draft interface, and subject to change as I begin implementing the
various structures and seeing how differences may help to make the
library better. But I think it does need to exist from a design
decision standpoint.

Dan Larkin

Boost list run by bdawes at, gregod at, cpdaniel at, john at