August 2009 - Boost - lists.preview.boost.org

[1.40.0] Beta 1 available
by Beman Dawes 19 Aug '09

19 Aug '09

Boost release 1.40.0 beta 1 is available from SourceForge: http://sourceforge.net/projects/boost/files/ This release contains no new libraries, but contains numerous bug fixes for existing libraries. Boost source files with types .bz2 and .gz are created with POSIX-style (\n) line endings. Source files with types .7z and .zip are created with Windows-style (\r\n) line endings. The content is otherwise identical. Be sure to download a file with the appropriate line endings for your platform. If you are new to Boost, be sure to read the Getting Started Guide. See www.boost.org There are three known issues with beta 1: * boost/detail/scoped_enum_emulation.hpp, used by Boost.Filesystem, has a name conflict (enum_t) with Unix header rpc/types.h. Fixed in trunk, but not yet merged into the release. * Boost.Python has fixes in trunk not yet merged into to the release. * Boost.Signals has has fixes in trunk not yet merged into to the release. These issues will be resolved for the final 1.40.0 release. Other than these three known issues, please report any problems with the beta on the developers or users mailing lists. Unless unexpected problems arise, the plan is to ship the final 1.40.0 release in a week to ten days. Thanks, --The Boost release team

3 3

FW: [boost.thread] how to delete this thread from within the thread and thread hangs
by Tan, Tom (Shanghai) 19 Aug '09

19 Aug '09

I debugged through VS2010, it seems that the main thread gets stuck in thread_group::join_all(), while some remaining thread gets stuck in remove_this_thread(). The state of the threads are wait:UserRequest. Does it suggest that a thread cannot be deleted(by operator delete) or removed from the thread_group(by remove_thread()) before the join_all() ? Thanks. -----Original Message----- From: Tan, Tom (Shanghai) Sent: 2009-08-19 10:35 To: 'boost(a)lists.boost.org' Subject: [boost.thread] how to delete this thread from within the thread and thread hangs I am using boost::thread_group to create(using thread_group::create_thread()) and dispatch threads. In order to limit the max thread numbers, at the end of each thread, I remove the thread from the thread_group and delete the thread itself(so that I could decide whether new threads need to be created). However it hangs somewhere between the creation and deletion of the last thread (say the 999th one of 999 in total). My questions are: -1) is it OK to delete the thread from within itself like what I do? if not, what the best way to achieve this -2) why does my code hangs? Below are the related code: //1- code to create and dispatch thread { //mutex for map<thread_id, thread*> operations boost::mutex::scoped_lock lk(m_mutex_for_ptr); // create a thread for this->f(duplicate_hashes) boost::thread* p = m_thread_group.create_thread(boost::bind( &detectiveT<equal_predicate>::f, this, duplicate_hashes )); // save the thread_id -> thread pointer map for later lookup and deletion m_thread_ptrs.insert(make_pair(p->get_id(), p)); // log to console for debug cout << "thread created: " << p->get_id() << ", " << m_thread_group.size() << ", " m_thread_ptrs.size() << "\n"; } //2- code of the thread execution void f(list<map_iterator_type>& l) { Do_something(l); boost::this_thread::at_thread_exit(boost::bind( &detectiveT<equal_predicate>::remove_this_thread, this )); } //3- code to delete the thread itself void remove_this_thread() { { //mutex for map<thread_id, thread*> operations boost::mutex::scoped_lock lk(m_mutex_for_ptr); boost::thread::id this_id(boost::this_thread::get_id()); map<boost::thread::id, boost::thread*>::iterator itr; itr = (m_thread_ptrs.find(this_id)); if(m_thread_ptrs.end() != itr) { // remove it from the control of thread_group m_thread_group.remove_thread(itr->second); // delete it delete itr->second; // remove from the map m_thread_ptrs.erase(this_id); // log to console for debug cout << "thread erased: " << this_id << ", " << m_thread_group.size() << ", " << m_thread_ptrs.size() << "\n"; } } } Thanks.

