- Boost-users - lists.preview.boost.org

accessing internal graph properties via vertex-iterators directly?
by Sebastian Weber 29 Nov '04

29 Nov '04

Hello there! First of all thanks a lot for the rapid response of my last question. I got another question concerning the access of internal graph properties: To access a bundeled vertice internal properties of a graph one has to use the following syntax: struct VertStruct { int stuff; }; typedef adjacency_list<vecS, vecS, undirectedS, VertStruct> graph_t; graph_t bg; ... setup graph ... graph_traits<graph_t>::vertex_iterator vi, vend; tie(vi, vend) = vertices(bg); bg[*vi].stuff = 4; This makes it clear, that even though we already have an iterator (vi) pointing to our vertice of interest, the BGL has to spend again some time locating the data ascociated with it. A far more direct and much clearer notion would be: (*vi).stuff = 4; With this, one would save a lookup in the data-structures and the vertice-iterator concept would be far more logic to me, concernig internal property handling. I don't know the BGL internals and how this behaviour is optimally programmed with the BGL. I thought of providing a custom container for the vertex-container which is composed of a vector of a customary struct, which glues vertice properties together with every element of the vertice list and makes the property really internal, allowing a (*vi).myrealinternalstuff = 4 expression. I hope my point is clear. Thanks a lot for any help. Greetings, Sebastian Weber

2 2

Graph library - bundled properties for edge
by TC MA 29 Nov '04

29 Nov '04

I try to add Vertex and Edge data with bundled properties. I am modifying the sample program interior_property_map.cpp to learn how to access the bundled properties, but I don't know how to fix my compile error. What is the right way to access the bundled properties for edge? Source code is: #include <boost/config.hpp> #include <iostream> #include <algorithm> #include <boost/graph/adjacency_list.hpp> #include <boost/property_map.hpp> using namespace std; using namespace boost; struct VertexData { int x; int y; }; struct EdgeData { int weight; }; template <class EdgeIter, class Graph> void who_owes_who(EdgeIter first, EdgeIter last, const Graph& G) { // Access the propety acessor type for this graph while (first != last) { // fail to compile here!!! cout << G[source(*first, G)].x << "," << G[source(*first, G)].y << " joins " << G[target(*first, G)].x << "," << G[target(*first, G)].y << " weight " << G[edge(*first)].weight << endl; ++first; } } int main() { // Create the graph, and specify that we will use store the data. typedef adjacency_list<vecS, vecS, directedS, VertexData, EdgeData> MyGraphType; typedef pair<int, int> Pair; // from <utility> Pair edge_array[11] = { Pair(0,1), Pair(0,2), Pair(0,3), Pair(0,4), Pair(2,0), Pair(3,0), Pair(2,4), Pair(3,1), Pair(3,4), Pair(4,0), Pair(4,1) }; MyGraphType G(5); for (int i=0; i<11; ++i) add_edge(edge_array[i].first, edge_array[i].second, G); G[0].x = 0; G[0].y = 0; G[1].x = 1; G[1].y = 1; G[2].x = 2; G[2].y = 2; G[3].x = 3; G[3].y = 3; G[4].x = 4; G[4].y = 4; // store weights in edges graph_traits <MyGraphType>::edge_iterator ei, eend; int i = 0; for (tie(ei, eend) = edges(G); ei != eend; ++ei) { G[*ei].weight = i++; cout << "G[e] weight " << G[*ei].weight << endl; } who_owes_who(edges(G).first, edges(G).second, G); cout << endl; return 0; } Compile error is: gcc-C++-action /home/tcma/cpp/boosttcma/libs/graph/interior_property_map.test/gcc/debug/inlining-on/interior_property_map.o /home/tcma/cpp/boosttcma/libs/graph/interior_property_map.cpp: In function `void who_owes_who(EdgeIter, EdgeIter, const Graph&) [with EdgeIter = boost::detail::adj_list_edge_iterator<boost::counting_iterator<size_t, boost::use_default, boost::use_default>, boost::detail::out_edge_iter<__gnu_cxx::__normal_iterator<boost::detail::sep_<size_t, boost::property<boost::edge_bundle_t, EdgeData, boost::no_property> >*, std::vector<boost::detail::sep_<size_t, boost::property<boost::edge_bundle_t, EdgeData, boost::no_property> >, std::allocator<boost::detail::sep_<size_t, boost::property<boost::edge_bundle_t, EdgeData, boost::no_property> > > > >, size_t, boost::detail::edge_desc_impl<boost::directed_tag, size_t>, ptrdiff_t>, boost::adjacency_list<boost::vecS, boost::vecS, boost::directedS, VertexData, EdgeData, boost::no_property, boost::listS> >, Graph = main()::MyGraphType]': /home/tcma/cpp/boosttcma/libs/graph/interior_property_map.cpp:113: instantiated from here /home/tcma/cpp/boosttcma/libs/graph/interior_property_map.cpp:64: error: no matching function for call to `edge(boost::detail::edge_desc_impl<boost::directed_tag, size_t>)' set -e "g++" -c -Wall -ftemplate-depth-255 -g -O0 -Wno-inline -I"../../../bin/boost/libs/graph/example" -I "/home/tcma/cpp/boost_1_32_0" -o "/home/tcma/cpp/boosttcma/libs/graph/interior_property_map.test/gcc/debug/inlining-on/interior_property_map.o" "/home/tcma/cpp/boosttcma/libs/graph/interior_property_map.cpp" "/usr/bin/objcopy" --set-section-flags .debug_str=contents,debug "/home/tcma/cpp/boosttcma/libs/graph/interior_property_map.test/gcc/debug/inlining-on/interior_property_map.o" ... ===== TingChong Ma ______________________________________________________________________ Post your free ad now! http://personals.yahoo.ca

2 1

RE: Problem with graph:johnson_all_pairs_shortest_paths
by keith.briggs＠bt.com 29 Nov '04

29 Nov '04

>So, you get a code like: const int V = n; int D[V][V]; In this case, 'V' is not a compile time constant and the second line >is not valid -- array bounds must be compile time constant. I have no idea why you get the error you get, instead of >error right at the point where array is declared. Most likely, this is diagnostic problem in the rather ancient (;-)) version of >gcc that you're using. Ok, so what's the right say to do this kind of dynamically-sized problem? Keith

2 1

Problem with graph:johnson_all_pairs_shortest_paths
by keith.briggs＠bt.com 29 Nov '04

29 Nov '04

I am using g++ 3.2 on a redhat linux system. I took the johnson_all_pairs_shortest_paths example, (http://www.boost.org/libs/graph/example/johnson-eg.cpp) which works fine, but then changed const int V = 5; to const int V = n; where n has been computed at runtime. This should not change the type of V or D, but I now get the error below. Can anyone explain how to fix this? Thanks, Keith > /usr/bin/g++ -I ~/boost_1_32_0/ graph_stats.cc graph_stats.cc: In function `int main()': graph_stats.cc:46: no matching function for call to ` johnson_all_pairs_shortest_paths(main()::Graph&, int[V][V], boost::bgl_named_params<int*, boost::vertex_distance_t, boost::no_property> )'

