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

[graph] Compilation error with adjacency_list and C++11
by Sebastien Loriot (GeometryFactory) 18 Jul '16

18 Jul '16

Hello, the program below does not compile at least with g++ 5.3.1 and clang++ 3.5.2-1 when using c++11 standard. If I comment line #1 it compiles. If I change #2 to undirectedS it compiles. Is there anything wrong in my code or is it a problem in boost's? Thanks, Sebastien. #include <boost/graph/adjacency_list.hpp> struct A { A(){} A(const A& ){} // #1 A& operator=(const A&){return *this;} }; typedef boost::adjacency_list<boost::listS, boost::vecS, boost::directedS, //#2 A > Graph; int main() { Graph g; boost::add_vertex(g); return 0; }

2 2

[type_index] Interest in dynamic_cast emulation?
by Chris Glover 17 Jul '16

17 Jul '16

Hi, I reached for Boost.TypeIndex the other day expecting to find a kind of dynamic_cast I could use in the absence of Rtti. I didn't find it, so I wrote something to emulate it using type_index internally. It's working, but before I go too far and clean this up and possibly submit a pull request, I would like to gauge if there's interest in such a thing or if there's some fundamental reason why it doesn't exist. So, thoughts? Thanks, -- chris

5 8

[contract] Strong exception safety guarantees
by Lorenzo Caminiti 15 Jul '16

15 Jul '16

Hello all, I've been considering adding a .except(...) construct to Boost.Contract that will allow to specify conditions to check at function exit but when the function body throws (in contrast to postconditions that are checked at function exit but only when the function body does not throw). I think .except(...) could be used to assert strong exception safety guarantees... (note that class invariants are already checked at exit of public functions and also when the public function bodies throw, but invariants are suited to assert only basic, and not strong, exception safety guarantees). That might help addressing a point made in P0147R0 under the "Contracts and Exceptions" section: ``Some operations make stronger exception safety claims. In particular, they claim that an exception thrown from a member function will leave the state of an object unchanged from its state on function entry. If we invalidate postconditions on exceptions, we appear to have no mechanism to describe strong exception safety.'' For example, the following swap ensures to leave its arguments unchanged when it throws: void swap(std::string& a, std::string& b) { boost::contract::old_ptr<std::string> old_a = BOOST_CONTRACT_OLDOF(a); boost::contract::old_ptr<std::string> old_b = BOOST_CONTRACT_OLDOF(b); boost::contract::guard c = boost::contract::function() .postcondition([&] { // Checked at function exit but only if body does not throw. BOOST_CONTRACT_ASSERT(a == *old_b); BOOST_CONTRACT_ASSERT(b == *old_a); }) .except([&] { // Checked if body throws (strong exception safety guarantees). BOOST_CONTRACT_ASSERT(a == *old_a); BOOST_CONTRACT_ASSERT(b == *old_b); }) ; ... // Body implementation (which might throw). } Would this be beneficial? Thanks, --Lorenzo

2 5

smartptr maintained
by Karolin Varner 15 Jul '16

15 Jul '16

Hi, is smartptr still being maintained? There are four pull requests, one more than a year old. Best, Karolin Varner

2 3

[graph] A* implementation doesn't follow the algorithm
by Nick Lamprianidis 14 Jul '16

14 Jul '16

For the A* algorithm holds that when a new vertex v is reached through a shorter path, then v is added to the open set. But looking at the boost graph's A* implementation, which is based on the BFS algorithm, one can see that a target vertex is added to the priority queue, regardless of whether the relevant edge is being relaxed. This creates the following situation: The execution starts and you get to a point where you know you cannot reach the goal: no vertices with finite cost in the priority queue. Normally, you would expect that the priority queue is empty and thus the execution ends. Instead, the execution continues, since the priority queue is filled with all those vertices (with infinite cost) that got added for no reason. In an application where the state of a target vertex v gets set when an associated edge is being relaxed, a problem arises. In the situation mentioned above, uninitialized vertices reach the visitor's examine_vertex method. Unless you know what's really happening, so you can take care to add a test condition to exit, it leaves you wondering what's going wrong. I propose that you either change the implementation or at least update the documentation (pseudocode). -- Nick Lamprianidis http://paign10.me

3 2

[log][regression] Error with Boost.Lob build jamfile breaks MinGW regression tester in develop
by Ion Gaztañaga 13 Jul '16

13 Jul '16

