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
