- Boost - lists.boost.org

Announce: Boost 1.50 installer for 64-bit Windows now available
by John Wiegley 15 Aug '12

15 Aug '12

BoostPro is happy to announce that we now have a free 64-bit installer for Windows available for download: http://www.boostpro.com/download This version (which is only for 1.50 and onward) installs 64-bit libraries and/or DLLs for the following compilers: Visual C++ 8.0 (Visual Studio 2005 SP1) Visual C++ 9.0 (Visual Studio 2008 SP1) Visual C++ 10.0 (Visual Studio 2010 SP1) There will be no support for Visual C++ 7.1 for 64-bit, at any time. It continues to be supported for the 32-bit installer, however. Enjoy! -- John Wiegley BoostPro Computing Software Development Training http://www.boostpro.com Clang/LLVM/EDG Compilers C++ Boost

1 0

[asio] C++11 conformance problem: tie(this)
by Howard Hinnant 14 Aug '12

14 Aug '12

In three places asio/basic_socket_iostream.hpp does this: tie(this); In C++11 tie(this) has become undefined behavior, due to 27.5.5.3 [basic.ios.members]/p2: basic_ostream<charT,traits>* tie(basic_ostream<charT,traits>* tiestr); Requires: If tiestr is not null, tiestr must not be reachable by traversing the linked list of tied stream objects starting from tiestr->tie(). In libc++ it causes an infinite recursion as the ostream::sentry constructor calls flush on the tied buffer, and flush subsequently constructs a local ostream::sentry object (this is all C++11 required behavior). I could detect tie(this) in libc++ and ignore it (as a conforming extension). However I can not detect cyclic ties in general. My gut feeling is that a noisy error is better than ignoring it because whatever tie(this) is supposed to be accomplishing in asio, it isn't, at least not with C++11-conforming std::libs (ignore or crash seem to be std::lib's two obvious options). I believe the best course of action is to remove the three instances of tie(this) from asio. I do not know if this same issue occurs in other parts of boost. I scanned but didn't catch anything. Howard

1 0

[type_erasure][docs]uniform term for underlying
by Larry Evans 14 Aug '12

14 Aug '12

The doc: http://steven_watanabe.users.sourceforge.net/type_erasure/libs/type_erasure… uses 3 terms: underlying actual contained to designate, essentially, the same thing, the actual type stored in the any. The docs would be clearer if a uniform term were used, with possibly a link to some glossary where the term was defined. -regards, Larry

1 0

[icl] HTML doc consumes more than 50 MB
by Michel Morin 14 Aug '12

14 Aug '12

The HTML doc in `libs/icl/doc/html/boost/icl` consumes more than 50 MB on my system. This directory contains about 2000 docs and there are many duplicate docs. Joachim, could you improve the situation? Thanks, Michel

3 4

C++11 decltype/SFINAE puzzler
by Eric Niebler 13 Aug '12

13 Aug '12

I'm running into a usability problem with the extended SFINAE rules that could effect best practice for all new C++ libraries. I'm hoping some clever person in the Boost community can help me. I find that in highly generic code, using decltype to define the return type of functions is very handy. Dave A. suggested a RETURNS macro to simplify this idiom: <https://groups.google.com/d/msg/boost-devel-archive/OzJ5Ft3pSnU/b_Ter9bgNqAJ> It's used like this: template<typename T> auto foo( T && t ) RETURNS( some-expression-using-t ); This is great and I use it a lot. Now, imagine you have a library of such functions calling other such functions: function A calls B calls ... calls Y, calls Z, all of which use decltype to declare their return types. Now, the user calls A passing a variable t for which the expression in Z's return type calculation makes no sense. Extended SFINAE kicks in, and Z simply disappears. Since Z has disappeared, the expression in Y's return type makes no sense, so Y disappears, too. And so on up the chain. The end result is that the user is presented with an error like: "no viable function A, template substitution failed." The user is given no information about which function in the chain failed to compile, or why. This is a serious usability problem! So, my question is: what can be done about this? Can we get the benefit of automatic type deduction in return types without causing SFINAE to drop functions from the overload set? Is there another trick we can use to report errors meaningfully when APIs are misused? The only solution I can think of is turn all the free functions in the chain into function objects and then using std::result_of to compute return types for them instead of using decltype directly. That means Dave's (very convenient!) RETURNS macro shouldn't be used, which is a bummer. (I think it also means that we need a noexcept_of template that computes the noexcept of an expression without causing the expression to appear in the function declaration, but that depends on how <http://llvm.org/bugs/show_bug.cgi?id=13286> gets resolved.) All suggestions welcome, -- Eric Niebler BoostPro Computing http://www.boostpro.com