Hi, My develop branch regression runner fails whereas the master one works fine. The develop runner fails with all Mingw targets (msvc 7.1 works fine), with this error: ************************************ # Starting tests ("c:\boost\develop\boost_bb\src\engine\bin.ntx86\bjam.exe" "-sBOOST_BUILD_PATH=c:\boost\develop;c:\boost\develop\boost_bb\src" "-sBOOST_ROOT=c:\boost\develop\boost_root" "--boost=c:\boost\develop\boost_root" "--boost-root=c:\boost\develop\boost_root" "--boost-build=c:\boost\develop\boost_bb\src" "--debug-configuration" -l300 toolset=gcc-6.1c++14 -d2 preserve-test-targets=off --dump-tests -j3 --abbreviate-paths debug-symbols=off -m64 "--build-dir=c:\boost\develop\results" >>"c:\boost\develop\results\bjam.log" 2>&1)... c:\boost\develop\boost_root\status> "c:\boost\develop\boost_bb\src\engine\bin.ntx86\bjam.exe" "-sBOOST_BUILD_PATH=c:\boost\develop;c:\boost\develop\boost_bb\src" "-sBOOST_ROOT=c:\boost\develop\boost_root" "--boost=c:\boost\develop\boost_root" "--boost-root=c:\boost\develop\boost_root" "--boost-build=c:\boost\develop\boost_bb\src" "--debug-configuration" -l300 toolset=gcc-6.1c++14 -d2 preserve-test-targets=off --dump-tests -j3 --abbreviate-paths debug-symbols=off -m64 "--build-dir=c:\boost\develop\results" 1>>"c:\boost\develop\results\bjam.log" 2>&1 # Running Boost.Build tests Traceback (most recent call last): File "run.py", line 71, in <module> runner(root) File "c:\boost\develop\boost_regression_src\regression.py", line 287, in __init__ self.main() File "c:\boost\develop\boost_regression_src\regression.py", line 624, in main getattr(self,action_m)() File "c:\boost\develop\boost_regression_src\regression.py", line 589, in command_regression self.command_test() File "c:\boost\develop\boost_regression_src\regression.py", line 368, in command_test self.command_test_boost_build() File "c:\boost\develop\boost_regression_src\regression.py", line 410, in command_test_boost_build "boost/bin.v2/libs/any/test/any_test.test")); WindowsError: [Error 3] The system cannot find the path specified: 'c:\\boost\\develop\\results\\boost/bin.v2/libs/any/test/any_test.test/*.*' ************************************ That path ("..libs/any/test/any_test.test/) is hardcoded in regression.py, but it's not generated in my bin.v2 so it's reasonable an error saying that the system can't find the path ;-) It seems that error occurs before boost.build tests, as bjam.log shows: ************************************ C:/boost/develop/boost_bb/src/build\targets.jam:1077: in evaluate-requirements from module targets error: Can not evaluate conditional properties <conditional>@Jamfile<C:\boost\develop\boost_root>%Jamfile<C:\boost\develop\boost_root>.handle-static-runtime <conditional>@Jamfile<C:\boost\develop\boost_root>%boostcpp.deduce-address-model <conditional>@Jamfile<C:\boost\develop\boost_root>%boostcpp.deduce-architecture <conditional>@Jamfile<C:\boost\develop\boost_root\libs\log\build>%Jamfile<C:\boost\develop\boost_root\libs\log\build>.check-instruction-set <conditional>@Jamfile<C:\boost\develop\boost_root\libs\log\build>%Jamfile<C:\boost\develop\boost_root\libs\log\build>.check-message-compiler <conditional>@Jamfile<C:\boost\develop\boost_root\libs\log\build>%Jamfile<C:\boost\develop\boost_root\libs\log\build>.check-pthread-mutex-robust <conditional>@Jamfile<C:\boost\develop\boost_root\libs\log\build>%Jamfile<C:\boost\develop\boost_root\libs\log\build>.check-visibility <conditional>@Jamfile<C:\boost\develop\boost_root\libs\log\build>%Jamfile<C:\boost\develop\boost_root\libs\log\build>.select-arch-specific-sources <conditional>@Jamfile<C:\boost\develop\boost_root\libs\log\build>%Jamfile<C:\boost\develop\boost_root\libs\log\build>.select-platform-specific-sources <conditional>@Jamfile<C:\boost\develop\boost_root\libs\log\build>%Jamfile<C:\boost\develop\boost_root\libs\log\build>.select-regex-backend <link>shared:<define>BOOST_LOG_DLL <target-os>cygwin:<define>BOOST_USE_WINDOWS_H <target-os>cygwin:<define>NOMINMAX <target-os>cygwin:<define>SECURITY_WIN32 <target-os>cygwin:<define>WIN32_LEAN_AND_MEAN <target-os>cygwin:<define>__USE_W32_SOCKETS <target-os>cygwin:<library>/boost/log//advapi32 <target-os>cygwin:<library>/boost/log//mswsock <target-os>cygwin:<library>/boost/log//ws2_32 <target-os>freebsd:<library>/boost/log//rt <target-os>hpux:<define>_XOPEN_SOURCE=600 <target-os>hpux:<library>/boost/log//ipv6 <target-os>linux:<define>_XOPEN_SOURCE=600 <target-os>linux:<library>/boost/log//rt <target-os>qnxnto:<library>/boost/log//socket <target-os>solaris:<define>_XOPEN_SOURCE=500 <target-os>solaris:<define>__EXTENSIONS__ <target-os>solaris:<library>/boost/log//nsl <target-os>solaris:<library>/boost/log//socket <target-os>windows:<define>BOOST_USE_WINDOWS_H <target-os>windows:<define>NOMINMAX <target-os>windows:<define>SECURITY_WIN32 <target-os>windows:<define>WIN32_LEAN_AND_MEAN <target-os>windows:<library>/boost/log//advapi32 <target-os>windows:<library>/boost/log//mswsock <target-os>windows:<library>/boost/log//ws2_32 <threading>multi:<library>/boost/atomic//boost_atomic <threading>multi:<library>/boost/thread//boost_thread <threading>single:<define>BOOST_LOG_NO_THREADS <toolset>clang:<cxxflags>-ftemplate-depth-1024 <toolset>como-linux:<define>_GNU_SOURCE=1 <toolset>como:<link>static <toolset>darwin:<cxxflags>-ftemplate-depth-1024 <toolset>gcc,<target-os>cygwin:<linkflags>-Wl,--enable-auto-import <toolset>gcc,<target-os>windows:<linkflags>-Wl,--enable-auto-import <toolset>gcc:<cxxflags>-fno-strict-aliasing <toolset>gcc:<cxxflags>-ftemplate-depth-1024 <toolset>intel-darwin:<cxxflags>-wd177,780,2196,1782,193,304,981,1418,411,734,279 <toolset>intel-linux:<cxxflags>-wd177,780,2196,1782,193,304,981,1418,411,734,279 <toolset>intel-win:<cxxflags>/Qwd177,780,2196,1782,193,304,981,1418,411,734,279 <toolset>intel-win:<define>_CRT_SECURE_NO_DEPRECATE <toolset>intel-win:<define>_CRT_SECURE_NO_WARNINGS <toolset>intel-win:<define>_SCL_SECURE_NO_DEPRECATE <toolset>intel-win:<define>_SCL_SECURE_NO_WARNINGS <toolset>msvc,<runtime-link>shared:<threading>multi <toolset>msvc:<cxxflags>/bigobj <toolset>msvc:<cxxflags>/wd4003 <toolset>msvc:<cxxflags>/wd4456 <toolset>msvc:<cxxflags>/wd4459 <toolset>msvc:<cxxflags>/wd4503 <toolset>msvc:<define>_CRT_SECURE_NO_DEPRECATE <toolset>msvc:<define>_CRT_SECURE_NO_WARNINGS <toolset>msvc:<define>_SCL_SECURE_NO_DEPRECATE <toolset>msvc:<define>_SCL_SECURE_NO_WARNINGS <toolset>pgi:<library>/boost/log//rt C:/boost/develop/boost_bb/src/build\targets.jam:1112: in common-properties2 from module targets C:/boost/develop/boost_bb/src/build\targets.jam:977: in targets.common-properties from module targets C:/boost/develop/boost_bb/src/build\targets.jam:1303: in class(a)basic-target.generate from module object(typed-target)@1504 C:/boost/develop/boost_bb/src/build\targets.jam:774: in generate-really from module object(main-target)@49045 C:/boost/develop/boost_bb/src/build\targets.jam:746: in class(a)main-target.generate from module object(main-target)@49045 C:/boost/develop/boost_bb/src/build\targets.jam:895: in targets.generate-from-reference from module targets C:/boost/develop/boost_bb/src/build\targets.jam:1266: in generate-dependencies from module object(typed-target)@14269 C:/boost/develop/boost_bb/src/build\targets.jam:1320: in class(a)basic-target.generate from module object(typed-target)@14269 C:/boost/develop/boost_bb/src/build\targets.jam:774: in generate-really from module object(main-target)@49008 C:/boost/develop/boost_bb/src/build\targets.jam:746: in class(a)main-target.generate from module object(main-target)@49008 C:/boost/develop/boost_bb/src/build\targets.jam:895: in targets.generate-from-reference from module targets C:/boost/develop/boost_bb/src/build\targets.jam:1266: in generate-dependencies from module object(alias-target-class)@36618 C:/boost/develop/boost_bb/src/build\targets.jam:1323: in class(a)basic-target.generate from module object(alias-target-class)@36618 C:/boost/develop/boost_bb/src/build\targets.jam:774: in generate-really from module object(main-target)@36634 C:/boost/develop/boost_bb/src/build\targets.jam:746: in class(a)main-target.generate from module object(main-target)@36634 C:/boost/develop/boost_bb/src/build\targets.jam:272: in class(a)project-target.generate from module object(project-target)@2141 c:/boost/develop/boost_bb/src\build-system.jam:714: in load from module build-system C:\boost\develop\boost_bb\src/kernel\modules.jam:295: in import from module modules C:\boost\develop\boost_bb\src/kernel/bootstrap.jam:139: in boost-build from module C:\boost\develop\boost_root\boost-build.jam:17: in module scope from module ************************************ I can't see why this Jamfile from Boost.Log is accepted when MSVC-7.1 is the target but fails when MinGW is the selected target. I could neither t deduce what is the failing piece of the configuration. The same error happens with a wide range of MINGW targets: GCC-3.4, GCC-4.1, GCC-4.2, GCC-4.3, GCC-4.4, GCC-4.5, GCC-4.6, GCC-4.7, GCC-4.8, GCC-4.9, GCC-5.1, GCC-5.2, GCC-5.3 and GCC-6.1. Any clue on what can be happening and how can it be fixed? Attached regression logs for a failed MINGW regression with GCC 6.1. Best, Ion

