On Tue, 22 Dec 2009, Arnaud Masserann wrote:

Where are you looking?  The line I see (in astar_search_no_init) is:

   MutableQueue Q(cost, index_in_heap, compare);

which doesn't require the number of vertices in advance.

So implicit graphs have been implemented since boost 1.39 ... Are you aware of any implementation notes, documentation, reference ? I'll give it a try tonight.  

I don't think there is separate documentation; allowing implicit graphs was a fix for a bug that was in Trac.

Notes : I use astar_search_no_init, and property maps based on std::map so that put() can index it in a not-known-yet location. Btw, my color map type is std::map (plus the wrapper around it). I feel that using "boost::default_color_type" is kind of a hack. Is it ?

The reason is that the normal Boost A* search avoids processing the same vertex twice by using a color map.  If you want the implicit graph version that appears in most textbooks, you need a dummy color map that claims that all vertices are unvisited.  So it is somewhat a workaround to allow the same algorithm to work for both cases.

That was not exactly my question. The thing is, I discovered the type "boost::default_color_type" while watching internal boost headers I'm not really supposed to look at as an end-user. I feel like I should have used something like boost::color_map::type or whatever. This would be exactly the same from the compiler's point of view, but the code would be better. More importantly, what are the logical steps I should have done to figure it out ?

You could define your own color type if you want as well. It would probably be difficult to figure out, though. It might be better to have a tree search version of A* that automatically does _no_init and a fake color map. Could you please submit a feature request on svn.boost.org for this functionality? Thank you. -- Jeremiah Willcock