- Boost-users - lists.boost.org

Boost.Thread: how to query the state of a thread
by Malte Starostik 24 Mar '05

24 Mar '05

{to moderator: sorry, picked the wrong sender address last time, this one is subscribed} Hi, looking through the docs I can't seem to find a way to query boost::thread whether it's still running or has terminated and if so if it's still joinable. Is that information available somehow or do I need to keep track myself? TIA, Malte

2 1

Finding member offset in compile time
by Davi de Castro Reis 24 Mar '05

24 Mar '05

Hi all, The question I have is not boost specific (maybe not even boost related), so if you think it is not appropriate to ask it here, please, please just tell me. So, here it goes. Is it possible to find the offset of a class member in compile time? In runtime, I can get the offset of member m1 in class A with the code offset = ((A *)0)->m1 But I want this value in compile time to use in some template metaprogramming. Is this possible? Since sizeof() is compile time, I suspect there is a way to do it. This would come very in hand for a metaprogramming based serialization library I am working on. Thanks in advance, Davi de Castro Reis If it is not appropriate to ask such questions here, could someone point me a C++ list where I could ask some advanced questions?

4 5

[typeof] submission updated
by Arkadiy Vertleyb 24 Mar '05

24 Mar '05

Hi all, My mail client seems to fail to CC this here, so I am re-posting: The typeof submission in the Boost sandbox file vault has been updated to include a fix allowing faster compiles with GCC (in emulation mode), as well as a workaround for what seems to be remains of ETI bug in VC71. Please take it at: http://boost-sandbox.sourceforge.net/vault/, typeof.zip. Regards, Arkadiy

1 0

BGL: remove_edge fails under certain circumstances
by Jean Utke 24 Mar '05

24 Mar '05

Hi, I noticed that with boost 1.32 under gcc 3.4.3 there are cases when remove_edge fails to remove the edge in question. I put this with all kinds of details on bugtracker under http://sourceforge.net/tracker/index.php?func=detail&aid=1166401&group_id=7… In short the problem appears to be the use of std::equal_range in the code for remove_edge. With a certain order of the vertex and edge creation it happens that equal_range returns an (end_of_list,end_of_list) pair instead of the range that includes the edge in question. I believe this is due to the list not being ordered according to the same "<" operator that std::equal_range invokes. So equal_ranges logic doesn't find the proper range, and remove_edge simply returns without warning and without removing the edge in question. There is more detail in the bug report mentioned above. I am just wondering about a good workaround. Currently I am considering to replace the equal_range call in my copy of the source but there may be a better way. ? Jean -- Jean Utke Argonne National Lab./MCS utke(a)mcs.anl.gov phone: 630 252 4552 cell: 630 363 5753

2 3

boost::iterator_facade problem with postfix increment proxy
by Jens Theisen 24 Mar '05

24 Mar '05

I want to implement my own iterator as single pass traversal with reference type value& (a genuine reference). My problem is, that the iterator facade concludes from the single pass traversal, that this is an input/output iterator and those are generelly subject to a postfix increment proxy. That is, writing *iter++ = some_value; doesn't really do anything but changing a temporary value in the proxy. In addition to this, iter++ == iter would't find a suited overload, which seems to be a bug. Chancing the traversal tag to forward traversal works correct, but that's not really what I want to do. I want my iterator to be single pass since I don't support the i == j => ++i == ++j requirement. Jens

3 10

[Boost.Test] (Solution) for Visual Studio - Link error, need to be pointed in the right direction
by Peter 24 Mar '05

24 Mar '05

