May 2005 - Boost-users - lists.preview.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

Building boost for 64-bit on AIX
by Patrik Jonsson 17 Aug '06

17 Aug '06

Hi, I'm trying to build boost (1.32.0) on an IBM SP2 under AIX5, using the 64-bit ABI. This is troublesome. I do: bjam "-sTOOLS=gcc" "-sGXX=g++ -maix64 -pthread" --prefix=$HOME --libdir=$HOME/lib64-gcc --includedir=$HOME/include-gcc install But it doesn't work. I get loads of errors like: gcc-Link-action bin/boost/libs/date_time/build/libboost_date_time.so/gcc/debug/shared-linkable-true/libboost_date_time-gcc-d-1_32.so ld: 0711-738 ERROR: Input file bin/boost/libs/date_time/build/libboost_date_time.so/gcc/debug/shared-linkable-true/greg_month.o: XCOFF32 object files are not allowed in 64-bit mode. collect2: ld returned 8 exit status set -e LIBPATH=bin/boost/libs/date_time/build/libboost_date_time.so/gcc/debug/shared-linkable-true:$LIBPATH export LIBPATH "g++" -maix64 -pthread -g -fPIC -shared -o "bin/boost/libs/date_time/build/libboost_date_time.so/gcc/debug/shared-linkable-true/libboost_date_time-gcc-d-1_32.so" "bin/boost/libs/date_time/build/libboost_date_time.so/gcc/debug/shared-linkable-true/greg_month.o" "bin/boost/libs/date_time/build/libboost_date_time.so/gcc/debug/shared-linkable-true/greg_weekday.o" "bin/boost/libs/date_time/build/libboost_date_time.so/gcc/debug/shared-linkable-true/date_generators.o" ...failed gcc-Link-action bin/boost/libs/date_time/build/libboost_date_time.so/gcc/debug/shared-linkable-true/libboost_date_time-gcc-d-1_32.so... ...skipped <@boost!lib64-gcc>libboost_date_time-gcc-d-1_32.so for lack of <@boost!libs!date_time!build/libboost_date_time.so/gcc/debug/shared-linkable-true>libboost_date_time-gcc-d-1_32.so... It seems it's using -maix64 ok when trying to build the library, but not when compiling... Can anyone tell me what the proper way of building boost under these conditions are? Thanks, /Patrik Jonsson

5 16

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

[BGL] Question on prim_minimum_spanning_tree
by Wang Johny 22 Jun '05

22 Jun '05

Hi, there I am a new user of boost (in particular BGL). For my project, I am using the function of "prim_minimum_spanning_tree" to construct the minimum spanning tree. But I found a strange problem and hope to get your help. Specifically, I am following the sample code "prim-example.cpp" (using MSVC), with one modification to the weight property. That is, I am defining the weight property as property < edge_weight_t, float > not the original one property < edge_weight_t, int > And I found by doing so, the function of "prim_minimum_spanning_tree" return wrong results (no edge is returned at all). But the original version using "property < edge_weight_t, int >" definition works well. So I am wondering if I missed something to make user-defined weitgh property work for this function. Any suggestion is welcome. Thank you very much. Best regards, Shenai Problematic code: /////////////////////////////////////////////////////////////////////////////////////////////////// typedef adjacency_list < vecS, vecS, undirectedS, property<vertex_distance_t, int>, property < edge_weight_t, float > > Graph; typedef std::pair < int, int >E; const int num_nodes = 5; E edges[] = { E(0, 2), E(1, 1), E(1, 3), E(1, 4), E(2, 1), E(2, 3), E(3, 4), E(4, 0) }; float weights[] = { 1.0f, 2.0f, 1.0f, 2.0f, 7.0f, 3.0f, 1.0f, 1.0f }; Graph g(num_nodes); property_map<Graph, edge_weight_t>::type weightmap = get(edge_weight, g); for (std::size_t j = 0; j < sizeof(edges) / sizeof(E); ++j) { graph_traits<Graph>::edge_descriptor e; bool inserted; tie(e, inserted) = add_edge(edges[j].first, edges[j].second, g); weightmap[e] = weights[j]; } std::vector < graph_traits < Graph >::vertex_descriptor > p(num_vertices(g)); property_map<Graph, vertex_distance_t>::type distance = get(vertex_distance, g); property_map<Graph, vertex_index_t>::type indexmap = get(vertex_index, g); prim_minimum_spanning_tree(g, *vertices(g).first, &p[0], distance, weightmap, indexmap, default_dijkstra_visitor()); for (std::size_t i = 0; i != p.size(); ++i){ if (p[i] != i){ TRACE("I am here"); } } /////////////////////////////////////////////////////////////////////////////////////////////////// --------------------------------- Do You Yahoo!? 150万曲MP3疯狂搜，带您闯入音乐殿堂美女明星应有尽有，搜遍美图、艳图和酷图 1G就是1000兆，雅虎电邮自助扩容！

2 1

Serialization of heterogeneous sequence using shared_ptr<void>
by Sean Kelly 10 Jun '05

10 Jun '05

Dear All, I'm trying to figure out if something like the below is possible with the serialization library. The idea is to serialize a heterogeneous sequence using shared_pointer<void>. thanks for any help Sean void hetero_sequence() { // create and open a character archive for output std::ofstream ofs("dictionary.pickle"); boost::archive::text_oarchive oa(ofs); std::deque<boost::shared_ptr<void> > sequence; sequence.push_back(boost::shared_ptr<string>(new string("random string"))); sequence.push_back(boost::shared_ptr<double>(new double(3.1415627))); sequence.push_back(boost::shared_ptr<bool>(new bool(false))); // write class instance to archive oa << sequence; // close archive ofs.close(); }

3 3

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

boost thread tutorial?
by Matthias Kaeppler 03 Jun '05

03 Jun '05

Howdy, I'm planning to use Boost.Thread in my program to utilize concurrency. I already had a closer look at the documentation and I noticed that it's lacking most parts for which I would consult a documentation in the first place: 1. API reference 2. A user guide showing how to use Boost.Thread in practical examples The only code examples I spotted were pseudo-code which were pretty meaningless to me. For example: void foo() { create_thread(&bar); } What is create_thread? Which arguments does it take? What is bar? I know I can't demand anything from the author since it's free software, but... this is simply not very helpful. So, does anyone know a good source with examples and maybe even an API reference of Boost.Thread? Thanks in advance. -- Matthias Kaeppler

3 3

boost.serialization 1.32 example execution fails in MFC project (Visual Studio .NET 2003)
by Yan Zhang 02 Jun '05

02 Jun '05

I installed Boost 1.32 in Windows with Visual Studio .NET 2003. I tested serialization provided in "vc7ide" project, it runs successfully. Of course, all test projects are "Console", no MFC library involved. Then I used the same library in MFC project, the execution failed in function: BOOST_SERIALIZATION_NVP(s) >From MSDN, it was said that Boost is supported in Visual Studio .NET 2003. I labored a week to upgrade our MFC project to Visual Studio .NET 2003 and it still has problem. Any idea? Thanks in advance. Yan

4 3