2 1

Serialization and source code organization
by Malte Clasen 28 Nov '04

28 Nov '04

Hi, I'm currently trying to use the new Boost 1.32 serialization library to save the state of a medium complex program (about 10.000 lines of code). The problem is that the serialization lib seems to require very close source code coupling: The translation unit that contains the load/save functions for the application has to see all serialize() method definitions (as they are templates). That means that I cannot rely on forward declarations, so I always have to include the respective header file. This slows down the compilation noticably and results in errors such as "C1204: compiler limit : internal structure overflow" and "C1055: compiler limit : out of keys" (VC++ 7.1), as more or less all significant headers are included in this translation unit. The documentation is aware of this kind of problem and recommends manual instantiations of the serialize() methods (in the PIMPL section). Do I get something wrong or is this the only solution? I don't really like manual template instantiations, but in this case I can't imagine another way to deal with it, except waiting for the next VC++ release and hoping for the best. Malte

4 8

help needed on random libary
by Deng Kun 28 Nov '04

28 Nov '04

can someone tell me how to seed the random library? I am having some problem with the following code the seed method won't compile on solaris but works fine on windows especially in the "else" part die->engine().seed((unsigned int)(s)); gives me some error. #ifndef RANDOMBITSET_H #define RANDOMBITSET_H #include <stdlib.h> #include <boost/random.hpp> #include <boost/dynamic_bitset.hpp> class RandomBitset { public: typedef boost::mt19937 EngineType; typedef boost::bernoulli_distribution<> DistType; typedef boost::variate_generator<EngineType, DistType> DieType; EngineType rng; DistType dist; DieType *die; RandomBitset(double p=0.5): rng(), dist(p){ die= new DieType(rng, dist); } RandomBitset(const RandomBitset & r){ rng=r.rng; dist=r.dist; if (die!=NULL) { delete die; } die= new DieType(rng,dist); } virtual ~RandomBitset(){ delete die; } //force reseed //input s<0 will use system time to reseed //otherwise use s as seed void seed(int s=-1){ if (s<0) { long rs=time(NULL); srand(rs); die->engine().seed((unsigned int) rand()); }else { die->engine().seed((unsigned int)(s)); } } void randomBitset(boost::dynamic_bitset<> & bs); }; #endif //RANDOMBITSET_H

1 0

boost and g++-4.0
by Marc Cromme 28 Nov '04

28 Nov '04

I was wondering if Boost does work with g++ 4.0 (on Linux/Unix systems). I have seen that the config files boost/config/compiler/gcc.hpp check up to version 3.4. (boost version 1.31.0-9 on a debian testing system) Does anybody have experiences with g++ 4.0 ?? Is there a gcc.hpp including tests for g++ 4.0 ?? Something else I should know and do not ?? Marc Cromme -- Marc Cromme, cand. polyt, Ph.D Senior Developer, Project Manager Index Data Aps Købmagergade 43, 2 1150 Copenhagen K. Denmark tel: +45 3341 1000 fax: +45 3341 0101 http://www.indexdata.com INDEX DATA Means Business for Open Source and Open Standards

1 0

Can't compile very simple snippet that uses boost::tuple
by Frank Astier 28 Nov '04

28 Nov '04