1 0

[boost.thread] how to delete this thread from within the thread and thread hangs
by Tan, Tom (Shanghai) 19 Aug '09

19 Aug '09

I am using boost::thread_group to create(using thread_group::create_thread()) and dispatch threads. In order to limit the max thread numbers, at the end of each thread, I remove the thread from the thread_group and delete the thread itself(so that I could decide whether new threads need to be created). However it hangs somewhere between the creation and deletion of the last thread (say the 999th one of 999 in total). My questions are: -1) is it OK to delete the thread from within itself like what I do? if not, what the best way to achieve this -2) why does my code hangs? Below are the related code: //1- code to create and dispatch thread { //mutex for map<thread_id, thread*> operations boost::mutex::scoped_lock lk(m_mutex_for_ptr); // create a thread for this->f(duplicate_hashes) boost::thread* p = m_thread_group.create_thread(boost::bind( &detectiveT<equal_predicate>::f, this, duplicate_hashes )); // save the thread_id -> thread pointer map for later lookup and deletion m_thread_ptrs.insert(make_pair(p->get_id(), p)); // log to console for debug cout << "thread created: " << p->get_id() << ", " << m_thread_group.size() << ", " m_thread_ptrs.size() << "\n"; } //2- code of the thread execution void f(list<map_iterator_type>& l) { Do_something(l); boost::this_thread::at_thread_exit(boost::bind( &detectiveT<equal_predicate>::remove_this_thread, this )); } //3- code to delete the thread itself void remove_this_thread() { { //mutex for map<thread_id, thread*> operations boost::mutex::scoped_lock lk(m_mutex_for_ptr); boost::thread::id this_id(boost::this_thread::get_id()); map<boost::thread::id, boost::thread*>::iterator itr; itr = (m_thread_ptrs.find(this_id)); if(m_thread_ptrs.end() != itr) { // remove it from the control of thread_group m_thread_group.remove_thread(me); // delete it delete itr->second; // remove from the map m_thread_ptrs.erase(this_id); // log to console for debug cout << "thread erased: " << this_id << ", " << m_thread_group.size() << ", " << m_thread_ptrs.size() << "\n"; } } } Thanks.

1 0

Introduction
by Jeff 18 Aug '09

18 Aug '09

Hey everyone. I'm Jeff Gosling and been deving in C++ for 8+ years now and I'm looking to get involved in an open source community I am very interested in getting involved in Boost development. I've subscribed to the developer mailing list and have browsed through the community webpage. I've also read up on all the existing boost modules/projects. Obviously I have a bit more reading to do to get to grips with Boost. What I was wondering is how specifically can I help? Where is a good place for someone new to Boost to start? Is there a task list that I can look to for something new to do? Thanks, Jeff

2 1

[1.40.0] Beta 1 release candidate available
by Beman Dawes 18 Aug '09

18 Aug '09

1.40.0 beta 1 release candidates are available at http://boost.cowic.de/rc/ Before pushing the beta out to SourceForge, I'd appreciate it if several people would try the release candidate and report success or problems. Thanks, --Beman

12 29

boost build output locations
by Zachary Turner 18 Aug '09

18 Aug '09

I notice there's some strange asymmetries in the locations that the standard boost build process outputs binaries to. Is there a reason for this? For example, running bjam variant=debug,release address-model=32 I get the following directory structure: bin.v2 --libs ----date_time\build\msvc-9.0 ------debug --------address-model-32 ---------- boost_date_time-vc90-gd-1_39.dll ---------- boost_date_time-vc90-gd-1_39.lib ----------link-static ------------threading-multi -------------- libboost_date_time-vc90-mt-gd-1_39 Alright there is one asymmetry evident. The dll version of the binaries are in address-model-32, and the static library version of the binaries are in address-model-32/link-static/threading-multi. Should there be like a link-dynamic and a link-static? It makes it much easier to automate linking and building if everything is symmetric, because in some compilers (e.g. visual studio) you don't have as much control as you do with a makefile. So then we take a look at boost::thread bin.v2 --libs ----date_time\build\msvc-9.0 ------debug --------address-model-32 ----------link-static ------------threading-multi -------------- libboost_thread-vc90-mt-gd-1_39.lib ----------threading-multi ------------ boost_thread-vc90-mt-gd-1_39.lib ------------ boost_thread-vc90-mt-gd-1_39.dll This time, the dll versions appeared under address-model-32/threading-multi instead of just address-model-32 like in date_time. Am I going crazy and I have a messed up system, or is this just the way it is? Is it easy to change, or would it be undesirable to change for some reason? Zach