Gennadiy, Once again thanks for the help. Since I could not find anything clear on how to do this myself I thought I would share it with the list and anyone else who does not know how to do this. This process allows me to create a fresh Visual 2005 C++ project and compile the various Boost.Test Unit Testing Framework examples, located under the boost.test documentation branch on the boost website. Assumptions: You have correctly installed and setup Boost (see http://www.boost.org/more/getting_started.html for more information). _Step 1_ File -> New -> Project -> General -> Console (within the wizard choose empty project and console application) _Step 2_ Create a New C++ source code file (*.cpp), add the example code you wish to run _Step 3_ Bring up the properties for the project (Within Solution Explorer right click and select properties on the project) Expand the C/C++ node of the treeview: * Select preprocessor and within the Preprocessor Definitions add the "BOOST_TEST_NO_AUTO_LINK" directive. * Select Code Generation and change the Runtime Library to "Multi-threaded Debug DLL (/MDd)" Expand the Linker node of the treeview: * Select Input and within the Additional Dependencies add "libboost_unit_test_framework-vc80-mt-gd.lib" _Step 4_ Save the project properties. _Step 5_ Compile the code. Notes: 1. The actual Lib file (libboost_unit_test_framework-vc80-mt-gd.lib) may be different for each system? Also I am guessing the Release version to link against will be the lib file without the gd. Also I think the runtime library setting will change to. 2. I have not figured out how to get the output of the tests to appear within the IDE. Currently I do a dodgy and just put a breakpoint within unit_test_main.cpp. Yes I know this is dodgy but I am still learning my way. I hope this helps others interested in using boost and specifically the Unit Test Framework within boost. (I know I would have a week ago :p) Peter.

1 0

regex_search (extended syntax) can search to the end of the iterator
by David McKelvie 23 Mar '05

23 Mar '05

>> It seems that regex_search iterates to the end of the sequence >> using ++iterator rather than stopping once it has found the first match John Maddock replied: >> 1) reproduce the behaviour with 1.32. >> 2) Let me have a reproducible test case. >> 3) Check that it's not a call to std::distance that seeking the iterator to >> the end (it shouldn't be). I have now reproduced the behaviour with Boost 1.32. I include a test case below. It does seem to be a call to std::distance which is seeking the end. The problem arises only if boost::regex::extended is specified at break /usr/local/include/boost-1_32/boost/regex/v4/perl_matcher_common.hpp:418 m_result.maybe_assign(*m_presult) is being called which then calls std::distance which does the seek to the end. The problem is probably in my iterator implementation as this is the first Ive tried to write, But that seems simple enough, so maybe its more general. This is running on Linux Fedora Core 1 Boost 1.32 gcc version 3.3.2 20031022 (Red Hat Linux 3.3.2-1) David

1 0

[BGL] Question about push_relabel_max_flow
by Matthias Linkenheil 23 Mar '05

23 Mar '05

Hello, I used the edmunds_karp_max_flow algorithm in my project and it worked fine. Then I changed it to the push_relabel_max_flow algorithm but it doesn't work. I get an access violation at line 562 in the push_relabel_max_flow.hpp . Have anyone an idea where the problem could be? Line 558 - line 565 of push_relabel_max_flow.hpp : // do the bottom u = bos; ai = out_edges(u, g).first; while (excess_flow[u] > 0) { if (capacity[*ai] == 0 && is_residual_edge(*ai)) push_flow(*ai); ++ai; } Thanks, Matthias

5 9

BGL: a quick question on bundled properties and graph traits
by Elvanör 23 Mar '05

23 Mar '05

Hello, How can I get the type of my vertex properties if I use bundled properties as internal properties? My example is this one: typedef adjacency_list<mapS, vecS, undirectedS, myClass> Graph; // and in one function: template <class graph> void myFunction (Graph & g) { // Here I need to declare an object of type myClass... how can I get this type using graph_traits ?? } Thanks. Again, the documentation on bundled properties really need to be improved, IMHO. All the information I could find was relevant to the old property maps mechanism... Jean-Noël

3 5

copy_file reliable?
by Oliver Kowalke 23 Mar '05

23 Mar '05

Hello, is boost::filesystem::copy_file reliable? If the os indicates some failure during copy of a file (for instance no more space available) the destination file is removed or left in an incomplete state? thx, Oliver -- "Happy ProMail" bis 24. M�rz: http://www.gmx.net/de/go/promail Zum 6. Geburtstag gibt's GMX ProMail jetzt 66 Tage kostenlos!

2 1