I am pretty sure it's because of my lack of skills with templates... Still, I don't understand why I can stream a vector if it's on its own, but not if it's stored in a boost::tuple. And it works with a std::pair! Any hint? #include <boost/tuple/tuple.hpp> #include <boost/tuple/tuple_io.hpp> #include <iostream> #include <vector> #include <algorithm> using namespace std; using namespace boost; template <typename T> ostream& operator<<(ostream& out, const vector<T>& v) { copy(v.begin(), v.end(), ostream_iterator<T>(out, " ")); return out; } template <typename T, typename U> ostream& operator<<(ostream& out, const pair<T, U>& p) { return out << p.first << " " << p.second; } int main(int, char**) { vector<float> v; cout << v; // Works fine pair<vector<float>, pair<int, int> > p; cout << p; // Works fine tuple<vector<float> > t; cout << t; // <== WON'T COMPILE } Thanks, Frank

2 1

Another use for apply.
by Paul Elliott 28 Nov '04

28 Nov '04

The bind documentation mentions the apply object as a way to get around the fact that bind does not evaluate its first arguement. There is another use. You can reverse the roles of function and parameters. You can use apply and bind to turn a parameter into a functor, and call it using a function as a parameter! Example. #include <boost/bind.hpp> #include <boost/function.hpp> #include <boost/bind/apply.hpp> #include <fstream> #include <iostream> #include <iomanip> // some sample test functions. (data) int g(int x) {return x+1;}; int h(int x) {return x*x; }; int main(int argc, char * argv) { // want to work with functions of the form int f(int); typedef int P(int); // bind the integer 5 to apply turning // apply into the number 5 into a function! call it five boost::function<int (P)> five = boost::bind(boost::apply<int>(),_1,5); //int y = five(g); // Now call 5 with the "data" g and h. std::cout << "+1=" << five(g) << std::endl << "square = " << five(h) << std::endl; return 0; }; Results: +1=6 square = 25 -- Paul Elliott 1(512)837-1096 pelliott(a)io.com PMB 181, 11900 Metric Blvd Suite J http://www.io.com/~pelliott/pme/ Austin TX 78758-3117

1 0

[Q] Unresolved references when linking against the test libs
by Michael Peterson 27 Nov '04

27 Nov '04

I apologize in advance if this turns out to be a linker problem not related to boost. So here goes: For compatibility/legacy reasons, we can not use the Boost.Build jamfiles to build our application. Accordingly, I've written a set of traditional makefiles to build the project's executables and have run into difficulties. Specifically, when I try to link my test program against the boost test libraries, I get an error message (reformatted for easy reading) saying that the reference to test_main can not be resolved. Here's the spew (formatted to make it easier to read): g++ -g3 -L../long/debug -L/usr/lib -L/usr/local/lib -L/usr/local/lib/stlport -L/usr/local/lib/boost -o "debug/unit_test" debug/longtest.o -lLong -lboost_unit_test_framework-gcc-mt-p -lboost_test_exec_monitor-gcc-mt-p -lpthread -lc /usr/local/lib/boost/libboost_test_exec_monitor-gcc-mt-p.so: undefined reference to `test_main(int, char**)' collect2: ld returned 1 exit status make: *** [debug/unit_test] Error 1 According to nm, the undefined reference, test_main, is defined in the exec_monitor library. I've tried reordering the libraries but no joy. Any advice and/or hints would be very much appreciated. I am using STLPort-4.6.2 and boost_1_32_0 and Linux (I386) Cheers, Michael

3 4

[Q] BBV2 -- How to control naming of libraries...
by Michael Peterson 27 Nov '04

27 Nov '04

This is another getting started question: I noticed that when I staged the build of the boost libraries, unlike BBV1, the lib names were of the form boost_xxx.so. I would like to be able to control the naming (and staging) such that ib names are prefixed with 'lib' and have a version number for a suffix. For example, instead of boost_xxx.so I would like the libs to be named libboost_xxx.so-1.32.0 Must I modify the <lib> target in each Jamfile.v2 to accomplish these ends? Thanks, again Michael P.S. Still haven't solved the unresolved reference to test_main. I now suspect that the libraries did not get built correctly (I used bbv1) because I can take source code directly from the examples and it fails with the same error. Hence, I'm trying to build using BBV2.

1 0

Thread Join/StackTrace
by Fallon, David 26 Nov '04

26 Nov '04

I am having problems debugging an application under Linux using gdb and the boost threads library. The problem I am basically having is the stack trace is only going back to the join statement rather than to point in the program that caused the crash. My application is reasonable complicated so to reproduce it I have created a buggy version of the helloword4 tutorial. The slightly modified the helloworld4 tutorial program to loop 7 times and then crash. The stack trace given in gdb points back to the join statement rather than the source code line that generated the error. Has anyone else come across this problem? // Copyright (C) 2001-2003 // William E. Kempf // // Permission to use, copy, modify, distribute and sell this software // and its documentation for any purpose is hereby granted without fee, // provided that the above copyright notice appear in all copies and // that both that copyright notice and this permission notice appear // in supporting documentation. William E. Kempf makes no representations // about the suitability of this software for any purpose. // It is provided "as is" without express or implied warranty. #include <boost/thread/thread.hpp> #include <boost/bind.hpp> #include <iostream> #include <string.h> void helloworld(const char* who) { for(int i = 0 ; i < 10; i++ ) { std::cout << who << "says, \"Hello World.\" " << i << std::endl; sleep(2); if(i > 7 ) { std::cout << " will crash " << std::endl; char * p = NULL; strcpy(p,"abcde "); // CAUSES Segmentation FAULT here but gdb } } } int main() { boost::thread thrd(boost::bind(&helloworld, "Bob")); thrd.join(); // Stack trace STOPS HERE }

