- Boost - lists.boost.org

BOOST_HAS_PTHREADS, BOOST_HAS_SCHED_YIELD tests in config_test not strict enough
by Peter Dimov 13 Apr '08

13 Apr '08

I'm looking at the results of some new tests I added to smart_ptr: spinlock_try_test, yield_k_test, and I'm seeing failures on platforms that (in single threaded mode, i.e. without <threading>multi) advertise BOOST_HAS_PTHREADS (and BOOST_HAS_SCHED_YIELD) but in reality do one of: 1. provide stub implementations of pthread_mutex_*, failing a pthread_mutex_trylock test; 2. provide stubs and segfault on pthread_mutex_trylock; 3. fail to link because of missing pthread_mutex_trylock; 4. fail to link because of missing sched_yield. This isn't particularly odd or surprising. But I think that config_test ought to fail on these platforms, for the same reason my tests fail. The reason the test passes is because boost_has_pthreads.ipp and boost_has_sched_yield.ipp are too permissive; the first one only tests pthread_mutex_* functions that are stubbed and appear to work, the second doesn't attempt to actually call sched_yield and - presumably - the linker discards the reference. Does this make any sense? :-)

2 22

[smart_ptr] enable_shared_from_this_light
by Daniel Frey 13 Apr '08

13 Apr '08

Hi, I attached a complete implementation of enable_shared_from_this_light which has an overhead of a single plain pointer. It is compatible with 1.35.0's enable_shared_from_this, except for one feature: The optimized version requires that the following static_cast is legal: enable_shared_from_this_light<T>* p; static_cast<T*>(p); which means that enable_shared_from_this_light<T> must be a *non-virtual* base class of T. If you need this feature, you might want to use trunk's enable_shared_from_this (without _light), which (currently) has an overhead of four plain pointers, one bool and it adds/requires the class to have a vtable. The trunk version therefore offers some advanced features. The above repeats a few things for those people that haven't followed the discussion in the "[smart_ptr] Some questions"-thread. For those that did: The thing to note is that I added two more things to shared_ptr: _internal_shared_count() and a ctor which takes a detail::weak_count and the raw pointer. Any feedback welcome. Regards, Daniel

4 15

[graph] Dangerous undocumented EdgeList parameter for adjacency_list.
by Jurko Gospodnetić 13 Apr '08

13 Apr '08

Hi. We have just finished a painful three day track-down for a mysterious access violation/crash/undefined behavior bug and the cause has been tracked down to some graph library edge descriptors getting invalidated in a case that is completely undocumented (that in turn causing memory trashing and all the lovely things that follow...) When you have an adjacency_list graph with its EdgeList (not OutEdgeList) parameter set to vecS, then any add_edge() operation may invalidate all existing edge descriptors. This is not documented anywhere - not under the add_edge() operation and not under the 'Iterator and Descriptor Stability/Invalidation' section in adjacency_list.html which in fact explicitly states that add_edge() operation does not invalidate edge descriptors. Please, please, please document this whole EdgeList concept and how it interacts with the rest of the graph library. Also, this behavior is not consistent with add_vertex() which does not invalidate any existing vertex descriptors. Edge descriptors seem to contain a pointer directly into their graph's edge storage, and that causes them to be invalidated whenever that storage gets reallocated. Any reason why they should not be holding an index to that storage in case EdgeList=vecS similar to how vertex descriptors identify their vertex? That way this whole problem with add_edge() invalidating all existing edge descriptors would be avoided. Thanks in advance. Best regards, Jurko Gospodnetić

1 1

[graph] Documentation error for the adjacency_list_traits<> type.
by Jurko Gospodnetić 13 Apr '08

13 Apr '08

Hi. The adjacency_list_traits<> documentation (adjacency_list_traits.html) lists its first template argument as EdgeList while it should be OutEdgeList. The way it is written now it causes confusion between the OutEdgeList and the (seemingly still unfinished) EdgeList concept. Hope this helps. Best regards, Jurko Gospodnetić

1 0

[graph] Invalid link in the documentation.
by Jurko Gospodnetić 13 Apr '08

13 Apr '08

