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

[BGL] What is filtered_graph really doing?
by Lindley M French 08 Jun '09

08 Jun '09

My edge properties struct has a bool "on" member. At times I may want to change whether an edge is on or not, and then I want to generate filtered_graphs that contain only the on or off edges for use with BGL algorithms. However, it doesn't seem to be working. If I do: func(Graph &G) { filtered_graph<Graph> F1(G,OnEdges(G)); // iterate over the edges of F1 and print them out // Now iterate over the edges of G and turn some of them off, printing out which ones filtered_graph<Graph> F2(G,OnEdges(G)); // iterator over the edges of F2 and print them out } then I end up getting the exact same set of edges from F1 and F2! F2 even shows the edges I turned off in between. What exactly is filtered_graph doing that this is possible? Related question: If I have a filtered_graph of on edges, and I turn one of them off *through* it, what happens?

1 0

Bug Sprint Final Report
by Marshall Clow 08 Jun '09

08 Jun '09

The boost bug sprint started Friday, May 29th, and ended Sunday June 7th. Thank you to everyone who participated! Just because the bug sprint is over, that doesn't mean you can't fix bugs! ;-) Here's a day by day status: Status <https://svn.boost.org/trac/boost/report/1> 7:00 AM PDT 5/29: 797 open tickets. 7:45 AM PDT 5/30: 772 open tickets. 6:00 AM PDT 5/31: 761 open tickets. 6:00 AM PDT 6/2: 747 open tickets. 6:00 AM PDT 6/3: 748 open tickets. 6:00 AM PDT 6/4: 739 open tickets. 8:00 AM PDT 6/5: 730 open tickets. 7:00 AM PDT 6/6: 719 open tickets. 7:00 AM PDT 6/7: 706 open tickets. 7:00 AM PDT 6/8: 710 open tickets (oops!) Activity: 5/29: 6 new tickets, 77 modifications, 25 tickets closed 5/30: 2 new tickets, 42 modifications, 17 tickets closed 5/31: 2 new tickets, 27 modifications, 8 tickets closed 6/1: 2 new tickets, 42 modifications, 17 tickets closed 6/2: 5 new tickets, 18 modifications, 5 tickets closed. 6/3: 4 new tickets, 19 modifications, 2 tickets closed. 6/4: 3 new tickets, 42 modifications, 24 tickets closed. 6/5: 3 new tickets, 35 modifications, 8 tickets closed. 6/6: 4 new tickets, 61 modifications, 29 tickets closed. 6/7: 1 new ticket, 20 modifications, 4 tickets closed. [ Numbers may not add up because I am counting via two different methods, using data that is time-stamped in two different time zones. Also, tickets can be closed and reopened. ] -- -- Marshall Marshall Clow Idio Software <mailto:marshall@idio.com> It is by caffeine alone I set my mind in motion. It is by the beans of Java that thoughts acquire speed, the hands acquire shaking, the shaking becomes a warning. It is by caffeine alone I set my mind in motion.

2 1

[Serialization] Stack Overflow on exit in 1.39.0: patch possibly available?
by Enrico Carrara 08 Jun '09

08 Jun '09

