D graph library -- update

[H. S. Teoh]

On Thu, Jul 11, 2013 at 08:14:00PM +0200, w0rp wrote:
> I don't like it. Here is why.
> 
> 1. You can only use a size_t type as the vertex type. What about
> strings?
> 2. The distinction between directed and undirected graphs is made
> with an boolean type parameter? Why not an enum? Better yet, why not
> just use interfaces? (You are already using classes and garbage
> collected memory.)

I think an enum would be better.


> 3. I have to control the graph's capacity manually, and I can't use
> arbitrary numbers for edges.

Yeah, constraining the number of vertices/edges at ctor time is not
feasible. We need to have an implementation that allows modifying the
graph post-construction, such as adding edges. (Deleting may not be as
important, and may be tricky to implement, but there *are* use cases for
that too.)


> 4. Adding an edge doesn't add vertices.

Couldn't you just add vertices manually, since you already know what the
edge is?


> My most common use of graphs is to start from nothing, build from
> adding edges arbitrarily, usually from IDs which may be integers,
> and may be strings, and then use graph algorithms to gain some
> understanding of the relation between objects mapped to these IDs.
> With this library, this will be difficult or impossible.

Yeah we need to cater to this use case too.

However, you should be able to use a helper class/graph to collect all
vertices/edges, then create the library's graph type using that once all
the information is known (e.g. number of vertices/edges, etc.). I
wouldn't say this is impossible. Troublesome, yes, but definitely
possible.


T

-- 
He who sacrifices functionality for ease of use, loses both and deserves neither. -- Slashdotter