- Boost-users - lists.boost.org

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

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

24 Nov '04

Wkr wrote: >>I am working now on a project, which solution consists of 73 vc-projects (more >>than 2500 files) and it does not leak memory in its main loop, thanks to the >>debug crt of m$. We have overwritten the new and delete operator like m$ in >>MFC does so we get accurate memory leak reporting. If you take this business >>serious one can not allow any memory leak reported by the debug crt. Of course, malloc and new are not the only ways to consume memory. Virtual Memory, Memory Mapped files, COM memory allocation functions etc etc. And the leak can be in library code over which we have much less control (other than to not use it) and therefore weaker support for leak finding and detection. It turns out we don't have a leak anywhere in our code. If we don't use boost::thread then no leak, if we use boost::thread and use CRT dynamically rather then statically then no leak. Ben wrote: >>Multithreaded configurations of MSVCRT allocates some per-thread memory >>as needed, e.g. for the object that localtime returns a pointer to. To >>ensure that this memory is freed at thread exit, you must either use a >>DLL configuration of the CRT or ensure that all threads that call into >>it are started using the _beginthread or _beginthreadex function. The >>Boost.Thread DLL is not (and cannot be) linked to the same CRT that is >>statically linked into your executable, so neither of these conditions >>is satisfied. >>If I remember correctly, any memory allocated in your executable cannot >>be deallocated in the Boost.Thread DLL, or vice versa, since they have >>separate heaps. I would expect an attempt to do so to result in a >>crash, but it might in some cases be silently ignored, resulting in a leak. I have considered this and it still may be the answer or lead to an answer. Yes indeed they have separate heaps It may explain why the leak is steeper depending on what the function does. However I do remember had one experiment where i filled up a vector with a load of stuff and hey presto, no leak. if I have a function that allocates and deallocates memory on the heap and I use it as a thread using boost::thread, then when memory deallocations are performed by that thread is it the boost dll that is doing the deallocation or is it my exe? One would assume it was my exe since the deallocation code is in my exe. Surely there is no code in the threads dll to deallocate my memory. And I never ever get a crash, just a leak.

2 1