Boost logo

Boost :

Subject: Re: [boost] [parameter] Boost.Graph program not responding at run-time
From: Lorenzo Caminiti (lorcaminiti_at_[hidden])
Date: 2011-12-03 16:11:40

On Sat, Dec 3, 2011 at 3:16 PM, Jeremiah Willcock <jewillco_at_[hidden]> wrote:
> On Sat, 3 Dec 2011, Lorenzo Caminiti wrote:
>> On Sat, Dec 3, 2011 at 2:28 PM, Jeremiah Willcock <jewillco_at_[hidden]>
>> wrote:
>>> On Sat, 3 Dec 2011, Lorenzo Caminiti wrote:
>>>> If I move the call to boost::depth_first_search into a template
>>>> depth_first_search_impl and out of the Boost.Parameter function body,
>>>> the code compiles (both MSVC and GCC with latest Boost from trunk) but
>>>> the executable runs forever and prints nothing to cout... What am I
>>>> doing wrong?
>>> I tried your code with GCC 4.6.0 and it worked just fine as you pasted it
>>> below.  I get:
>>> order of discovery: u v y x w z
>>> order of finish: x y v u z w
>>> as the result.  You are returning an invalid pointer from
>>> default_color_map(), though; &colors[0] becomes invalid when colors is
>>> destroyed at the end of the function.
>> Oops... thanks, that was actually the issue, after I fixed the invalid
>> pointer the code runs fine.
>> BTW, what's the best way to generate a default_color_map for
>> Boost.Graph like the one below?
> Probably the simplest is to use shared_array_property_map; you can return
> those from functions as shallow copies.  If you write the default code in

Something like this? But this gives me again the run-time error...

template< typename Size, typename IndexMap >
boost::iterator_property_map<boost::default_color_type*, IndexMap,
        boost::default_color_type, boost::default_color_type&>
default_color_map ( Size const& num_vertices, IndexMap const& index_map )
            IndexMap> colors(num_vertices, index_map);
    return &colors[0];

> your DFS function itself, you can create the vector there and pass an
> iterator_property_map to the underlying DFS code (that is what the current
> parameter defaulting code does).


Boost list run by bdawes at, gregod at, cpdaniel at, john at