3 8

[regression][winapi] Tests not being run
by Andrey Semashev 11 Jul '16

11 Jul '16

Hi, I wrote about it before, but now the problem becomes more weird. The problem is that the tests for Boost.WinAPI are not being run for some reason. What's weird is that now there is one test in the matrix (http://www.boost.org/development/tests/develop/developer/winapi.html) that isn't part of the Boost.WinAPI test suite. I assume that entry is part of the formal checks for the library conformance, since it is present for all libraries. Could someone please have a look why the tests for Boost.WinAPI are not being executed? PS: The link for the __boost_check_library__ entry is broken: https://github.com/boostorg/winapi/blob/developstatus/boost_check_library.py I believe, there's a slash missing between develop and status, and also the repository name should be boost rather than winapi.

2 2

[TypeErasure] Merging pull-requests
by Deniz Bahadir 11 Jul '16

11 Jul '16

Hello everyone, Hello Steven, a view weeks ago I reported some bugs of Boost.TypeErasure [1,2] and provided pull-requests [3,4] which fix these. I just wanted to bring these to attention so that they might get merged and find their way into the next Boost release. Thanks, Deniz PS: There is another open pull-request [5] (by John Maddock) which seems to be even more urgent. [1] https://svn.boost.org/trac/boost/ticket/12291 [2] https://svn.boost.org/trac/boost/ticket/12292 [3] https://github.com/boostorg/type_erasure/pull/9 [4] https://github.com/boostorg/type_erasure/pull/10 [5] https://github.com/boostorg/type_erasure/pull/11 -- BENOCS GmbH Dipl.-Inform. Deniz Bahadir Winterfeldtstr. 21 10781 Berlin Germany Phone: +49 - 30 / 577 0004-22 Email: deniz.bahadir(a)benocs.com www.benocs.com Board of Management: Michael Wolz, Dr.-Ing. Oliver Holschke, Dr.-Ing. Ingmar Poese Commercial Register: Amtsgericht Bonn HRB 19378

