Okay, I found the schedule which says 1.40 won't be out until August 1st. That doesn't work for me, so I decided to try pulling the necessary updates from the repository directly. I've got the new subgraph.hpp and many of the template errors have gone away. However, I'm still getting several errors relating to this bit of code: //=========================================================================== // Mutability Traits // Just pull the mutability traits form the underlying graph. Note that this // will probably fail (badly) for labeled graphs. template <typename G> struct graph_mutability_traits< subgraph<G> > { typedef typename graph_mutability_traits<G>::category category; }; In particular: subgraph.hpp(893) : error C2143: syntax error : missing ';' before '<' subgraph.hpp(893) : error C2059: syntax error : '<' subgraph.hpp(893) : error C2065: 'G' : undeclared identifier subgraph.hpp(893) : error C2143: syntax error : missing ';' before '{' subgraph.hpp(893) : error C2447: '{' : missing function header (old-style formal list?) Is there another file I have to grab to make this work?

On a (possibly) related note, I'm trying to use the above subgraph in kruskal_minimum_spanning_tree(), but it's giving me an error about

error C2039: 'vertex_bundled' : is not a member of 'boost::subgraph<Graph>'

This was patched in trunk, but didn't for some reason, it hasn't been merged into the release branch. It'll appear in 1.40. Andrew Sutton andrew.n.sutton@gmail.com _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

That appears to have done it, thanks. (I did have to grab graph_mutability_traits.hpp as well which I guess wasn't in 1.39.)

I've got the new subgraph.hpp and many of the template errors have gone away. However, I'm still getting several errors relating to this bit of code:

//=========================================================================== // Mutability Traits // Just pull the mutability traits form the underlying graph. Note that this // will probably fail (badly) for labeled graphs. template <typename G> struct graph_mutability_traits< subgraph<G> > { typedef typename graph_mutability_traits<G>::category category; };

In particular:

subgraph.hpp(893) : error C2143: syntax error : missing ';' before '<' subgraph.hpp(893) : error C2059: syntax error : '<' subgraph.hpp(893) : error C2065: 'G' : undeclared identifier subgraph.hpp(893) : error C2143: syntax error : missing ';' before '{' subgraph.hpp(893) : error C2447: '{' : missing function header (old-style formal list?)

You may have updated just before my last commit. I had to redistribute some include statements. I ran the entire test suite just before committing and everything built, so it /should/ be fine. Let me know if its not. Andrew Sutton andrew.n.sutton@gmail.com _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

FYI, the 2-argument version of add_vertex doesn't work on subgraphs. I suspect the same is true of the other functions that take properties objects.

That doesn't surprise me. I noticed that subgraph was failing one of the property tests in my new test harness just before I left school. I probably won't have a chance to take a good look why until Friday. Andrew Sutton andrew.n.sutton@gmail.com

The intention with regards to properties was never all that clear to me from the documentation, to be honest. I *thought* that each subgraph would have a local copy of all properties (as they were at subgraph creation time) and the modifying these would not change the properties of the corresponding global vertex/edge, and my code actually relies on this. Am I going to have to change my code design, either to accommodate the current design or a future fix?

FYI, the 2-argument version of add_vertex doesn't work on subgraphs. I

...

suspect the same is true of the other functions that take properties objects.

That doesn't surprise me. I noticed that subgraph was failing one of the property tests in my new test harness just before I left school. I probably won't have a chance to take a good look why until Friday.

After some digging (and trying to implement add_vertex(vp, g) for subgraphs), it turns out that that the bundled property support for subgraphs seems to be fundamentally broken - sorry Dmitry :) The fault really lies, I think, with the design of the subgraph class w.r.t. properties. Discussion follows: Every subgraph object keeps a pointer to its parent (the object being subgraphed) and a local graph. The problem is that the local is also declared to store the properties of the global graph so there are lots of places where property values could be applied to both vertices and edges. With non-bundled properties, the subgraph uses a speciialized property map that delegates requests for properties to the root graph. We probably need to duplicate this effort for bundled proprties. I'm going to reopen the ticket that was closed 4 years ago (#380). If anybody wants to take a stab at this, that would be great :) Otherwise, I'll probably work on this on Monday. Andrew Sutton andrew.n.sutton@gmail.com _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

