April 2008 - Boost - lists.preview.boost.org

[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

[smart_ptr] Some questions
by Daniel Frey 11 Apr '08

11 Apr '08

Hi, I was asked to present smart_ptr to our department, but while trying to understand the details of the implementation, I found some things that I don't understand: 1) in shared_ptr.hpp, the ctor which takes a weak_ptr doesn't copy px from r.px in the initializer list like all other ctors, instead the copy is done the the ctor body. There is even a comment which suggests that there is a problem with doing it before pn, it would not be "safe". What exactly does this mean? px is just a plain pointer, so AFAICS it won't hurt to simply say: template<class Y> explicit shared_ptr(weak_ptr<Y> const & r) : px(r.px), pn(r.pn) // may throw { } or is the current code some kind of optimization? 2) in detail/shared_count.hpp, operator= for shared_count has an optimization for tmp==pi_. At least I think that it's just an optimization and it would work without the check. OTOH, operator= for weak_count does not check for tmp==pi_. Why? Is there any deeper reason that these two code fragements differ? 3) I asked about this point before, but got no real answer: There is no throw specification in shared_from_this()'s documentation. AFAICS, shared_from_this() (if used correctly) can not throw. But will this be guaranteed? Also, it seems that enable_shared_from_this is getting some new features. Previously, enable_shared_from_this added a single weak_ptr to the derived class. Now it adds a vtable, a shared_ptr, a weak_ptr and a bool variable. Am I the only one who is concerned about this? Before the change, I even wondered if the weak_ptr could be replaced by a detail::weak_count, which would reduce the overhead from two plain pointers to only one plain pointer, since shared_from_this always has *this. Regards, Daniel

3 26

Using new threads - link issues
by Amit 11 Apr '08

11 Apr '08

Hi, I understand that using tss with the threads library (statically linked, ICL 10.1 on Win32) forces the user to define tss_cleanup_implemented() in the global namespace. Since there is no documentation on this, I would appreciate some information as to whether there are any gotchas: I am assuming that tss_cleanup_implemented() is the place where all thread_specific_ptr's should be reset(). Is there anything else required? Also, are there any special considerations when some of the threads might not have been started through Boost.threads? Btw, thread.hpp is extremely fiddly to use, since it does not define WIN32_LEAN_AND_MEAN, which leads to winsock.h getting included which makes it unuseable with any networking libraries (that use winsock2). I ended up creating my ouwn header that includes this after defning the macro. Thanks a lot Amit

2 7

Egg 2nd request for reviews
by dan marsden 11 Apr '08

11 Apr '08

Hi All The review of the Egg library by Shunsuke Sogame has been running for 1 week now. There has been some discussion of the library on a couple of related threads, but no reviews submitted so far. Please try and find time to submit a review of this library if possible. If you wish to review, but don't have time before the review ends on April 13th, please post to that effect, we may be able to extend / move the review period to help reviewers. Introduction: It is not so easy to define Function Objects especially if you want to support Boost.ResultOf and Boost.Lambda. Therefore, as Boost provides iterator_facade and iterator adaptors, Egg provides function_facade and function adaptors. Egg provides the following features: * Workaround for the Forwarding Problem http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2002/n1385.htm * Helpers to build Function Objects: * egg::function and egg::function_facade provides the way to build Function Objects which supports Boost.ResultOf and Lambda. * Function Objects Adaptors(in other words, higher-order functions): * egg::curryN supports the currying. * egg::pipable emulates extension methods(C#). * egg::fuse/unfuse emulates variadic functions. * egg::nestN represents nested lambda expressions. * etc... The documentation is on line: http://p-stade.sourceforge.net/boost/libs/egg/ The zipped source code is in Vault/FunctionObjects: http://tinyurl.com/34lgda Tested under: Boost Development Trunk and Boost Version1.34.1. --------------------------------------------------- Please always state in your review, whether you think the library should be accepted as a Boost library! Additionally please consider giving feedback on the following general topics: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? Thanks Dan Marsden Review Manager ___________________________________________________________ Yahoo! For Good helps you make a difference http://uk.promotions.yahoo.com/forgood/

5 12