2 1

[Hana/Fit] about constexpr/noexcept on equivalent functions to std::overload
by Vicente J. Botet Escriba 08 Jul '16

08 Jul '16

Hi, On the C++ standard meating in Oulu, we decided to make the std::overload function constexpr and conditionaly noexcept and ensure that the overloaded functions shall be constexpr if the stored finctions are. I don't find in the reference documentation of Hana and Fit any reference of whether the overloaded functions preserve constexpr or not. There is a reedit post [1] and CWG issue 1581 [2] that are related. Could the authors clarify? What other think? Best, Vicente [1] https://www.reddit.com/r/cpp/comments/35g7f6/c17_progress_update/cr4mvid [2] http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1581

3 6

[config] msvc-14 config changes heads up
by John Maddock 08 Jul '16

08 Jul '16

I've just pushed some changes to develop so that MSVC-14.0 update 3 no longer defines: BOOST_NO_CXX14_VARIABLE_TEMPLATES BOOST_NO_SFINAE_EXPR BOOST_NO_TWO_PHASE_NAME_LOOKUP As far as I can tell, these cause no new regressions in develop, please let me know if I've missed something. I haven't stopped defining BOOST_NO_CXX11_CONSTEXPR as it causes new failures: * Multiprecision, one new failure when using constexpr features, looks harmless. * Metaparse, causes the compiler to run out of resources on a couple of tests - these test non-default values of BOOST_METAPARSE_LIMIT_STRING_SIZE and are probably harmless. * Type_erasure, causes one new runtime failure. * Chrono, nothing much compiles - this one is the showstopper and needs investigating - any takers? Best, John.

7 13