Hi. The 'BGL Book Errata' link in table_of_contents.html links to http://siek.info/bgl.html which in turn requires the user to enter a password to access. This should be fixed. This could possibly be happening due to an invalid link target and the HTTP server redirecting the call to the root folder to which access is protected by a password. Hope this helps. Best regards, Jurko Gospodnetić

1 0

[gil] [announcement] New IO lib
by Tom Brinkman 12 Apr '08

12 Apr '08

>> https://gil-contributions.googlecode.com/svn/trunk/gil_2/boost/gil/extensio… Link requires a password. You should add a link to summary page so people can get a quick introduction to your proposals. This is a link to svn. Is there any documentation yet? Definately get this added to the review queue. If nothing else it will create lots of interesting discussions. Nice work. I'll be using it.

2 1

boost::shared_ptr/weak_ptr
by Patrick Twohig 12 Apr '08

12 Apr '08

I've been maintaining/developing a fairly large application which has been built entirely without the use of exceptions. Two of the major target platforms have weak or no exception support. Anyhow, It appears that the function weak_ptr<T>::lock() relies on an exception thrown by shared_ptr<T>'s constructor in order to work properly. I'm assuming based on the code for lock() that the reason the call uses an exception is because the constructor of shared_ptr uses an atomic operation to perform the reference counting. I was curious if perhaps and appropriate solution for compilers lacking support for exceptions would be to simply make the constructors for boost::shared_ptr construct a shared_ptr equivalent to shared_ptr<T> ptr( 0 ); I'm assuming that if the constructors of shared_ptr never throw (even if the interface indicates so) using weak_ptr::lock() would be safe based on the code below, taken directly from weak_ptr.hpp. shared_ptr<T> lock() const // never throws { #if defined(BOOST_HAS_THREADS) // optimization: avoid throw overhead if(expired()) { return shared_ptr<element_type>(); } try { return shared_ptr<element_type>(*this); } catch(bad_weak_ptr const &) { // Q: how can we get here? // A: another thread may have invalidated r after the use_count test above. return shared_ptr<element_type>(); } #else // optimization: avoid try/catch overhead when single threaded return expired()? shared_ptr<element_type>(): shared_ptr<element_type>(*this); #endif }

3 5

[1.35] System: error_code.cpp #defines macros without checking if already defined
by Mat Marcus 11 Apr '08

11 Apr '08

Hi Beman, error_code.cpp contains the following #defines: #define _CRT_SECURE_NO_DEPRECATE #define _SCL_SECURE_NO_DEPRECATE It should first check that these macros are not defined already. Otherwise users who #define these macros on the command line will received duplicate definition errors, as I am. Also, you might consider adding: #define _SECURE_SCL 0 for VC 9. - Mat

8 17

[Boost][Spirit] Missing libs/spirit/test directory?
by K. Noel Belcourt 11 Apr '08

11 Apr '08

Hi, The nightly builds are broken because the boost/status/Jamfile.v2 contains this line build-project ../libs/spirit/test ; # test-suite spirit but this directory doesn't appear to exist in the repository. Bjam fails with the this message. error: Unable to find file or target named error: '../libs/spirit/test' error: referred from project at error: '.' Could someone fix this? Thanks. -- Noel

3 2

Re: [boost] [move semantics] Do we have any plan for move semantics emulation?
by vicente.botet 11 Apr '08

11 Apr '08

Hello, In 2005 David Abrahams presented its implementation of move semantics. In Jul 24, 2006 Ion Gaztañaga posted http://www.nabble.com/-move-semantics--Do-we-have-any-plan-for-move-semanti… Since then there is some Boost libraries that use this implementation internnally (I'm thinking of course on Boost.Interprocess, Boost.Thread), but each one changing the namespace. In addition Boost.Thread has an internal move class with a simplified implementation intendeed for the same sematics. This make very difficult to interact between different libraries using the same concept but with a different name. In addition there is a risk that these implementation diverge. Even if the implementation is only an emulation ot the C++0x move semantics, this should be better than nothing? I'd like to reiterate the Ion question, "Do we have any plan for move semantics emulation ?" Best regards _____________________ Vicente Juan Botet Escriba

3 2