D graph library

H. S. Teoh hsteoh at quickfur.ath.cx
Wed May 22 16:55:28 PDT 2013


Hi, I'm back! :)


On Sat, May 11, 2013 at 07:34:50PM +0200, Joseph Rushton Wakeling wrote:
> On 05/11/2013 07:08 PM, H. S. Teoh wrote:
[...]
> > Aha. I think we found the source of contention here. You're thinking
> > about concrete graph types that can be used for general graph
> > applications, whereas I'm thinking of Phobos-style generic graph
> > algorithm *templates* that can process any graph-like type
> > satisfying certain requirements.
> 
> Yes, that seems to be the main source of our differences of opinion.
> I entirely agree with you about the need for generic graph algorithm
> templates, but we do need graph types as well, and most of my
> specifications were intended with those in mind.
[...]

Agreed. I think your suggestions as described in previous posts are good
for concrete graph data types provided by the library.

The algorithms themselves, of course, will obviously be geared toward
these data types, but where possible, they should be made generic so
that other data types satisfying the required APIs will be usable with
them. So I think writing them as templates parametrized on input graph
type (with signature constraints to ensure the type is usable with the
algorithm) would be the way to go.

And since the algorithms themselves will be templates, if the library
exports, say, BipartiteGraph, then that can be a dedicated bipartite
graph type that doesn't need to have any relation (though it could if it
improves the implementation) to more general graph types. Some
optimizations specific to bipartite graphs can be used in the
implementation, for example.


T

-- 
Windows: the ultimate triumph of marketing over technology. -- Adrian von Bidder


More information about the Digitalmars-d mailing list