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

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