February 2016 - Boost - lists.preview.boost.org

[geometry][pool][ptr_container][typeof][auto_index][quickbook] Merge to master planned for release?
by Rene Rivera 24 Feb '16

24 Feb '16

There are some changes I did to the cited libraries and tools to deal with some release build infrastructure. I need to know if the maintainers of them are going to merge their respective develop branches to master? I need to know so that I can move forward as quickly as possible to generating CI release packages for the upcoming 1.61 release. Note: If I don't hear soon I might need to do some merging myself on your libraries/tools and end up messing something up ;-) So I would prefer if the maintainers do it. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

4 9

Regression impacting chrono
by Raffi Enficiaud 23 Feb '16

23 Feb '16

Dear all, There is a regression between 180bee and 372c53 on VS, and apparently boost.chrono (and indirectly boost.test...) is impacted: See http://www.boost.org/development/tests/develop/developer/output/teeks99-08e… trace below: ================= cl /Zm800 -nologo @"D:\t08\run\results\boost\bin.v2\libs\chrono\build\msvc-12.0\dbg\adrs-mdl-64\lnk-sttc\thrd-mlt\process_cpu_clocks.obj.rsp" process_cpu_clocks.cpp D:\t08\run\boost_root\boost/system/error_code.hpp(431) : error C2872: 'detail' : ambiguous symbol could be 'boost::detail' or 'boost::operators_impl::detail' ================= Between those 2 revisions, there were updates on - context - dll - system - utility - winapi Thanks, Raffi

2 2

[utility] Re: Massive test failures due to ambiguous namespace
by Rene Rivera 23 Feb '16

23 Feb '16

On Tue, Feb 23, 2016 at 1:31 PM, Markus Trippelsdorf <markus(a)trippelsdorf.de > wrote: > http://www.boost.org/development/tests/develop/developer/summary.html > show many "fails" due to: > > In file included from ../libs/chrono/src/process_cpu_clocks.cpp:17: > In file included from > ../boost/chrono/detail/inlined/process_cpu_clocks.hpp:19: > In file included from ../boost/chrono/process_cpu_clocks.hpp:22: > In file included from ../boost/chrono/detail/system.hpp:12: > ../boost/system/error_code.hpp:431:15: error: 'detail' is not a class, > namespace, or scoped enumeration > { return *detail::throws(); } > ^ > ../boost/system/error_code.hpp:431:15: error: reference to 'detail' is > ambiguous > { return *detail::throws(); } > ^ > ../boost/system/error_code.hpp:421:13: note: candidate found by name > lookup is 'boost::detail' > namespace detail { inline system::error_code * throws() { return 0; } } > ^ > ../boost/operators.hpp:658:11: note: candidate found by name lookup is > 'boost::operators_impl::detail' > namespace detail > ^ > 2 errors generated. > Also.. This is affecting general building of release packages. First time it showed up was with this superproject update < https://travis-ci.org/boostorg/boost/jobs/111041426>. Please fix ASAP! -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

2 2

Massive test failures due to ambiguous namespace
by Markus Trippelsdorf 23 Feb '16

23 Feb '16

http://www.boost.org/development/tests/develop/developer/summary.html show many "fails" due to: In file included from ../libs/chrono/src/process_cpu_clocks.cpp:17: In file included from ../boost/chrono/detail/inlined/process_cpu_clocks.hpp:19: In file included from ../boost/chrono/process_cpu_clocks.hpp:22: In file included from ../boost/chrono/detail/system.hpp:12: ../boost/system/error_code.hpp:431:15: error: 'detail' is not a class, namespace, or scoped enumeration { return *detail::throws(); } ^ ../boost/system/error_code.hpp:431:15: error: reference to 'detail' is ambiguous { return *detail::throws(); } ^ ../boost/system/error_code.hpp:421:13: note: candidate found by name lookup is 'boost::detail' namespace detail { inline system::error_code * throws() { return 0; } } ^ ../boost/operators.hpp:658:11: note: candidate found by name lookup is 'boost::operators_impl::detail' namespace detail ^ 2 errors generated. -- Markus

1 0

boost::container::set insert range bug
by Han Wang 23 Feb '16

23 Feb '16

Hi, Let's say we have some simple code here. boost::container::set<int> s; boost::container::set<int> const sp; s.insert(boost::begin(sp), boost::end(sp)); This insert call will cause "ambiguous call to overloaded function". Best regards, Han

2 1

GSoC Project Proposal - Boost Document Library Extensions
by Anurag Ghosh 23 Feb '16

23 Feb '16

