Changes between Version 9 and Version 10 of soc/2007/UserFriendlyGraph


Ignore:
Timestamp:
May 17, 2007, 9:00:34 PM (15 years ago)
Author:
Andrew Sutton
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • soc/2007/UserFriendlyGraph

    v9 v10  
     1= User Friendly Graphs and Their Measures =
    12I am using this place to publish thoughts and updates about the design and implementation of this project. If you happen to be reading this and have some comments about the content, ideas, or questions, please leave them here - I'd like to read them.
    23
     
    78[wiki:soc/2007/UserFriendlyGraphNewAlgorithms This] is a discussion of the several new algorithms (mostly just property computations) of graphs.
    89
    9 == Documentation and Other Niceties ==
    10 It seems to me that the Boost.Graph documentation has gotten a little stale and needs a face-lift (i.e., rewrite to quickbook). There are also some older parts of the documentation that don't appear to align with current practice - especially those parts related to internal or bundled properties. If you read closely, you get the idea that bundled properties are the preferred technique, but they have yet to earn an entry into the table of contents.
    11 
    12 (Jeremy: yes, it would be good to make the bundled properties more visible and better documented.)
    13 
    14 Of course, the documentation isn't the only place where Boost.Graph doesn't align with the rest of Boost. For example, there is not `boost::graph` namespace. While this isn't exactly a tragedy for the ages, it would provide a clean separation from the rest of Boost. I am considering implementing my `[un]directed_graph`s in a `boost::graph` namespace.
    15 
    16 (Jeremy: yes, I'm in favor of going with a `boost::graph` namespace. It turns out that back when the BGL
    17 was added to Boost we had not yet developed boost guidelines for namespace use.)
    18 
    19 Another advantage of adding the `boost::graph` namespace is that it provides a mechansim for doing some other interesting things like reordering the parameters of common Boost.Graph function calls. One of my biggest complaints when I started learning the library was that the graph was always passed as the last argument in these functions. This doesn't really mesh well with the common "C-style" object-oriented approach where the type of the first parameter generally indicates the type to which said function would belong as a method. Is it really that big of a deal? I don't know... but it would be pretty easy to reorder parameters likes this (for example):
    20 
    21 {{{
    22 #!cpp
    23 namespace boost {
    24   namespace graph {
    25     template <class C>
    26     inline std::pair<typename C::edge_descriptor, bool>
    27     add_edge(boost::directed_graph_helper<C>& g, typename C::vertex_descriptor u, C::vertex_descriptor v)
    28     {
    29       return boost::add_edge(u, v, g);
    30     }
    31   }
    32 }
    33 }}}
    34 
    35 Just a thought... There's probably some reason why this might break that I haven't thought of. And yes... that's what the signature of the `add_edge()` function actually looks like for directed graphs.
    36 
    37 (Jeremy: I'm not a fan of changing the parameter ordering as that change would have to propagate
    38 throughout the BGL, and it would break lots of user code.)
     10== Documentation, Etc. ==
     11[wiki:soc/2007/UserFriendlyGraphNewDocs This] is a discussion of other (mostly documentary) aspects of the Boost Graph Library.