9 19

[hash] test failure with current Intel compiler
by Beman Dawes 13 Aug '12

13 Aug '12

Release branch, using the current Intel compiler on Windows, a couple of filesystem tests are failing on my machine with the message: ..\..\..\boost/functional/hash/detail/container_fwd_0x.hpp(49): error: class template "std::tr1::shared_ptr" may not be redeclared in the current scope template <class> class shared_ptr; These tests are passing for GCC and VC++, but the Intel compiler uses the well regarded EDG front end. --Beman

2 1

[graph] interest in resumable dijkstra?
by Alex Hagen-Zanker 13 Aug '12

13 Aug '12

Dear boost-list, I placed the BGL algorithm of the dijkstra_shortest_path in a class, with the creation and initialization part separate from the main algorithm. This allows interrupting, resetting and resuming the algorithm. Would this be of interest to anybody? The following function call: dijkstra_shortest_path(graph, orig, parameter_pack); is separated into: auto dijkstra = make_dijkstra(graph, parameter_pack); dijkstra.init_from_origin(orig /*, optional_visitor*/); dijkstra.expand(/*optional_visitor*/); The make_dijkstra() function reads all parameters from the parameter_pack including color_map and priority_queue Visitors interrupt the calculation using a do_intterrupt() callback instead of throwing an exception. The function expand() can be called repeatedly, each time with another visitor. The implementation requires C++11, because of auto and lambda's, it also relies on the following patch: https://svn.boost.org/trac/boost/ticket/7130. To see for yourself: http://people.pwf.cam.ac.uk/ahh34/dijkstra_test.zip I am interested to hear your opinion. With kind regards, Alex

5 24

[type_erasure][doc]static_binding doc: no mention of PH to PH use.
by Larry Evans 13 Aug '12

13 Aug '12

The static_binding doc: http://steven_watanabe.users.sourceforge.net/type_erasure/libs/type_erasure… contains: Description Represents a mapping from placeholders to the actual types that they bind to. However, the doc for: template < typename Concept2 , typename Tag2 , typename Map > any ( const any< Concept2, Tag2 > & other , const static_binding< Map > & binding ); here: http://steven_watanabe.users.sourceforge.net/type_erasure/libs/type_erasure… contains: Requires: [snip] Map must be an MPL map with keys for all the placeholders used by Concept and values for the corresponding placeholders in Concept2. So the static_binding doc should contain something like: Represents a mapping from placeholders to the actual types that they bind to or a mapping from placeholders to placeholders, depending on where static_binding is used. HTH. -regards, Larry

1 0

[1.51.0] Beta 1 release candidates available
by Marshall Clow 12 Aug '12

12 Aug '12

Release candidate files for 1.51.0 beta 1 are available at http://boost.cowic.de/rc/ As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. This helps ensure the candidates build OK before we push them out to SourceForge. The files (and associated md5s) are: 543e3498c4ce520bfa635607971be4fc boost_1_51_0_beta1_rc1.tar.gz 3f9beb290dad223c21822e9ef601fd80 boost_1_51_0_beta1_rc1.tar.bz2 0401b9c40aac37b7dd9ef7e33190270c boost_1_51_0_beta1_rc1.zip e5aa1cd82e71173197ee6794c2c035d2 boost_1_51_0_beta1_rc1.7z Thanks, --The release managers

10 15

[MPI] Jamfile tweak
by Daniel James 12 Aug '12

12 Aug '12

Hi, I've made a change to the MPI documentation Jamfile. The documentation build was failing on trunk because the same project name was used in 'libs/mpi/build/Jamfile.v2' and 'libs/mpi/doc/Jamfile.v2', so I gave the documentation project a more appropriate name: https://svn.boost.org/trac/boost/changeset/79974/ I'll merge to release once 1.51 is finished. Daniel

1 0