Hello everyone! I wished to propose continue working on the Boost Document Library as a part of the Google Summer of Code 2016, and would like to work on the following things this summer on the library which was started last summer - 1. Integrating Basic Chart Support. 2. Writing comparators for the cells. (Cells are heterogeneous in nature, similar to Boost.Variant) 3. Making cell class have the behavior of a reference to the document's cell. 4. Basic formatting options for cell contents. Kindly make appropriate suggestions to my proposal. The aim of the proposal is to make it a Boost-Ready library. I would remind everyone that the library in its current state has basic spreadsheet functionality like opening, closing and exporting documents, sheet operations and cell,row,column (iterators) operations for Linux and Windows through wrappers over LibreOffice and Microsoft Office API's. ( https://github.com/BoostGSoC15/boost-document) I have been inactive for sometime, but I hope to improve test coverage before March and fix some other issues. Thanks Anurag Ghosh researchweb.iiit.ac.in/~anurag.ghosh

1 0

[Core] BOOST_TRY/BOOST_CATCH
by Chris Glover 22 Feb '16

22 Feb '16

Hi, I ran into a problem when trying to use BOOST_TRY/BOOST_CATCH to add no-exception support to property tree. Here's an example of the original code; try { write_ini(stream, pt, flags); } catch (ini_parser_error &e) { BOOST_PROPERTY_TREE_THROW(ini_parser_error( e.message(), filename, e.line())); } I converted this code to use the macros from core/no_exception_support.hpp *BOOST_TRY *{ write_ini(stream, pt, flags); } *BOOST_CATCH *(ini_parser_error &e) { BOOST_PROPERTY_TREE_THROW(ini_parser_error( e.message(), filename, e.line())); } *BOOST_CATCH_END* The issue is that now the exception, ini_parser_error& e, is not defined when I compile with exceptions off. I solved this by adding a local instance of ini_parser_error above the try block *ini_parser_error e("", "", 0);* BOOST_TRY { write_ini(stream, pt, flags); } BOOST_CATCH (ini_parser_error &e) { BOOST_PROPERTY_TREE_THROW(ini_parser_error( e.message(), filename, e.line())); } BOOST_CATCH_END This is a little gross, but it's not too bad and I was expecting the variable to be optimized away. But it isn't -- instantiating that exception on the stack is very clearly generating instructions on VS2015 and GCC 5.3. While this is not a huge deal, I don't like it so one way I can think to fix this is to conditionally compile out the catch block, but that defeats the purpose of the macros in the first place. BOOST_TRY { write_ini(stream, pt, flags); } BOOST_CATCH (ini_parser_error &e) { *#ifdef BOOST_NO_EXCEPTIONS* BOOST_PROPERTY_TREE_THROW(ini_parser_error( e.message(), filename, e.line())); *#endif* } BOOST_CATCH_END Then I thought maybe I can declval a fake 'e' in the else block by redefining the macros as follows; #ifndef BOOST_NO_EXCEPTIONS #define BOOST_TRY { try { #define BOOST_CATCH(type, var) } catch(type var) { #define BOOST_CATCH_END } } #else #define BOOST_TRY { if(true) { #define BOOST_CATCH(type, var) } else if(false) { type var = boost::declval<type>(); #define BOOST_CATCH_END } } #endif This is working, but is possibly undefined behaviour. Does anyone have thoughts on that? It also requires splitting up the type from the variable name. The next step to this would be to add a third parameter for some constructor args so we can just create an exception object directly. Something like: #define BOOST_CATCH(exception_type, var, args) } else if(false) { boost::decay<exception_type>::type var args; So now the original code would look like this: BOOST_TRY { write_ini(stream, pt, flags); } BOOST_CATCH (ini_parser_error&, e, ("", "", 0)) { BOOST_PROPERTY_TREE_THROW(ini_parser_error( e.message(), filename, e.line())); } BOOST_CATCH_END This is starting to look a little nasty to me so I'm wondering if anyone has any thoughts on this? Should I stop worrying about it and just use the #ifdef? The reality is that I work in an environment without exceptions and we hit these things from time to time so I'd like to fix up as many as possible. Thanks, -- chris

2 2

media file error
by Rainer Deyke 21 Feb '16

21 Feb '16

In "CDs/Presumed Guilty Compilation": "Beyond Dwan - Need.mp3" -> "Beyond Dawn - Need.mp3" -- Rainer Deyke (rainerd(a)eldwood.com)

1 0

What's wrong with this benchmark
by Benedek Thaler 20 Feb '16

20 Feb '16

Dear Boost, In a previous mail, I introduced a container library, `double_ended`. This library has benchmarks [0]. However, the benchmarks show unexpected results. This is what I do [1]: - compile program using G++ 5.3, -O2 - remove CPU0 from kernel scheduler pool (isolcpu=0 boot flag) - disable CPU scaling - pin benchmark thread to CPU0 - in the test, create a vector - reserve memory for 1M unsigned - write a byte to each page reserved, to warm up the page table - get TSC value (machine has constant_tsc flag) - insert 1M unsigned value - get TSC value again, subtract previous value - repeat test 25 times, average results I do this with 3 containers: std::vector, boost::container::vector and double_ended::devector. While the latter two produces almost equivalent results, std::vector seriously falls behind. - No reallocation happens between the TSC sampling - Test order doesn't matter: every order produces the same results - Container size or sample count doesn't matter, same results. - The deviations of individual measures of each container is small, the performance is consistent. - I compared the produced ASM of std::vector and double_ended::devector, they are very similar, almost the same instructions in different order [2]. What do I miss here? Thanks, Benedek [0]: http://erenon.hu/double_ended/double_ended/benchmarks.html [1]: https://github.com/erenon/double_ended/blob/master/benchmark/push_back.cpp [2]: http://pastebin.com/tUL54i9f

3 11

[RFC] C++ apparently lacks a mechanism for locking ranges of a shared resource
by Raphael S Carvalho 20 Feb '16

20 Feb '16

I am very sorry if this topic is unrelated to the topics covered by this mailing list. While developing a small project which consists of exporting a blockv device via network (if you are curious: https://github.com/raphaelsc/blockv) there was the need to lock a range of a shared resource, such as a file. I searched for resources coming from C++ standard library and boost library, but I wasn't able to find anything that would fit my needs. Am I missing something? Anyway, I ended up implementing my own range locking mechanism. The implementation is quite simple, feel free to look it at: https://github.com/raphaelsc/byte-range-lock-cpp/blob/master/range_lock.hh (I made my best effort to document it well) Is there any chance that something like range_lock will be made available in the next versions of boost library? Thank you very much for reading this, Raphael Carvalho

1 0