Hello, As others did (see http://lists.boost.org/boost-users/2009/05/48047.php) I had the problem of stack overflow on program exit while using BOOST_CLASS_EXPORT with version 1.39.0, probably due to an error in void_caster.cpp. Is it possible to have a patch for it before delivery of next version and how? Thanks in advance, eca

3 4

string_algo and vector
by gast128 08 Jun '09

08 Jun '09

Dear all, the documetnation was alittle bit vague about the use of other sequences with string_algo. However I would expect that a vector and a string have many similarities, but still I got a crash when using a vector (with Visual Studio 2003, Boost 1.36): void Foo() { //crashes with vector: std::vector<int> v1 = boost::assign::list_of(1)(3)(5)(7)(9); std::vector<int> v2 = boost::assign::list_of(3)(5); boost::algorithm::erase_range(v1, v2); _ASSERT(v1.size() == 3); //crash in detructor of v2 when leaving scope } anyone idea? wkr, me

1 2

[BGL] problem about copy graph
by Li Ning 08 Jun '09

08 Jun '09

typedef adjacency_list<vecS, vecS, undirectedS, no_property, edge_ex> graph_t; typedef graph_traits<graph_t>::vertex_descriptor vertex_t; typedef graph_traits<graph_t>::edge_descriptor edge_t; struct edge_ex { //int index; bw_t az_capacity; bw_t za_capacity; int cost; vertex_t fake_source; }; // init a graph g and assign edge_ex values, and get a std::pair<edge_t, bool> r when add_edge(5,6,g); graph_t g2 = g; std::pair<edge_t, bool> rr = edge(5,6,g2); g2[rr.first].cost = 1000; std::cout<<g[r.first].cost<<" "<<g2[r.first].cost<<" "<<g2[rr.first]; //output is: old_value old_value 1000 WHY?? It seems a bug, g2[r.first] should be 1000 rather than the value assign to g even r.first is a descriptor that belongs to g OK, this is problematic usage, but... g2[r.first] works, it doesn't make sense. -- View this message in context: http://www.nabble.com/-BGL--problem-about-copy-graph-tp23921384p23921384.ht… Sent from the Boost - Users mailing list archive at Nabble.com.

1 1

[system] Link error using __stdcall
by Daniele Barzotti 08 Jun '09

08 Jun '09

I'm using VC2008 to build a library which uses boost::system. This library is then used in a COM DLL. When I build the COM DLL in 'Release mode' I get these link errors: ----------------------------------------- EuroATLib.lib(EuroATLib.obj) : error LNK2001: unresolved external symbol "class boost::system::error_category const & __stdcall boost::system::get_system_category(void)" (?get_system_category@system@boost@@YGABVerror_category@12@XZ) EuroATLib.lib(EuroATLib.obj) : error LNK2001: unresolved external symbol "class boost::system::error_category const & __stdcall boost::system::get_generic_category(void)" (?get_generic_category@system@boost@@YGABVerror_category@12@XZ) EuroATLib.lib(ATDispatcher.obj) : error LNK2001: unresolved external symbol "bool __stdcall boost::this_thread::interruptible_wait(void *,struct boost::detail::timeout)" (?interruptible_wait@this_thread@boost@@YG_NPAXUtimeout@detail@2@@Z) ----------------------------------------- I think the problem is in the calling convention that in COM is __stdcall while the boost::system uses __cdecl. What I don't understand is why when I build the COM DLL in 'Debug mode' it works! I've checked the VC linker settings and it seems ok. Any suggestions? Thanks, Daniele.

2 2

[thread] thread_specific_ptr is not initialized with NULL
by Michael Gopshtein 08 Jun '09

08 Jun '09

Hi, As I understand from documentation, once thread_specific_ptr is created, first call to get() should return NULL in all threads. Actually sometimes it doesn't happen. Consider the following scenario: 1) thread T1 initializes some global tss object (by doing "new" on global thread_specific_ptr<>*) 2) thread T2 tries to read the value with get(), and gets null. It sets a correct value (unsigned int 42) 3) thread T1 deletes tss object, and allocates a new one instead. 4) thread T2 tries to read the value from the new object So I expected that in (4) thread T2 will get NULL again. Actually, when new object created in (3) is created in same memory location, T2 gets the original value in (4), and not NULL. When new pointer allocated in (3) is different, T2 gets NULL as expected (verified using "placement new" to control location of the tss object). Is it a bug or inpropriate use pattern? The code that demonstrates the issue is listed below (please ignore synchronization issues) - note the line with a comment: when I do "new (buf2) ..." instead, it works as expected. Thanks, Michael ====================================== #include <boost/thread/tss.hpp> #include <boost/thread.hpp> #include <unistd.h> #include <iostream> using namespace std; boost::thread_specific_ptr<unsigned long> *pptr = NULL; char buf1[sizeof(boost::thread_specific_ptr<unsigned long>)]; char buf2[sizeof(boost::thread_specific_ptr<unsigned long>)]; void do1() { cout << "Creating TLS index\n"; pptr = new (buf1) boost::thread_specific_ptr<unsigned long>; sleep(5); cout << "Replacing TLD index\n"; pptr->~thread_specific_ptr(); pptr = new (buf1) boost::thread_specific_ptr<unsigned long>; // HERE WE CAN ALLOCATE IN buf1 OR buf2 } void printval() { unsigned long * val = pptr->get(); if (val == NULL) { cout << "Got NULL value\n"; val = new unsigned long(42); pptr->reset(val); } else { cout << "Got value: " << *val << endl; } } void do2() { for (int i = 0; i < 4; i++) { sleep(2); printval(); } } int main(int argc, char *argv[]) { cout << "size " << sizeof(boost::thread_specific_ptr<unsigned long>) << endl; boost::thread t1(do1); boost::thread t2(do2); t1.join(); t2.join(); return 0; } ============================ OUTPUT: Creating TLS index Got NULL value Got value: 42 Replacing TLD index Got value: 42 Got value: 42

2 3

Re : [GUID] newbie's question
by bidi_bulle＠yahoo.com 08 Jun '09

08 Jun '09

> Did you mean the UUID library? Thanks for your answer but I was really talking the GUID library Please look at this post to better see which library I am talking of: http://www.nabble.com/-Review--The-review-of-the-Boost.Guid-library-starts-…

5 4

Bug Sprint Report for Friday, June 5th
by Marshall Clow 07 Jun '09

07 Jun '09

The boost bug sprint started Friday, May 29th, and runs through Sunday June 7th. Today is the last day! Can we get under 700 open tickets? Status <https://svn.boost.org/trac/boost/report/1> 7:00 AM PDT 5/29: 797 open tickets. 7:45 AM PDT 5/30: 772 open tickets. 6:00 AM PDT 5/31: 761 open tickets. 6:00 AM PDT 6/2: 747 open tickets. 6:00 AM PDT 6/3: 748 open tickets. 6:00 AM PDT 6/4: 739 open tickets. 8:00 AM PDT 6/5: 730 open tickets. 7:00 AM PDT 6/6: 719 open tickets. 7:00 AM PDT 6/7: 706 open tickets. Activity: 5/29: 6 new tickets, 77 modifications, 25 tickets closed 5/30: 2 new tickets, 42 modifications, 17 tickets closed 5/31: 2 new tickets, 27 modifications, 8 tickets closed 6/1: 2 new tickets, 42 modifications, 17 tickets closed 6/2: 5 new tickets, 18 modifications, 5 tickets closed. 6/3: 4 new tickets, 19 modifications, 2 tickets closed. 6/4: 3 new tickets, 42 modifications, 24 tickets closed. 6/5: 3 new tickets, 35 modifications, 8 tickets closed. 6/6: 4 new tickets, 61 modifications, 29 tickets closed. [ Numbers may not add up because I am counting via two different methods, using data that is time-stamped in two different time zones. Also, tickets can be closed and reopened. ] What can you do? See <https://svn.boost.org/trac/boost/wiki/BugSprintJune2009> for details. I've added four new reports to the trac: Open ticket count by owner: <https://svn.boost.org/trac/boost/report/18> Open ticket count by component: <https://svn.boost.org/trac/boost/report/19> Open ticket count by ticket type: <https://svn.boost.org/trac/boost/report/20> Open ticket count by milestone: <https://svn.boost.org/trac/boost/report/21> There's been a lot of discussion on the list about tickets; and there are about a dozen patches that have been tested and are ready to be applied. If you're looking to help, you can look at some of the older bugs, say, the ones for Boost 1.36, and determine if they still apply. If they do, note that in the ticket. There are 42 tickets that are still open that are marked as "to be fixed in Boost 1.36" See <https://svn.boost.org/trac/boost/report/3> for a list of open tickets by milestone. --------- Sign-up sheet -------- The following people have committed to participate in the bug sprint. Please add you name here, along with what you can do. 1) Marshall Clow (coordination, Mac OS X characterization) 2) Beman Dawes (filesystem, system, timer) 3) Doug Gregor (function, graph, logic, mpi, numeric, property_map, signals) 4) "joel falcou" <joel.falcou(a)u-psud.fr> ( linux gcc testing/VC 2008 testing, patching) 5) Michael Caisse <boost(a)objectmodelingdesigns.com> (bug fixing) 6) Jeremiah Willcock <jewillco(a)osl.iu.edu> (will test and commit graph patches) 7) David Abrahams (iterator, python) 8) Sohail Somani (patches for g++ 4.2.4) 9) Steven Watanabe <watanabesj(a)gmail.com> (bug fixes, como) 10) vicente.botet" <vicente.botet(a)wanadoo.fr> 11) Stjepan Rajko <stjepan.rajko(a)gmail.com> (fusion) 12) Daniel Wallin (parameter, ...) -- -- Marshall Marshall Clow Idio Software <mailto:marshall@idio.com> It is by caffeine alone I set my mind in motion. It is by the beans of Java that thoughts acquire speed, the hands acquire shaking, the shaking becomes a warning. It is by caffeine alone I set my mind in motion.

1 0

CMake thoughts
by Robert Bielik 07 Jun '09

07 Jun '09

Hi, The preliminary CMake file in the distr. (1.38.0) is IMHO way, WAY too complex. It makes no sense to have each sublib as a separate project, and in all different flavors at that (debug/rel/mt/st). It seems as it is designed just to create the boost libraries, which in my view in a non-sensical approach of using CMake since boost is a library, not a standalone application. The CMake file should be designed for inclusion in user CMake hierarchies, so I'd like a much more simple variant akin towards this: project(boost) option(BOOST_BUILD_STATIC_LIBRARY "Build Boost as STATIC library" ON) set(BOOST_INCLUDED_LIBRARIES <list of all the sublibraries wanted/needed> ) # Collect all the files needed into variable BOOST_SOURCE_FILES using the # list from above file(GLOB ...) if (BOOST_BUILD_STATIC_LIBRARY) add_library(boost STATIC ${BOOST_SOURCE_FILES}) else (BOOST_BUILD_STATIC_LIBRARY) add_library(boost DYNAMIC ${BOOST_SOURCE_FILES}) endif (BOOST_BUILD_STATIC_LIBRARY) This way I can easily incorporate boost into my own CMake hierarchy for creating my own projects and not clutter the workspace with hundreds of projects all with different settings. Just my 2 cents. Regards /Rob Ps. Haven't checked the list for a while, so apologies if I'm kicking in opened doors.

6 12