2 1

[move][container] Fast-track reviews for Move and Container?
by Ion Gaztañaga 17 Aug '09

17 Aug '09

Hi, As some others have mentioned, I'd like to ask if Boost.Move and Boost.Container could meet the requirements for a Fast Track review (the Review Wizard has the last word according to the Boost Formal Process, but I'll like to see if there is consensus). Arguments: Boost.Move -> Only one header (move.hpp) -> Technique already in use in Boost (in several detail namespaces). This is a proposal for a common implementation. -> Boost-conformant implementation available in sandbox. Boost.Container -> Most of them standard containers -> Node containers are just wrappers over Boost.Intrusive -> Most containers (all except stable_vector) were already reviewed for Boost.Interprocess. -> Boost-conformant implementation available in sandbox. I'll be specially interested in pushing Move first, so that we could have move semantics for Boost 1.41. Best, Ion

4 6

Re: [boost] [1.40.0] Unmerged changes delaying beta 1
by Ralf W. Grosse-Kunstleve 17 Aug '09

17 Aug '09

> I'd prefer these changes go in 1.40.0 if possible. Since they have > been stable on trunk, and we are waiting a few more days anyhow for > beta feedback, I don't see a lot of risk. So please merge, and then > watch the release tests to make sure nothing breaks. All {boost,libs}/python changes are now merged into the release branch. Thanks to Steven Watanabe and Henrik Sundberg for pointing out the http vs. https problem. Ralf

1 0

Re: [boost] [1.40.0] need svn merge advice (was: Unmerged changes delaying beta 1)
by Ralf W. Grosse-Kunstleve 17 Aug '09

17 Aug '09