2 1

Boost Thread - Read Write Mutex Problem
by David Brownell 26 Nov '04

26 Nov '04

When running the simple program listed below, the scoped_read_lock appears to never acquire a read lock on the mutex and, as a result, the program never finishes. In looking through the documentation, I don't think there is anything additional I need to do and was a bit surprised that this didn't work. Here is the code: boost::read_write_mutex m(static_cast<boost::read_write_scheduling_policy::read_write_scheduling_pol icy_enum>(alternating_many_reads)); std::cout << "Before\n"; { boost::read_write_mutex::scoped_write_lock l(m); } std::cout << "Middle\n"; { boost::read_write_mutex::scoped_read_lock l(m); } std::cout << "After\n"; And some more details: - test_read_write_mutex.cpp completed without problems - writer_priority and reader_priority completed without problems. Only alternating_many_reads and alternating_single_read seem to have problems. - Windows XP SP2 - Microsoft Visual Studio 2003 - I am compiling with the Multithreaded DLL version of the CRT, so boost_thread-vc71-mt-gd-1_32.lib is being used Thanks for your help! David Brownell

1 0

Serialization: shared_ptr documentation
by Malte Clasen 26 Nov '04

26 Nov '04

Hi, the serialization docs about shared_ptr state that you have to call void_cast_register to use shared_ptr: ---------- This indicates that we're not quite done. [...] In this case we need only the latter function so we can replace the base object serialization with: // register the relationship between each derived class // its polymorphic base void_cast_register< boost::detail::sp_counted_base, boost::detail::sp_counted_base_impl<P, D> >(); ---------- (http://boost.org/libs/serialization/doc/shared_ptr.html) There are two issues with this: a) The actual void_cast_register declaration has its parameters in the reverse order: ---------- template<class Derived, class Base> inline BOOST_DLLEXPORT const void * void_cast_register( const Derived * /* dnull = NULL */, const Base * /* bnull = NULL */ ) BOOST_USED; ---------- (void_cast.hpp) b) It doesn't seem to work either way, although there are different exceptions in both cases. The demo_shared_ptr.cpp doesn't even call it, instead the following is used: ---------- oa.register_type( static_cast< boost::detail::sp_counted_base_impl< B *, boost::checked_deleter<B> > * >(NULL) ---------- (demo_shared_ptr.cpp) This one actually works, the use counter is properly updated. So I guess the documentation is outdated, isn't it? Malte

2 1

cannot compile serialization library
by "Kay Erik Münch" 25 Nov '04

25 Nov '04

Hi, I'm using the borland 5.6.4 compiler on a Win2k platform. For compiling the serialization lib i followed the hint given in the "Release Notes" to use spirit 1.6x I chdir-ed into the serialization\build directory and called: bjam -sTOOLS=borland -sBCCROOT=C:\Programme\Borland\CBuilder6 -sSPIRIT_ROOT=K:\spirit161 bcc32 tells me (rougly translated): borland-C++-action ..\..\..\bin\boost\libs\serialization\build\ libboost_serialization.lib\borland\debug\xml_grammar.obj K:\boost_1_32_0\libs\serialization\build\../src/xml_grammar.cpp: Error E2209 K:\spirit161\boost/spirit/core/basics.hpp 19: \ include-File 'boost/mpl/apply_if.hpp' could not be opened *** 1 Error ... *** "C:\Programme\Borland\CBuilder6\bin\bcc32" -j5 -g255 -q -c -P -w -Ve -Vx -a8 -b- -DBOOST_TEST_NO_AUTO_LINK=1 -v -Od -vi- -tWC -tWR -tWC -WM- -w-8080 -w-8071 -w-8057 -w-8001 -I"..\..\..\bin\boost\libs\serialization\build" -I"K:\spirit161" -I"C:\Programme\Borland\CBuilder6\include" -I"K:\boost_1_32_0" -o"..\..\..\bin\boost\libs\serialization\build\libboost_serialization.lib\ borland\debug\xml_grammar.obj" "K:\boost_1_32_0\libs\serialization\build\../src/xml_grammar.cpp" He's right, there is no apply_if.hpp in the mpl library any more. How can i get the library compiled ? -- Thanks for boost ! Kay ________________________________________________________________ Verschicken Sie romantische, coole und witzige Bilder per SMS! Jetzt neu bei WEB.DE FreeMail: http://freemail.web.de/?mc=021193

3 3

Re: Memory leak reported using threads library
by alansa＠ati-uk.com 25 Nov '04

25 Nov '04