More options are always welcome, so long as they're easy to specify. Incidentally, I believe there was a problem with placing edge_index_t edge_index in the bundled properties----it only worked when I used the (far uglier) joint internal/bundled property approach. Something else to put on the list.

The intention with regards to properties was never all that clear to me from the documentation, to be honest.

I *thought* that each subgraph would have a local copy of all properties (as they were at subgraph creation time) and the modifying these would not change the properties of the corresponding global vertex/edge, and my code actually relies on this.

Am I going to have to change my code design, either to accommodate the current design or a future fix?

Me neither. This is really my first time digging into subgraph. It makes sense (to me) that each vertex/edge should have only one property, but I can see reasons for localizing properties as well. If both are needed, I can create specializations of property_map that select local/global lookup strategies. Would that be acceptable? Andrew Sutton andrew.n.sutton@gmail.com _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

Hmm....I'll download that file and give it a try on Monday. I don't fully understand property maps. Aside from vertex_index, I haven't used get() for anything directly; I usually just do w = G[edge].edge_weight; or similar. And when using algorithms, I was able to figure out the property map parameters mainly be looking at what the examples did. So using the above access pattern, how would one differentiate a subgraph with "pass-through" property access versus one with local properties?

Incidentally, I believe there was a problem with placing edge_index_t edge_index in the bundled properties----it only worked when I used the (far uglier) joint internal/bundled property approach. Something else to put on the list.

I think I've run into this before. There was a problem with the property-deducing metafunctions that was failing if you gave a formally constructed bundle (of the form property). It should be fixed in trunk. Relevant changes are in boost/graph/properties.hpp. As far as options, I was think something like: typedef property_map >::type LocalPropMap; typedef property_map >::type GlobalPropMap; So specializations on local/global will automatically select lookup logic. I don't think I have to change anything else. Andrew Sutton andrew.n.sutton@gmail.com _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

As long as you're making changes to subgraph anyway, something that really bugs me about it is the necessity to make the root graph itself be of subgraph type. While I can understand the reasoning, it would be nice if there were a way to simply make the root be a shallow wrapper around any particular graph. I don't know how feasible this is, but I figured I'd ask.

w = G[edge].edge_weight; or similar.

And when using algorithms, I was able to figure out the property map parameters mainly be looking at what the examples did.

So using the above access pattern, how would one differentiate a subgraph with "pass-through" property access versus one with local properties?

Good question. I hadn't thought of that. Maybe something like: w = G[global(edge)].edge_weight // or w = G[local(edge)].edge_weight I think I can hack something like that together. As for default behavior... I'm leaning towards global properties, but I suppose I could control it with a preprocessor macro. Andrew Sutton andrew.n.sutton@gmail.com _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

My only concern with making global property access the default is whether that will break any existing code. Since the doc was unclear, I'm not sure if there's any good way to check that, except trying it and waiting for the complaints to role in.....

As long as you're making changes to subgraph anyway, something that really bugs me about it is the necessity to make the root graph itself be of subgraph type. While I can understand the reasoning, it would be nice if there were a way to simply make the root be a shallow wrapper around any particular graph.

I don't know how feasible this is, but I figured I'd ask.

It may be possible, but I'm not thinking too much about it right now. I've just committed the beginning of this work. Now you can write: g[v] -> returns the global bundle of v g[global(v)] -> returns the global bundle for v g[local(v)] -> returns the local bundle of v typedef property_map< Subgraph, local_subgraph_property

::type Map; Map pm = get(local(&Node::weight), g);

I'm not fully sold on the local_subgraph_property name. I could probably shorten it to local_property, and it would work just as well. I haven't built explicit support for global bundled properties, and I need to extend the same support to the old-style properties. Thoughts? Andrew Sutton andrew.n.sutton@gmail.com _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users