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

Releasing Boost Dependency Analyzer 1.1
by Jens Weller 11 Aug '13

11 Aug '13

Hello boost community, a short notice that I just have released the version 1.1 of my dependency analyzing tool for boost. For now I have only managed to get a proper Windows Version, Linux Version will follow later. New Features: Configuration - the tool remembers the path to bcp now - select the source for libraries - maintainers.txt - libraries.xml - 2 filter options - filter libraries by name - filter edges by type, for now its header, source/lib, test and documentation. Export: - Export CSV File which has all libraries and the number of dependencies (sorted) libraries.xml - this is now a optional source for the library names Some feedback: libraries.xml as a lib name source is nice, but not quite perfect. I've seen different results from maintainers.txt and libraries.xml. As maintainers.txt also libraries.xml contains duplicates, some of its library names don't fit the expectation of bcp, so I applied some fixes for this in my program. The Dependency filter is yet not perfect, especially in detection. More details about this version and the download for it at my blog: http://www.meetingcpp.com/index.php/br/items/releasing-boost-dependency-ana… kind regards, Jens Weller

4 5

Boost 1.54 build problem: --without-context not honoured?
by Steve M. Robbins 11 Aug '13

11 Aug '13

Hi, I'm digging into a build problem and noticed that even though I specify "./bjam --without-context", Boost.Context is still built! The bjam configuration output states that Context is not to be built: Component configuration: - atomic : building - chrono : building - context : not building - coroutine : building - date_time : building - exception : building But it is built nonetheless. This causes a build failure for architectures which are not supported; see build log [1]. Compare that to the build for 1.53 [2] which works fine. I've diffed the libs/context directory between 1.53 and 1.54 and nothing jumps out at me as the cause. Has anyone noticed and fixed this already? Thanks, -Steve [1] https://buildd.debian.org/status/fetch.php?pkg=boost1.54&arch=ia64&ver=1.54… [2] https://buildd.debian.org/status/fetch.php?pkg=boost1.53&arch=ia64&ver=1.53…

4 4

[preprocessor] nested for_each not working like expected
by Eric Niebler 10 Aug '13

10 Aug '13

I can't figure out what I'm doing wrong. According to the docs, this should work: #define S0 (0)(1)(2)(3) #define S1 (5)(6)(7)(8) #define M4(R, DATA, ELEM) (DATA,ELEM) #define M2(R, DATA, ELEM) BOOST_PP_SEQ_FOR_EACH_R(R, M4, ELEM, S1); BOOST_PP_SEQ_FOR_EACH(M2, ~, S0) I expect to get a sequence like (0,1)(0,2)... for each combination. I get gibberish. (Please don't tell me to use FOR_EACH_PRODUCT. In my real use case, M2 and M4 are far more complicated, and a simple product won't do.) Can anybody please tell me what I'm doing wrong? TIA, -- Eric Niebler Boost.org

5 11

[chrono] Outdated information in documentation
by Björn Pollex 10 Aug '13

10 Aug '13

In the getting started section [1] it refers to an issue with the BOOST_ERROR_CODE_HEADER_ONLY macro which seems to be fixed by now. Regards, Björn [1] http://www.boost.org/doc/libs/1_54_0/doc/html/chrono/users_guide.html#chron…

2 1

[date time] std::out_of_range thrown on date 2012-5-29
by Matthijs Möhlmann 09 Aug '13

09 Aug '13

Hello all, Following piece of program gives a std::out_of_range exception: #include <boost/date_time/posix_time/posix_time.hpp> int main(int argc, char **argv) { boost::posix_time::ptime datetime; datetime = boost::posix_time::time_from_string("2012-5-29"); return 0; } Compiled with the following line: g++ -o main -lboost_date_time -g -std=c++11 main.cpp Output: matthijs@hammer % ./main terminate called after throwing an instance of 'std::out_of_range' what(): basic_string::at zsh: abort ./main Platform: x86_64 Boost version: 1.54 Compiler version: gcc 4.8 Where can I officially report bugs? Regards, Matthijs Möhlmann

3 3

[move] forward with lvalue ref template param
by Andrew Ho 08 Aug '13

08 Aug '13

Hi during my implementation of unique_ptr I noticed that boost::forward doesn't play nicely with lvalue ref types. int a; int &b = a; int &c = std::forward<int&>(b); // compiles fine int &d = boost::forward<int&>(b); // compiler error I did a little playing around with the declarations of forward and I managed to get this to work: // if T is not a lvalue ref and movable template <class T> inline typename ::boost::move_detail::enable_if_c < enable_move_utility_emulation<T>::value && ::boost::move_detail::is_rv<T>::value && !::boost::move_detail::is_lvalue_reference<T>::value, const T &>::type forward(typename ::boost::move_detail::identity<T>::type &x) BOOST_NOEXCEPT { return const_cast<T&>(x); } // if T is not a lvalue ref and not movable template <class T> inline typename ::boost::move_detail::enable_if_c < enable_move_utility_emulation<T>::value && !::boost::move_detail::is_rv<T>::value && !::boost::move_detail::is_lvalue_reference<T>::value, const T &>::type forward(const typename ::boost::move_detail::identity<T>::type &x) BOOST_NOEXCEPT { return x; } // if T is a lvalue ref template <class T> inline typename ::boost::move_detail::enable_if_c < ::boost::move_detail::is_lvalue_reference<T>::value , T>::type forward(T x) BOOST_NOEXCEPT { return x; } Basically, this forces all calls to forward<A&> to simply return the lvalue ref (const-ness is maintained, I think), otherwise it does whatever boost::forward did before. As far as I can tell, this doesn't break boost::forward, and it enables it to properly handle taking lvalue refs. Am I right in my assumptions? Are there any cases where this would fail to produce standard-compliant/desired results?