I don't mind any one off small leaks. They may not be nice but no one is going to notice them. What bothers me is when memory keeps leaking for each iteration of the loop. I don't bother with the microsoft crt leak stuff. It's rarely that much use in complex projects and even if it does detect a leak it rarely can tell you where it is. As it turns out the crt leak detect stuff doesn't seem to show any leak (at least on my system), but lets say I put in my own my own leak of say new char[10] or something then the leak messages pour out. Use windows performance counters however and it's a different story, watch the working set rocket up. And it seems to increase at different rates depending on what the thread is doing. Eventually you will run out of memory entirely. Use the crt dll in your main program however and the working set is dead flat. >What I don't understand is your mentioning of the boost::function lib. >Where do you think it is getting used in >your example? boost::function is being used in the constructor of thread i believe. Has anyone been able to confirm this leak or is it just me? Naturally boost::threads is a dll only (at least v 1.30 which i'm currently using) and it itself can either link dynamically or statically to the crt. It doesn't make any difference which though. I have to link dynamically to crt in my program to avoid the leak. Why should this make a difference? I don't particular want to upgrade to 1.32 for my project as it's rather late in the day. I don't want any other issues creeping in and I've resolved the issue by using the dll. However I thought I should report my findings and see if anyone knows anything about it. Do we know if there is no leak in 1.32 or is it still there? Thanks. Alan

8 11

Re: [Boost-users] Regex linking woes.
by Jean Francois Poirier 25 Nov '04

25 Nov '04

> The version in the lib has it's std lib in namespace "std" rather than > "_STL", I'm guessing that STLPORT_PATH was setup incorrectly and so the lib > build didn't include the STLPort headers. Either that or else __STL_DEBUG > was set inconsistently between the two builds (bjam turns it on for debug > builds). > John. Touché. Hadn't looked at resulting VC command-line and indeed, STLPort was not included properly. Only now, after much hair-pulling, inclusion of STLPort headers with <stlport-iostream>off leads me to another perplexing point: C:\boost_1_32_0\boost/shared_ptr.hpp(431) : error C2039: 'basic_ostream' : is not a member of '_STL' followed by a bunch of errors stemming from the absence of basic_ostream. I looked through shared_ptr.hpp's inclusion path for missing references to ostream or somesuch but could find none. (building with <stlport-iostream>on works, but does not achieve what I want) Could it be that my path settings are leading to ostream never being included? Many thanks, jeff poirier Software Designer / Servers Group, VertigoXmedia

2 1

boost 1.32 breaks my code
by gast 128 25 Nov '04

25 Nov '04

Dear boost developpers, I just downloaded the new version, but some changes break my code. First I get not BOOST_MPL_ASSERT compilable on VC 7.1. From the documentation I could read that it could replace BOOST_MPL_ASSERT_IS_SAME, but I removed it completely, and switched back to BOOST_STATIC_ASSERT. Second I think the boost::bind has changed. This leads to compile errors in a double bind construction. The last time I tracked a problem with boost::bind it took me three days tofollow the source code. I don't know if I spent so much time again, I can replace the code, by not using boost::bind and write it explicitly. Last I get warning C4913 constantly. It's reported in 'is_incrementable.hpp' (line 56). Wkr, me _________________________________________________________________ Talk with your online friends with MSN Messenger http://messenger.msn.nl/

5 8

Problem with incremental components
by Gildardo Sanchez 25 Nov '04

25 Nov '04

Hi. I recently updated my computer from FC2 to FC3. Then, recompiled Boost, and when I tried to recompile my code, i get the following messages: /usr/include/boost/graph/incremental_components.hpp: In function `void boost::compress_components(ParentIterator, ParentIterator)': /usr/include/boost/graph/incremental_components.hpp:82: error: `find_representative_with_full_compression' is not a member of `boost::detail' /usr/include/boost/graph/incremental_components.hpp: In function `void boost::normalize_components(ParentIterator, ParentIterator)': /usr/include/boost/graph/incremental_components.hpp:102: error: `normalize_node' is not a member of `boost::detail' If I try to compile the example that comes in the book for incremental components (examples/incremental_components.cpp <http://www.boost.org/libs/graph/example/incremental_components.cpp>), I get the following error: incrementalComponents.cpp:99: error: `print_graph' undeclared (first use this function) Any idea on why could this be happening? I haven't touched anything in my own code. Thanks Gildardo

2 3

Boost Graph Library: parallel edge removal problem
by Tiago de Paula Peixoto 25 Nov '04

25 Nov '04

Hello. I believe I found a bug in the remove_edge function, when the graph is directed and allows parallel edges. Sometimes an edge simply isn't removed. I think the problem is that remove_edge uses edge_range internally, but this function needs an ordered EdgeList (such as multisetS), and doesn't work properly when it's something like listS. The attached file shows the problem. It builds a simple graph with a loop, adds a parallel edge, and tries to remove it. The output of the program is: number of edges before removal: 5 number of edges after removal: 5 When EdgeList is changed from listS to multisetS, it works as it should: number of edges before removal: 5 number of edges after removal: 4 I'm using Boost 1.32.0, with GCC 3.4.3 on GNU/Linux. Thanks. -- Tiago de Paula Peixoto <tiago(a)forked.de>

2 1

address of member operator() function defined with member templates!
by Paul Elliott 25 Nov '04

25 Nov '04

This may be an general C++ question but: I want to take the address of a member function that happens to be an operator() operator, which is defined with member templates in apply.hpp: --------------quote---- namespace boost { template<class R> struct apply { typedef R result_type; template<class F> result_type operator()(F & f) const { return f(); } template<class F, class A1> result_type operator()(F & f, A1 & a1) const { return f(a1); } -------end quote. I want to take the address of operator() for <int,int> which is defined by the member template above. ----Quote--- // want to work with functions of the form int f(int); typedef int P(int); boost::function<int (P)> f = // boost::bind(boost::apply<int>(),_1,5); // above works but instead try below! boost::bind(&boost::apply<int>::operator()<int,int>,5); // above line produces error. ----end quote I get error message: exabind.cpp:23: error: no matching function for call to `bind(<unknown type>, boost::apply<int>, int)' How do I specify a pointer to the member operator() method defined with member template parameters <int,int> ? I must be doing something wrong. My brain hurts. -- Paul Elliott 1(512)837-1096 pelliott(a)io.com PMB 181, 11900 Metric Blvd Suite J http://www.io.com/~pelliott/pme/ Austin TX 78758-3117

1 0

Re: [Boost-users] newbie: Graph library - bundled properties revisited
by TC MA 24 Nov '04

24 Nov '04

Thanks for your help. Now I try to add Vertex and Edge data with bundled properties. Source code is: #include <boost/config.hpp> #include <iostream> #include <algorithm> #include <boost/graph/adjacency_list.hpp> #include <boost/property_map.hpp> using namespace std; using namespace boost; struct VertexData { int x; int y; }; struct EdgeData { int weight; }; template <class EdgeIter, class Graph> void who_owes_who(EdgeIter first, EdgeIter last, const Graph& G) { // Access the propety acessor type for this graph while (first != last) { // fail to compile here!!! cout << G[source(*first, G)].x << "," << G[source(*first, G)].y << " joins " << G[target(*first, G)].x << "," << G[target(*first, G)].y << " weight " << G[edge(*first)].weight << endl; ++first; } } int main() { // Create the graph, and specify that we will use store the data. typedef adjacency_list<vecS, vecS, directedS, VertexData, EdgeData> MyGraphType; typedef pair<int, int> Pair; // from <utility> Pair edge_array[11] = { Pair(0,1), Pair(0,2), Pair(0,3), Pair(0,4), Pair(2,0), Pair(3,0), Pair(2,4), Pair(3,1), Pair(3,4), Pair(4,0), Pair(4,1) }; MyGraphType G(5); for (int i=0; i<11; ++i) add_edge(edge_array[i].first, edge_array[i].second, G); G[0].x = 0; G[0].y = 0; G[1].x = 1; G[1].y = 1; G[2].x = 2; G[2].y = 2; G[3].x = 3; G[3].y = 3; G[4].x = 4; G[4].y = 4; // store weights in edges graph_traits <MyGraphType>::edge_iterator ei, eend; int i = 0; for (tie(ei, eend) = edges(G); ei != eend; ++ei) { G[*ei].weight = i++; cout << "G[e] weight " << G[*ei].weight << endl; } who_owes_who(edges(G).first, edges(G).second, G); cout << endl; return 0; } Compile error is: gcc-C++-action /home/tcma/cpp/boosttcma/libs/graph/interior_property_map.test/gcc/debug/inlining-on/interior_property_map.o /home/tcma/cpp/boosttcma/libs/graph/interior_property_map.cpp: In function `void who_owes_who(EdgeIter, EdgeIter, const Graph&) [with EdgeIter = boost::detail::adj_list_edge_iterator<boost::counting_iterator<size_t, boost::use_default, boost::use_default>, boost::detail::out_edge_iter<__gnu_cxx::__normal_iterator<boost::detail::sep_<size_t, boost::property<boost::edge_bundle_t, EdgeData, boost::no_property> >*, std::vector<boost::detail::sep_<size_t, boost::property<boost::edge_bundle_t, EdgeData, boost::no_property> >, std::allocator<boost::detail::sep_<size_t, boost::property<boost::edge_bundle_t, EdgeData, boost::no_property> > > > >, size_t, boost::detail::edge_desc_impl<boost::directed_tag, size_t>, ptrdiff_t>, boost::adjacency_list<boost::vecS, boost::vecS, boost::directedS, VertexData, EdgeData, boost::no_property, boost::listS> >, Graph = main()::MyGraphType]': /home/tcma/cpp/boosttcma/libs/graph/interior_property_map.cpp:113: instantiated from here /home/tcma/cpp/boosttcma/libs/graph/interior_property_map.cpp:64: error: no matching function for call to `edge(boost::detail::edge_desc_impl<boost::directed_tag, size_t>)' set -e "g++" -c -Wall -ftemplate-depth-255 -g -O0 -Wno-inline -I"../../../bin/boost/libs/graph/example" -I "/home/tcma/cpp/boost_1_32_0" -o "/home/tcma/cpp/boosttcma/libs/graph/interior_property_map.test/gcc/debug/inlining-on/interior_property_map.o" "/home/tcma/cpp/boosttcma/libs/graph/interior_property_map.cpp" "/usr/bin/objcopy" --set-section-flags .debug_str=contents,debug "/home/tcma/cpp/boosttcma/libs/graph/interior_property_map.test/gcc/debug/inlining-on/interior_property_map.o" ... > On Nov 24, 2004, at 11:21 AM, TC MA wrote: > > Still has a compile problem. > interior_property_map.cpp is now: > > struct vertexStruct { > string name; > }; > > template <class EdgeIter, class Graph> > void who_owes_who(EdgeIter first, EdgeIter last, const > Graph& G) > { > // Access the propety acessor type for this graph > typedef typename property_map<Graph, > &vertexStruct::name>::const_type NamePA; > > My mistake, this would have needed to be: > typedef typename property_map<Graph, string (vertexStruct::*)>::const_type NamePA; > > But, this shows us just how different bundled properties are from the prior types of properties. The property_map class becomes harder to use, but in many cases is not necessary. At the end is my rewrite of the example, which illustrates how much less baggage we need to worry about when we go all-out with bundled parameters. > > Doug > > template <class EdgeIter, class Graph> > void who_owes_who(EdgeIter first, EdgeIter last, const Graph& G) > { > while (first != last) { > cout << G[source(*first, G)].first_name << " owes " > << G[target(*first, G)].first_name << " some money" << endl; > ++first; > } > } > > struct VertexData > { > string first_name; > }; > > int > main() > { > { > // Create the graph, and specify that we will use std::string to > // store the first name's. > typedef adjacency_list<vecS, vecS, directedS, VertexData> MyGraphType; > > typedef pair<int,int> Pair; > Pair edge_array[11] = { Pair(0,1), Pair(0,2), Pair(0,3), Pair(0,4), > Pair(2,0), Pair(3,0), Pair(2,4), Pair(3,1), > Pair(3,4), Pair(4,0), Pair(4,1) }; > > MyGraphType G(5); > for (int i=0; i<11; ++i) > add_edge(edge_array[i].first, edge_array[i].second, G); > > G[0].first_name = "Jeremy"; > G[1].first_name = "Rich"; > G[2].first_name = "Andrew"; > G[3].first_name = "Jeff"; > G[4].first_name = "Doug"; > > who_owes_who(edges(G).first, edges(G).second, G); > } > > cout << endl; > > return 0; > } ===== TingChong Ma ______________________________________________________________________ Post your free ad now! http://personals.yahoo.ca

1 0

Graphviz vs boost.Graph: which is recommended?
by Dan Dimerman 24 Nov '04

24 Nov '04

Hello, I am about to start a subproject that takes a graph, computes a layout and draws it on screen (Windows XP). I thought about using AT&T's well known graphviz library until I saw that on boost 1.32 there's a new algorithm: "boost::kamada_kawai_spring_layout". Although I am tempted to use boost's lib, tradition dictates that a longer/better tested and implemented library is the way to go. Do you happen to have any experience in this kind of problem (drawing graphs)? Any suggestions/ caveats ? Thanks... --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com) Version: 6.0.799 / Virus Database: 543 - Release Date: 19-Nov-04

4 6

Re: Re: [Boost-users] newbie: Graph library - bundled properties revisited
by TC MA 24 Nov '04

24 Nov '04

Still has a compile problem. interior_property_map.cpp is now: struct vertexStruct { string name; }; template <class EdgeIter, class Graph> void who_owes_who(EdgeIter first, EdgeIter last, const Graph& G) { // Access the propety acessor type for this graph typedef typename property_map<Graph, &vertexStruct::name>::const_type NamePA; // typedef typename property_map<Graph, vertexStruct::name>::const_type NamePA; NamePA name = get(&vertexStruct, G); typedef typename boost::property_traits<NamePA>::value_type NameType; NameType src_name, targ_name; while (first != last) { src_name = G[source(*first, G)].name; targ_name = G[target(*first, G)].name; cout << src_name << " owes " << targ_name << " some money" << endl; ++first; } } int main() { { // Create the graph, and specify that we will use std::string to // store the first name's. typedef adjacency_list<vecS, vecS, directedS, vertexStruct> MyGraphType; typedef pair<int,int> Pair; Pair edge_array[11] = { Pair(0,1), Pair(0,2), Pair(0,3), Pair(0,4), Pair(2,0), Pair(3,0), Pair(2,4), Pair(3,1), Pair(3,4), Pair(4,0), Pair(4,1) }; MyGraphType G(5); for (int i=0; i<11; ++i) add_edge(edge_array[i].first, edge_array[i].second, G); MyGraphType::vertex_descriptor v = *vertices(G).first; G[v].name = "TingChong"; ++v; G[v].name = "Carmen"; who_owes_who(edges(G).first, edges(G).second, G); } cout << endl; return 0; } Compiler output is: gcc-C++-action /home/tcma/cpp/boosttcma/libs/graph/interior_property_map.test/gcc/debug/inlining-on/interior_property_map.o /home/tcma/cpp/boosttcma/libs/graph/interior_property_map.cpp: In function `void who_owes_who(EdgeIter, EdgeIter, const Graph&)': /home/tcma/cpp/boosttcma/libs/graph/interior_property_map.cpp:59: error: type/value mismatch at argument 2 in template parameter list for `template<class Graph, class Property> struct boost::property_map' /home/tcma/cpp/boosttcma/libs/graph/interior_property_map.cpp:59: error: expected a type, got `& vertexStruct::name' /home/tcma/cpp/boosttcma/libs/graph/interior_property_map.cpp:59: error: `const_type' does not name a type /home/tcma/cpp/boosttcma/libs/graph/interior_property_map.cpp:64: error: `NamePA' undeclared (first use this function) /home/tcma/cpp/boosttcma/libs/graph/interior_property_map.cpp:64: error: (Each undeclared identifier is reported only once for each function it appears in.) /home/tcma/cpp/boosttcma/libs/graph/interior_property_map.cpp:64: error: expected `;' before "name" /home/tcma/cpp/boosttcma/libs/graph/interior_property_map.cpp:66: error: template argument 1 is invalid /home/tcma/cpp/boosttcma/libs/graph/interior_property_map.cpp:66: error: `value_type' does not name a type /home/tcma/cpp/boosttcma/libs/graph/interior_property_map.cpp:68: error: `NameType' undeclared (first use this function) /home/tcma/cpp/boosttcma/libs/graph/interior_property_map.cpp:68: error: expected `;' before "src_name" /home/tcma/cpp/boosttcma/libs/graph/interior_property_map.cpp:71: error: `src_name' undeclared (first use this function) /home/tcma/cpp/boosttcma/libs/graph/interior_property_map.cpp:72: error: `targ_name' undeclared (first use this function) set -e "g++" -c -Wall -ftemplate-depth-255 -g -O0 -Wno-inline -I"../../../bin/boost/libs/graph/example" -I "/home/tcma/cpp/boost_1_32_0" -o "/home/tcma/cpp/boosttcma/libs/graph/interior_property_map.test/gcc/debug/inlining-on/interior_property_map.o" "/home/tcma/cpp/boosttcma/libs/graph/interior_property_map.cpp" "/usr/bin/objcopy" --set-section-flags .debug_str=contents,debug "/home/tcma/cpp/boosttcma/libs/graph/interior_property_map.test/gcc/debug/inlining-on/interior_property_map.o" ...failed gcc-C++-action /home/tcma/cpp/boosttcma/libs/graph/interior_property_map.test/gcc/debug/inlining-on/interior_property_map.o... ...skipped </home/tcma/cpp/boosttcma/libs/graph/interior_property_map.test/gcc/debug/inlining-on>/home/tcma/cpp/boosttcma/libs/graph/interior_property_map for lack of </home/tcma/cpp/boosttcma/libs/graph/interior_property_map.test/gcc/debug/inlining-on>interior_property_map.o... ...skipped </home/tcma/cpp/boosttcma/libs/graph/interior_property_map.test/gcc/debug/inlining-on>/home/tcma/cpp/boosttcma/libs/graph/interior_property_map.run for lack of </home/tcma/cpp/boosttcma/libs/graph/interior_property_map.test/gcc/debug/inlining-on>/home/tcma/cpp/boosttcma/libs/graph/interior_property_map... ...failed updating 1 target... ...skipped 3 targets... > Date: Wed, 24 Nov 2004 00:07:08 -0500 > From: Doug Gregor <dgregor(a)cs.indiana.edu> > Subject: Re: [Boost-users] newbie: Graph library - bundled properties > revisited > To: boost-users(a)lists.boost.org > Message-ID: <B11939FE-3DD6-11D9-9E73-000D932B7224(a)cs.indiana.edu> > Content-Type: text/plain; charset=US-ASCII; format=flowed > > On Nov 23, 2004, at 10:56 PM, TC MA wrote: > > // create a tag for our new property > > > > enum vertex_first_name_t { vertex_first_name }; > > namespace boost { > > BOOST_INSTALL_PROPERTY(vertex, first_name); > > } > > You won't actually need the part above this any more. > > > struct vertexStruct { > > string name; > > }; > > > > template <class EdgeIter, class Graph> > > void who_owes_who(EdgeIter first, EdgeIter last, const > > Graph& G) > > { > > // Access the propety acessor type for this graph > > typedef typename property_map<Graph, > > vertexStruct::name>::const_type NamePA; > > The compiler is actually giving a somewhat useful message here: add an > '&' before the vertexStruct::name to form a pointer-to-member. > > > NamePA name = get(vertex_first_name, G); > > Here again, you'll want to use a pointer-to-member, like this: > > NamePA name = get(&vertexStruct, G); > > > typedef typename > > boost::property_traits<NamePA>::value_type NameType; > > > > NameType src_name, targ_name; > > > > while (first != last) { > > src_name = boost::get(name, source(*first,G)); > > targ_name = boost::get(name, target(*first,G)); > > Now you can use the simpler: > > src_name = G[source(*first, G)].name; > targ_name = G[target(*first, G)].name; > > Once you've replaced the original get calls with these lines, you can > remove the definition of the "name" variable as well. > > Doug ===== TingChong Ma ______________________________________________________________________ Post your free ad now! http://personals.yahoo.ca

2 1

compiling 1_32 in release mode brings the computer to its knees (Modified by Yarden Livnat)
by Mail Delivery Subsystem 24 Nov '04

24 Nov '04

Hi, I'm trying to compile 1_32 on OSX with the latest gcc (GCC) 3.3 20030304 (Apple Computer, Inc. build 1666) however, while the debug version compile in just a few minutes, the 'release' start trashing on : libs/serialization/src/xml_grammar.cpp libs/serialization/src/xml_wgrammar.cpp in effect the compilation takes all the memory and then pages endlessly for hours, bringing the machine down to its knees. my compile command is: sudo bjam -sTOOLS=darwin "-sBUILD=release <threading>multi <define>BOOST_SIGNALS_NAMESPACE=Signals " install where the <define> is for Qt, Anybody has a clue why this is happaning and how to get the compilation to complete (other then copy the two .o from the debug tree into the release tree ? thanks Yarden

6 7