April 2005 - Boost-users - lists.boost.org

Boost Graph Library and Boehm Garbage Collector
by FBSL 08 Sep '08

08 Sep '08

Hello I am having trouble to garbage-collect adjacency_list<>. I have instanciated it with correctly garbage-collected vectors and lists (I have copied vecS and listS definitions, and added Boehm GC's default allocator so that they are garbage-collected). In my application I need to dynamically allocate many graphs, but it does not work, there is a (big) memory leak. Unfortunately, there is no template argument in adjacency_list<> to specify Boehm GC's allocator. Does anyone have a hint ? Snippet code "main.cpp" follows, compiled with Boost Graph Library 1.32, Boehm GC 6.4 and G++ 3.3.5, with command line : $ g++ -o main main.cpp -lgc -lgccpp -- #include <boost/graph/adjacency_list.hpp> #include <gc/gc_allocator.h> #include <gc/gc_cpp.h> #include <iostream> #include <vector> #include <list> using namespace std; using namespace boost; namespace boost { struct collected_vecS {}; struct collected_listS {}; template <class ValueType> struct container_gen<collected_vecS, ValueType> { typedef vector<ValueType,gc_allocator<ValueType> > type; }; template <class ValueType> struct container_gen<collected_listS, ValueType> { typedef list<ValueType,gc_allocator<ValueType> > type; }; template <> struct parallel_edge_traits<collected_vecS> { typedef allow_parallel_edge_tag type; }; template <> struct parallel_edge_traits<collected_listS> { typedef allow_parallel_edge_tag type; }; namespace detail { template <> struct is_random_access<collected_vecS> { enum { value = true }; typedef true_type type; }; } } typedef adjacency_list<collected_vecS, collected_vecS, directedS, no_property, no_property, no_property, collected_listS> graph; int main() { // leaks... while(true){ graph * g=new (UseGC) graph; for(unsigned int i=0; i<100; ++i){ add_vertex(*g); } for(unsigned int i=0; i<100; ++i){ for(unsigned int j=0; j<100; ++j){ add_edge(i,j,*g); } } } }

3 4

BGL: INTERNAL COMPILER ERROR in VC7.1
by Yariv Tal 10 Jun '07

10 Jun '07

This one was already posted by Nicholas Burlett awhile back (see http://lists.boost.org/MailArchives/boost-users/msg06534.php) but I have some new info that may help. The problem: ========= When compiling code that uses the boost.graph library the VC7.1 compiler shouts: c:\boost_1_32_0\boost\mpl\aux_\preprocessed\plain\apply_wrap.hpp(48) : fatal error C1001: INTERNAL COMPILER ERROR As Nicholas already noted, this seems to be due to some compiler problem with the boost.graph out_edge_iterators since it is caused by the following lines in my code: (FilteredGraphGenerator::FilteredGraph is a typedef of a boost::filtered_graph) typedef boost::graph_traits<FilteredGraphGenerator::FilteredGraph> ::out_edge_iterator oedge_iterator; oedge_iterator edgesItr, edgesEnd; boost::tie(edgesItr, edgesEnd) = boost::out_edges(itr->first, m_g.m_filteredGraph); while (edgesItr != edgesEnd) { // do anything! } In fact, it seems to be related to the operator!= between iterators (if the while loop is commented out it compiles). How ever, the error persists even after changing the operator!= to operator== : while (edgesItr == edgesEnd) { // do anything! } ========================================================================== Some findings: =========== * We used to use boost_1_30_0 and the code used to compile PERFECTLY. The problem only appeared after migrating to boost_1_32_0. * Calling directly to the "equal" function in iterator_core_access instead of the operator== works. typedef boost::graph_traits<FilteredGraphGenerator::FilteredGraph> ::out_edge_iterator oedge_iterator; oedge_iterator edgesItr, edgesEnd; boost::tie(edgesItr, edgesEnd) = boost::out_edges(itr->first,m_g.m_filteredGraph); while (boost::iterator_core_access::equal(edgesItr, edgesEnd, boost::mpl::true_())) { // do somthing } * The error message location is at the mpl::apply_wrap2 function. Any relation to the mpl::apply2 function used for declaring the operator== in the BOOST_ITERATOR_FACADE_INTEROP_HEAD macro? Have these functions changed since v1.30.0?

9 8

Thread cancellation
by Chris Coleman 01 Sep '05

01 Sep '05

Hi, I know at present that the Boost Threads implementation does not provide a terminate() / cancel() function, but the documentation suggests that work is in progress to implement this feature once a safe and portable way is found. I was just wondering whether this will appear soon in future releases, or if it is likely to be some time? At present I can kill a thread internally by simply throwing an exception and not catching it. But externally I cannot. I have a thread pool server I built some time ago using the pthread API and I'm porting it to use Boost Threads. The server has add() and remove() thread methods. Within the remove function under the pthread implementation I could call pthread_cancel(thrID) and that would be that, Obviously I cant call thread.cancel() as I'd like here and was wondering if there were any simple ways to signify that a particular thread should terminate? Cheers Chris This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation.

9 16

strange filesystem dll behaviour
by Paul 28 Aug '05

28 Aug '05

Hi, I'm having killer problems with the filesystem library. I'm compiling it with bjam "-sTOOLS=mingw", which seems to work just fine. All the tests pass etc. Then I wrote this simple program: #include <boost/filesystem/path.hpp> #include <iostream> using namespace std; using namespace boost::filesystem; int main() { try { path p("c:",native); } catch (exception & e) { cerr << "Error: " << e.what() << endl; return 1; } cerr << "Ok" << endl; return 0; } and compiled it with the Makefile: test: test.cpp Makefile g++ -g -I../boost/boost-compiled -I. -Wall -c test.cpp g++ -g -Wl,-enable-stdcall-fixup -Wl,-subsystem,console -Wall -o test.exe test.o libboost_filesystem-mgw-d-1_32.lib g++ -g -Wl,-enable-stdcall-fixup -Wl,-subsystem,console -Wall -o test-dll.exe test.o -L. -lboost_filesystem-mgw-d-1_3 (adjust for your paths, I copied the dlls and libs into the local dir Just To Be Sure). The output of running the two programs is as follows: paul@xyz ~/test $ ./test Ok paul@xyz ~/test $ ./test-dll.exe Error: boost::filesystem::path: invalid name "c:" in path: "c:" Why does it behave differently depending on the linkage? If I must use a .lib, what if it needs to be used in multiple .dlls of mine? Help? Thanks Paul

3 10

boost::filesystem bug for win98
by Sebastien Martel 07 Jun '05

07 Jun '05

Hello, The windows implementation for find_first_file is flawed for windows 98. The problem is appending \* to the dir path: this is not supported for win98. Here is a possible fix that has been working for me quite well. inline const char * find_first_file( const char * dir, BOOST_HANDLE & handle, BOOST_SYSTEM_DIRECTORY_TYPE & data ) { // std::cout << "find_first_file " << dir << std::endl; // \* is not supported on win98 //std::string dirpath( std::string(dir) + "\\*" ); std::string dirpath( dir ); dirpath += ( dirpath.empty() || dirpath[dirpath.size()-1] != '\\' ) ? "\\*" : "*"; return ( (handle = ::FindFirstFileA( dirpath.c_str(), &data )) == BOOST_INVALID_HANDLE_VALUE ) ? 0 : data.cFileName; } -- Best regards, Sebastien mailto:smartel@real.com

2 1

BGL: copy graph & edge predicate question
by Sebastian Weber 19 May '05

19 May '05

Hello Everybody! I am trying to extract a part of a graph. Speaking in terms of the BGL, I do a copy from a filtered graph object into a new graph. To do so, I defined a VerticePredicate for the filtered graph. As a result not all vertices in the graph are present in the filtered version. This implies that some edges do disappear in the filtered version fo the graph. In order to copy from this filtered graph into a new, fresh graph via copy, do I have to use the following EdgePredicate? // edge predicate which only lets edges through which are part // of the given VerticePredicate template <class Graph, class VerticePredicate> struct edge_filter { typedef boost::graph_traits<Graph> Traits; typedef typename Traits::edge_descriptor Edge; // needs to be default-constructible ! edge_filter() { } edge_filter(Graph& g, VerticePredicate& vFilter) : m_g(&g), m_vFilter(&vFilter) {} bool operator()(const Edge& e) const { return (*m_vFilter)(boost::target(e,*m_g)) && (*m_vFilter)(boost::source(e,*m_g)); } private: Graph* m_g; VerticePredicate* m_vFilter; }; Or is this not necessary and implicitly done by the filtered graph interface? Another thing concernig the copy-function: Is there a way to NOT copy the vertice indices, but rather have the vertices renumbered from 1 to size of filtered graph? I guess I have to cope with the vertice_copier-function stuff, but I don't see how to do it. And another matter: The copy_component function does not seem to be documented. I found it by chance in the sources of copy.hpp. Thanks a lot! Sebastian Weber

2 1

Serialization, shared_ptr and namespaces
by Jan Eickmann 05 May '05

05 May '05

Hi, I'm trying to serialize a list of shared_ptr's to objects. Here's a summary of the code I have: namespace MyNamespace { class B { //implementation plus standard serialization function }; class A { private: list< shared_ptr<B> > myBs; public: template<class Archive> void serialize(Archive & ar, const unsigned int version) { ar & BOOST_SERIALIZATION_NVP(myBs); } }; } If I just try to serialize it, I get an unregistered_class exception. So I think I have to use BOOST_SHARED_POINTER_EXPORT(_GUID) to register the shared_ptr. When I include this inside the namespace (please note that the error messages are from my real code, so they have slightly other names: BOOST_SHARED_POINTER_EXPORT(B) I get this: f:\xenocide\xenocide\src\common\simulation\simulation.h(108) : error C2059: syntax error : 'string' f:\xenocide\xenocide\src\common\simulation\simulation.h(108) : error C2146: syntax error : missing ';' before identifier 'BOOST_CLASS_EXPORT_GUID' f:\xenocide\xenocide\src\common\simulation\simulation.h(108) : error C2059: syntax error : 'string' f:\xenocide\xenocide\src\common\simulation\simulation.h(109) : error C2143: syntax error : missing ';' before '}' When I put it outside the namespace I have to use a fully qualified name including the namespace for class B, so it becomes BOOST_SHARED_POINTER_EXPORT(MyNamespace::B) Then I get (not Xenocide is here what MyNamespace is in my example): f:\xenocide\xenocide\src\common\simulation\simulation.h(115) : error C2653: '__shared_ptr_Xenocide' : is not a class or namespace name f:\xenocide\xenocide\src\common\simulation\simulation.h(115) : error C2653: '__shared_ptr_Xenocide' : is not a class or namespace name I also tried various combinations with BOOST_SHARED_POINTER_EXPORT_GUID but it didn't help. Can someone explain to me how I have to declare shared_ptr's in order for them to work with boost::serialization? I was unable to find some more indepth documentation. Thanks, Jan Eickmann

4 5

Re: [Boost-users] Compatibility between shared_ptr and Rational RoseRT
by Ross Manges 05 May '05

05 May '05

> When running the executable under Rational Purify, it reports many FIM > errors (Freeing Invalid Memory), and all of these are again due to the > deletion of objects that were owned by a shared_ptr. Is your program (the code that uses shared_ptrs) running in multiple threads? I am seeing problems with my multithreaded code where the use_count in the shared_ptrs is not accurate and causing all sorts of problems. I'm even seeing core dump backtraces showing problems in the scoped_lock where the shared_ptr use_count is getting updated. It appears that there are a lot of restrictions on how shared_ptrs can be used in a multithreaded program, and I may be breaking some of those restrictions as it is easy to do so. In any case, let me know if you find a solution to your FIM errors. I have a feeling I'm seeing symptoms of the same problem. Thanks.

4 12

[MPL] is lambda<apply<...> >::type wrong?
by Vladim�r Marko 03 May '05

03 May '05

[using boost 1.32.0 with gcc 3.4.2 (mingw)] It seems to me that is_same< lambda<apply<type-list> >::type, apply<type-list> >::type::value is allways true. Is this intended or a bug? The exercise 1-6 in the MPL tutorial, http://www.boost.org/libs/mpl/doc/tutorial/exercises.html , reads "Build a lambda expression that has functionality equivalent to twice. Hint: mpl::apply is a metafunction!" where twice is defined as template <typename F,typename X> struct twice : apply<F,typename apply<F,X>::type> { }; and I think the obvious solution should be apply<_1,apply<_1,_2> > . The problem is that the expression apply< apply<_1,apply<_1,_2> >, add_pointer<_1>,int >::type doesn't compile at all. This is surprising since for example the expression apply< twice<_1,twice<_1,_2> >, add_pointer<_1>,int >::type yields int**** as expected. Is there some fundamental difference between the metafunctions twice and apply? My tests suggest that the compilation failure is caused by the property of lambda<apply<...> >::type described at the top. This seems pretty odd to me since lambda<T>::type is supposed to have a nested template class "apply" if T is a placeholder-expression and lambda<apply<type-list> >::type::apply refers to the boost::mpl::apply even if the type-list contains a placeholder-expression (making the whole apply<type-list> a placeholder-expression). Did I miss something? Thanks, Vladimir Marko

2 1

dijkstra_visitor
by Andreas Fabri 02 May '05

02 May '05

Hello, I wrote my own dijksta visitor for the shortest path algorithm, and on an event I wanted it to write something in a bundled property of a vertex. However this didn't compile because the graph is a const&. Is there a way to solve this problem? Thanks in advance, andreas

2 1