Beman gave me the advice below. When trying to svn merge libs/python I'm running into this error: svn: Access scheme mixtures not yet supported ('http://svn.boost.org/svn/boost/trunk/libs/python/test/enable_shared_from_th…' and 'https://svn.boost.org/svn/boost/branches/release/libs/python/test') svn: Error reading spooled REPORT request response The full output is below. Fedora release 11 (Leonidas) % svn --version svn, version 1.6.4 (r38063) compiled Aug 7 2009, 03:42:39 The working copy was checked out fresh with this client. The merge command is OK for boost/python. Adding --force doesn't help for libs/python. Last night I locally tested after simply copying the boost/python and libs/python directories into a working copy of the release branch. That works fine, but there will be no merge info if I commit from the manually modified working copy. IIUC that will be a problem for future merges. What's the best way forward? What if I commit from the release working copy with the manual copies from the trunk, then manually edit svn:mergeinfo to tell it I have everything from trunk up to this point? -- Secondary question: should I do this at the top level (branches/release) or in the subdirectories (branches/release/boost/python, branches/release/libs/python)? Any advice is appreciated; I'm quite afraid of doing something bad to the merge info. (The svn documentation explicitly tells me not to merge in subdirectories in order to avoid pitfalls...) Ralf ----- Original Message ---- From: Beman Dawes <bdawes(a)acm.org> To: Ralf W. Grosse-Kunstleve <rwgk(a)yahoo.com> Sent: Monday, August 17, 2009 9:12:37 AM Subject: Re: [boost] [1.40.0] Unmerged changes delaying beta 1 I'd prefer these changes go in 1.40.0 if possible. Since they have been stable on trunk, and we are waiting a few more days anyhow for beta feedback, I don't see a lot of risk. So please merge, and then watch the release tests to make sure nothing breaks. > (I don't have any experience working with the release branch...) The merge process is pretty simple. Assume you have a working copy of branches release at \boost\release: svn merge http://svn.boost.org/svn/boost/branches/release/boost/python \ http://svn.boost.org/svn/boost/trunk/boost/python \ \boost\release\boost\python svn merge http://svn.boost.org/svn/boost/branches/release/libs/python \ http://svn.boost.org/svn/boost/trunk/libs/python \ \boost\release\libs\python % svn merge --force http://svn.boost.org/svn/boost/branches/release/libs/python http://svn.boost.org/svn/boost/trunk/libs/python /net/firtree/raid1/rwgk/boost_release_merge_attempt/boost/libs/python --- Merging differences between repository URLs into '/net/firtree/raid1/rwgk/boost_release_merge_attempt/boost/libs/python': U /net/firtree/raid1/rwgk/boost_release_merge_attempt/boost/libs/python/test/andreas_beyer.cpp U /net/firtree/raid1/rwgk/boost_release_merge_attempt/boost/libs/python/test/stl_iterator.py U /net/firtree/raid1/rwgk/boost_release_merge_attempt/boost/libs/python/test/exec.cpp U /net/firtree/raid1/rwgk/boost_release_merge_attempt/boost/libs/python/test/slice.cpp U /net/firtree/raid1/rwgk/boost_release_merge_attempt/boost/libs/python/test/object.cpp U /net/firtree/raid1/rwgk/boost_release_merge_attempt/boost/libs/python/test/enum.py svn: Access scheme mixtures not yet supported ('http://svn.boost.org/svn/boost/trunk/libs/python/test/enable_shared_from_th…' and 'https://svn.boost.org/svn/boost/branches/release/libs/python/test') svn: Error reading spooled REPORT request response

3 2

[C++0x] Report from Frankfurt committee meeting
by Beman Dawes 17 Aug '09

17 Aug '09

The C++ standards committee met in Frankfurt, Germany, last week. Key actions: * Concepts have been removed from C++0x. The committee is very much in favor of Concepts. But Concepts are seen as so important that they have to be right. And the strong consensus was that getting Concepts right, for any reasonable definition of "right", would add several years to the schedule. There was also a consensus that an implementation of a compiler that could compile the entire standard library is part of the definition of "right". While ConceptGCC has been a great help, it isn't there as far as validating "right". Personally, I think Clang may end up being the compiler that eventually validates Concepts. * The range-based for loop and some other library features that were dependent on Concepts will be retained by recasting them to no longer depend on Concepts. See a paper in the upcoming post-meeting mailing to see how range-based for loops will work. * A second Committee Draft (CD2) will need go out for public comment in the Spring or Summer 2010, given the amount of change required to remove Concepts. The C++0x final schedule will thus slip about one year. * No committee action was taken as to how Concepts will eventually make it into C++. While there was a bit of discussion about doing a Concepts Technical Report (TR), there was no such proposal made. Committee members seem to lean toward letting the two rival Concept teams go back to work outside of the committee process. The expectation being they will come back to the committee when they are ready to restart the standardization process. Hopefully the lessons learned about Concepts during the committee process will be taken advantage of, so future standardization of Concepts will be smoother. My personal opinion is that removing Concepts will speed the arrival of conforming C++0x compilers. GCC, for example, has already implemented much of C++0x, so their key developers are no longer faced with the difficult task of turning ConceptGCC into a production compiler, and can concentrate on remaining major features like lambdas. Although Concepts would have added a lot to C++ and Boost, Concepts would also have presented major migration challenges. I'm thinking that for most Boost libraries, migration to C++0x will now be easier and less disruptive. We need to focus on the bright side. --Beman

18 35