[graph] about subgraph

Hello all, I would like to share my thoughts about the subgraph facility provided in the graph library. I have dived in it during the past few days because it looked nice, and it seemed to do what I was willing to do (that is, being able to work on various parts of the root graph while maintaining useful invariant). However, I have stumbled on surprising difficulties (I mean I would not have anticipated them from a boost component) : - The subgraph does not support serialization. In my opinion, it is a key feature for any kind of container. I found a broken version on the web and (as far as I can tell) fixed it, but it still seems to me that it is lacking from the original component. - The copy constructor is broken (see https://svn.boost.org/trac/boost/ticket/6564 but I see my comment on the second necessary patch was not sent, the bottom line is the original copy constructor led to errors when working on the copied graph). It is a central function, the fact that it has been broken without anyone but me noticing thus far leads me to think that a/ I am even less competent than I think I am in programming or b/ not many people use subgraph. - The remove_vertex is not implemented, and will not be (see https://svn.boost.org/trac/boost/ticket/4752 ). I was again very surprised when I discovered that, it was really an obvious function, the kind that justify for me the use of subgraph. And, reading further on the commentary for that "wont fix bug", the suggestion from jewillco of using a filtered_graph instead is perfectly relevant for my case. Nevertheless, I would rather have read such suggestion on the doc before chosing my component than at this quite late point. So I have one question and one suggestion to you boost (graph (subgraph)) developers : - Don't you think, given the lack of tests/users and the the missing features, that subgraph should leave the library ? - I think, if it stays, that the documentation should emphasize these points, and especially the last point : that filtered_graph is often a better solution. As a final note, I feel a little bit out of my place since I have absolutely no legitimacy criticizing the work of people who are by far more competent than me in computer sciences, so I won't feel offended if you point out that I am totally wrong. sincerey yours, -- Ernest Galbrun
participants (1)
-
Ernest Galbrun