- Boost - lists.boost.org

[1.53.0] Beta release candidates available
by Marshall Clow 04 Jan '13

04 Jan '13

Release candidate files for 1.53.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: d5a45d0e08a14d5fb0965fe675d76ac6 *boost_1_53_0_beta1_rc1.tar.gz 89a6084458cd9f0e136c4b5292265461 *boost_1_53_0_beta1_rc1.tar.bz2 2a8897e04c59ccaf39189568f6966d60 *boost_1_53_0_beta1_rc1.zip 4cdf5a71d46e1115ca0c413f5b139a54 *boost_1_53_0_beta1_rc1.7z Thanks, --The release managers

7 7

[atomic] building with --layout=system, mingw, bug #7482
by Tim Blechmann 04 Jan '13

04 Jan '13

hi, i need some help with resolving issue #7482: for some reason it seems to build a static libboost_atomic, although it has to be a shared library. could someone with more insights in this platform have a look, what's going wrong (and why the library is static)? unfortunately i neither have access to mingw, nor am i too familiar with the boost build infrastructure ... thanks, tim

3 3

Upgrade mailman to 2.1.15
by DongInn Kim 04 Jan '13

04 Jan '13

Dear All, If it is not too busy time tomorrow, can we upgrade mailman from 2.1.12 to 2.1.15? I am planning to upgrade it on Friday, Jan 4th, 2013 and it won't take long to upgrade it. Date: Friday, Jan 4th, 2013. Time: - 4:00am-4:10am Pacific US time - 5:00am-5:10am Mountain US time - 6:00am-6:10am Central US time - 7:00am-7:10am Eastern US time - 12:00pm-12:10pm GMT Please let me know if you have any questions or suggestions. Regards, -- - DongInn

1 1

Release managers: Boost.Thread breaking changes in 1.53
by Vicente J. Botet Escriba 04 Jan '13

04 Jan '13

Hi, there has been some threads about the following Boost.Thread breaking change in release 1.53. "Breaking changes when BOOST_THREAD_VERSION==3 (Default value since Boost 1.53): There are some new features which share the same interface but with different behavior. These breaking features are provided by default when BOOST_THREAD_VERSION is 3, but the user can however choose the version 2 behavior by defining the corresponding macro. As for the deprecated features, these broken features will be only available until boost 1.55. * [@http://svn.boost.org/trac/boost/ticket/6229 #6229] Rename the unique_future to future following the c++11. * [@http://svn.boost.org/trac/boost/ticket/6266 #6266] Breaking change: thread destructor should call terminate if joinable. * [@http://svn.boost.org/trac/boost/ticket/6269 #6269] Breaking change: thread move assignment should call terminate if joinable. " I would like to request advise from the release managers and of course the Boost community. Should I rollback the default to BOOST_THREAD_VERSION==3 for 1.53 and let the time to discuss the best way to manage with these breaking changes? Best, Vicente

21 40

[log] Most recent version
by Alexander Arhipenko 04 Jan '13

04 Jan '13

Hi, We're going to update boost.log sources in our code base. Could you please recommend what version to use? The code is taken from: https://boost-log.svn.sourceforge.net/svnroot/boost-log/. And currently I consider 3 options: branches/v1 branches/bleeding-edge trunk Thanks in advance. Regards

5 7

[release] permission to merge xpressive bug fix
by Eric Niebler 03 Jan '13

03 Jan '13

Apologies, I forgot to merge this fix to release. Can I do it now? https://svn.boost.org/trac/boost/changeset/82103 It is to fix this: https://svn.boost.org/trac/boost/ticket/7809 -- Eric Niebler BoostPro Computing http://www.boostpro.com

2 2

utf8_codecvt facet - volunteer opportuntiy
by Robert Ramey 03 Jan '13

03 Jan '13

Our implementation for a codecvt facet internal wide char to/from utf8 format requires some maintainence. We have our own implementation since 2001. Since then, the standard libary has come to specify some implementations and some libraries have implemented some or all of this aspect of the standard library. I've come to believe that we should: a) tweak our code to use the standard library implementations if they exist. b) tweak our code to use the names of the standard library implementation b) tweak our build so that our version replaces the the standard library implementation when and only when there is no standard implemenation available. This seemingly simple task is complicated by the following circumstances. a) The relationshp between UCS and Unicode is pretty confusing. b) The iterface for codecvt is confusing. c) a number of standard library implementations have non-conforming codecvt interface. d) a number of standard library implementations don't have any codecvt header at all. This is not a problem for our current implementation because we never import it. Anyone interested in working on this should contact Marshall, Beman or myself (in that precedance). Robert Ramey

2 1

[config] Proposed BOOST_NOEXCEPT_NOTHROW macro
by Beman Dawes 03 Jan '13

03 Jan '13

The three current BOOST_NOEXCEPT* macro variants miss the case where C++03 code has a "throw()" throw-specifier. Classes that derive from standard library exceptions need this to avoid breaking code on C++03 compilers. I'm not enamored with the BOOST_NOEXCEPT_NOTHROW name, so feel free to offer suggestions for alternate names. Here is the full set of macros: #ifdef BOOST_NO_NOEXCEPT # define BOOST_NOEXCEPT # define BOOST_NOEXCEPT_NOTHROW throw() <---- new macro # define BOOST_NOEXCEPT_IF(Predicate) # define BOOST_NOEXCEPT_EXPR(Expression) false #else # define BOOST_NOEXCEPT noexcept # define BOOST_NOEXCEPT_NOTHROW noexcept <---- new macro # define BOOST_NOEXCEPT_IF(Predicate) noexcept((Predicate)) # define BOOST_NOEXCEPT_EXPR(Expression) noexcept((Expression)) #endif Unless there are objections, I'll commit the changes Wednesday afternoon Eastern US time. --Beman

7 11

[xpressive] Broken in release if explicit operator bool is available
by Andrey Semashev 03 Jan '13

03 Jan '13

Hi, With the recent change to Boost.SmartPtr that adds support for explicit operator bool() Boost.Xpressive no longer compiles. The relevant error message is: ./boost/xpressive/detail/utility/tracking_ptr.hpp:440:73: error: no type named ‘unspecified_bool_type’ in ‘class boost::intrusive_ptr<boost::xpressive::detail::regex_impl<const char*> >’ Could this be fixed?

2 3

Flow-based programming library for Boost?
by Marcus Tomlinson 03 Jan '13

03 Jan '13

Is there any interest out there for a library that allows you to create fast, efficient flow-based programs with an easy-to-use object-oriented interface? (http://en.wikipedia.org/wiki/Flow-based_programming) I've created an open-source library that does this, called "DSPatch" ( http://sourceforge.net/projects/dspatch) and would like to contribute it to the Boost Libraries. Please let me know if this sounds like something you'd like to see in Boost. Thanks!

15 64