On Thursday, 11 July 2013 at 18:14:01 UTC, 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?
This is a core graph type designed explicitly for speed and
efficiency. If you want string ids for vertices, it's better to
wrap this with maps from string to size_t and back again. Having
strings or other arbitrary data types involved in the core data
type will just be a nightmare space- and speed-wise.
2. The distinction between directed and undirected graphs is
made with an boolean type parameter? Why not an enum?
It is an enum.
why not just use interfaces? (You are already using classes and
garbage collected memory.)
It's in consideration. I haven't yet identified a clear need.
3. I have to control the graph's capacity manually, and I can't
use arbitrary numbers for edges.
4. Adding an edge doesn't add vertices.
Again, those things are probably best achieved by wrappers that
mediate the adding of edges.
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.
I understand those requirements, I just think that the core data
structure on which calculations are done is not the ideal place
to implement them.
(Sorry for terse replies, I'm writing on my phone...)