1 0

[git] eol issues and fetchRecurseSubmodules = on-demand
by Ahmed Charles 08 Aug '13

08 Aug '13

Two things: 1. tools\build\v2\engine\build.bat has LF instead of CRLF for line endings, which causes bootstrap.bat (which has the right endings) to not work properly. It seems like the top level .gitattributes doesn't apply to submodules. 2. After cloning and fetching modular boost each day for a while, I finally figured that waiting an hour or so to sync could probably be improved. So I read the docs and tested adding fetchRecurseSubmodules = on-demand for each submodule in .gitsubmodules and it seems to work much faster with the same result. (It would result in differences once the submodules can change without the super-project changing, but currently, I don't think that is the case.) Perhaps it's with considering?

2 5

[boost/spirit] numeric policy
by Brian Schrom 07 Aug '13

07 Aug '13

I've had the case where I needed to retain formatting information for a number (general, fixed, scientific) and was nicely accomplished by extending the policy, but needed to have a begin_parse() and end_parse() for the policy to be complete. It seems that it makes some sense or is this accomplished another way? Maybe something to consider for policies in general? Index: qi/numeric/real_policies.hpp =================================================================== --- qi/numeric/real_policies.hpp (revision 85166) +++ qi/numeric/real_policies.hpp (working copy) @@ -28,6 +28,18 @@ static bool const allow_trailing_dot = true; static bool const expect_dot = false; + template <typename Attribute> + static void + begin_parse(Attribute& attr_) + { + } + + template <typename Attribute> + static void + end_parse(Attribute& attr_,bool /* result */) + { + } + template <typename Iterator> static bool parse_sign(Iterator& /*first*/, Iterator const& /*last*/) Index: qi/numeric/detail/real_impl.hpp =================================================================== --- qi/numeric/detail/real_impl.hpp (revision 85166) +++ qi/numeric/detail/real_impl.hpp (working copy) @@ -133,6 +133,7 @@ parse(Iterator& first, Iterator const& last, Attribute& attr, RealPolicies const& p) { + p.begin_parse(attr); if (first == last) return false; Iterator save = first; @@ -257,6 +258,7 @@ // If we got a negative sign, negate the number traits::assign_to(traits::negate(neg, n), attr); + p.end_parse(attr, true); // maybe this should return a bool and be the return value? // Success!!! return true; }

4 7

[intrusive] Compilation problem with gcc 4.7
by Hartmut Kaiser 07 Aug '13

07 Aug '13

In code which compiled just fine I'm now seeing: In file included from /opt/boost/trunk-debug/boost/intrusive/slist_hook.hpp:24:0, from /opt/boost/trunk-debug/boost/intrusive/slist.hpp:21, from /opt/buildbot/slave/hpx_gcc47_x8664_boosttrunk_debug/build/hpx/lcos/local/mu tex.hpp:23, from /opt/buildbot/slave/hpx_gcc47_x8664_boosttrunk_debug/build/hpx/runtime/compo nents/server/wrapper_heap.hpp:20, from /opt/buildbot/slave/hpx_gcc47_x8664_boosttrunk_debug/build/hpx/runtime/compo nents/server/managed_component_base.hpp:13, from /opt/buildbot/slave/hpx_gcc47_x8664_boosttrunk_debug/build/hpx/lcos/base_lco .hpp:12, from /opt/buildbot/slave/hpx_gcc47_x8664_boosttrunk_debug/build/hpx/lcos/base_lco _with_value.hpp:11, from /opt/buildbot/slave/hpx_gcc47_x8664_boosttrunk_debug/build/hpx/performance_c ounters/counters.hpp:12, from /opt/buildbot/slave/hpx_gcc47_x8664_boosttrunk_debug/build/hpx/runtime/compo nents/server/runtime_support.hpp:32, from /opt/buildbot/slave/hpx_gcc47_x8664_boosttrunk_debug/build/hpx/runtime.hpp:1 2, from /opt/buildbot/slave/hpx_gcc47_x8664_boosttrunk_debug/build/src/hpx_main.cpp: 7: /opt/boost/trunk-debug/boost/intrusive/detail/generic_hook.hpp: At global scope: /opt/boost/trunk-debug/boost/intrusive/detail/generic_hook.hpp:134:55: error: declaration of typedef struct boost::intrusive::hooktags<typename GetNodeAlgorithms::type::node_traits, Tag, LinkMode, BaseHookType> boost::intrusive::generic_hook<GetNodeAlgorithms, Tag, LinkMode, BaseHookType>::hooktags [-fpermissive] /opt/boost/trunk-debug/boost/intrusive/detail/generic_hook.hpp:84:8: error: changes meaning of hooktags from struct boost::intrusive::hooktags<typename GetNodeAlgorithms::type::node_traits, Tag, LinkMode, BaseHookType> [-fpermissive] Ion, could you fix this, please? Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu

2 2

MinGW test failures
by Andrey Semashev 07 Aug '13

07 Aug '13

Hi, I can see that almost all MinGW tests (jc-bell.com runner) for trunk are failing, at least for Boost.Log [1] and Boost.Atomic [2]. However, test logs don't show any errors, only compiler warnings. Does anyone know what is the problem? Also, this is not the first time when I see no errors in logs while the test is marked as failed. This is really unhelpful. Are some logs being lost by the test running suite? [1] http://www.boost.org/development/tests/trunk/developer/log.html [2] http://www.boost.org/development/tests/trunk/developer/atomic.html

2 1