- Boost-users - lists.boost.org

[heap] Singular handle issue with MSVC iterator debug facilities
by Mateusz Loskot 09 Aug '17

09 Aug '17

Hi, Using VS2017 and Boost 1.64, I'm compiling a program which uses boost::heap::d_ary_heap. In debug configuration (with default _ITERATOR_DEBUG_LEVEL), I'm observing issues at run-time when a handle of item on the heap is compared against default-constructed instance of handle_type. BTW, the handle_type compiled in is based on std::list::iterator as defined in boost::heap::detail::priority_queue_mutable_wrapper. The issue is that MSVC iterator debug facilities break execution with File: c:\program files (x86)\microsoft visual studio\2017\professional\vc\tools\msvc\14.10.25017\include\list Line: 290 Expression: list iterators incompatible AFAIU, handle_type{}; seems to yield handle h object wrapping singular iterator. Below, minimal example to reproduces the problem is included. While debugging the sample, Visual C++ debugger does not show the iterator wrapped by the handle as default-constructed with null node pointer. Instead, it displays garbage: ((???, ???), ???) // ------------------------------------------------------------------ #include <cstdint> #include <functional> #include <boost/heap/d_ary_heap.hpp> using NodeID = std::uint32_t; using EdgeWeight = std::int32_t; using HeapData = std::pair<EdgeWeight, NodeID>; using HeapContainer = boost::heap::d_ary_heap< HeapData, boost::heap::arity<4>, boost::heap::mutable_<true>, boost::heap::compare<std::greater<HeapData>>>; using HandleType = HeapContainer::handle_type; int main() { HeapContainer heap; auto const handle = heap.push(std::make_pair(100, 1)); handle == HandleType{}; // _DEBUG_ERROR("list iterators incompatible"); return 0; } // ------------------------------------------------------------------ Is this a known MSVC drawback while working with boost::heap::d_ary_heap or above the handle_type is actually misused? Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

1 0

Boost 1.65.0 Release Candidate 1
by Marshall Clow 09 Aug '17

09 Aug '17

The release candidates for the 1.65.0 release are now available at: https://dl.bintray.com/boostorg/release/1.65.0/source/ The SHA256 checksums are as follows: 0f1352a7738f24b39b564263b66a8c38bc7d984b57406396400474602e961ad3 boost_1_65_0_rc1.7z c2a022d4d6706668ea94b8e799a76e38929e0e34db884ef451fa9d5db6103238 boost_1_65_0_rc1.tar.bz2 7e84a27276792209d48357a0671348768dbf4dd1d4eadbf01b855274208f148d boost_1_65_0_rc1.tar.gz 537c42771b2351b4ea3eb8e9a13a3423edcd155323d2c14c4606cd23fc22d09f boost_1_65_0_rc1.zip 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. Thanks! -- The release managers

4 5

[filesystem] Pull request needs attention
by Robert Dailey 09 Aug '17

09 Aug '17

I have fixed a crash I found due to static initialization ordering in boost filesystem. I have a proposed fix here: https://github.com/boostorg/filesystem/pull/47 It hasn't gotten any attention yet, so I'm hoping someone can offer some advice and/or merge the PR for me. Thanks in advance.

2 1

Problem building Boost 1.64.0 with Oracle Developer Studio 12.6
by Leo Carreon 09 Aug '17

09 Aug '17

Hi Boosters, I have been trying to build Boost 1.64.0 with Oracle Developer Studio 12.6 on Oracle Solaris 11.3 x86_64. There are two errors encountered during the build. They are: 1. Problem with Boost.Optional with this error messages: "libs/log/src/named_scope.cpp", line 118: Error: Use of overloaded binary operator '=' is ambiguous. "./boost/optional/optional.hpp", line 900: Note: Viable candidate 'boost::optional<boost::log::v2_mt_posix::attributes::named_scope_list>& boost::optional<boost::log::v2_mt_posix::attributes::named_scope_list>::operator=<boost::log::v2_mt_posix::attributes::named_scope_list&>(boost::log::v2_mt_posix::attributes::named_scope_list&)'. "./boost/optional/optional.hpp", line 962: Note: Viable candidate 'boost::optional<boost::log::v2_mt_posix::attributes::named_scope_list>& boost::optional<boost::log::v2_mt_posix::attributes::named_scope_list>::operator=<boost::log::v2_mt_posix::attributes::named_scope_list&>(boost::log::v2_mt_posix::attributes::named_scope_list&)'. 2. Problem with Boost.Python with this error message: "libs/python/src/numpy/dtype.cpp", line 61: Error: NPY_FLOAT16 is not defined. Note that these two errors are the cause of 9 Boost shared libraries to not be generated. I would appreciate it very much if someone could give me some pointers on how to resolve the above issues. Kind regards, Leo

1 0

Re: [Boost-users] [filesystem] Pull request needs attention
by Robert Dailey 08 Aug '17

08 Aug '17

On Tue, Aug 8, 2017 at 12:07 PM, Daniela Engert <dani(a)ngrt.de> wrote: > Am 08.08.2017 um 18:20 schrieb Robert Dailey via Boost-users: >> I have fixed a crash I found due to static initialization ordering in >> boost filesystem. I have a proposed fix here: >> https://github.com/boostorg/filesystem/pull/47 > > There is actually an even older (from april) pull request > https://github.com/boostorg/filesystem/pull/43 (by me) open on the very > same subject. > > Ciao > Dani Ah I didn't realize someone else had solved this problem. I will close mine in favor of yours. I don't quite understand why they're trying to share globals/statics between threads without some synchronization, but it's not my battle to deal with. I just want the code to work and not crash my application. Thanks for the reply.

1 0

make file starting out
by Peter Koukoulis 08 Aug '17

08 Aug '17

Hi I am new to setting up make files, and even newer to Boost. I've been using Geany on Ubuntu to learn Boost. When I compile and link using a single file with the following : g++ -g -Wall -std=c++14 -o "%e" "%f" -lboost_thread -DBOOST_THREAD_VERSION=5 -lboost_system -ldl then everything works as expected, for the following that is: #include <iostream> #include <boost/thread.hpp> #include <boost/thread/mutex.hpp> #include <boost/bind.hpp> #include <boost/asio.hpp> class t { private: boost::asio::io_service ios; std::unique_ptr<boost::asio::io_service::work> work_ios; boost::thread_group tg; int f; boost::mutex mx; public: // Constructor t( int p ) : work_ios{std::make_unique<boost::asio::io_service::work>(ios)}, f{p} { if(p>0) p = boost::thread::hardware_concurrency()*2; for ( int i = 0; i < p; ++i ) tg.create_thread( boost::bind( &boost::asio::io_service::run, &ios ) ); } // Destructor ~t () { work_ios.reset(); tg.join_all(); ios.stop(); } template <typename Job> void run_job( Job job ) { boost::unique_lock< boost::mutex > lock( mx ); if ( 0 == f ) return; --f; ios.dispatch( boost::bind( &t::wrap_job, this, boost::function< void() >(job) )); } private: void wrap_job( boost::function< void() > job ) { try { job(); } catch ( const std::exception& ) {} boost::unique_lock< boost::mutex > lock( mx ); ++f; } }; int main() { t tp{2}; tp.run_job( [] () { std::cout << "some work \n"; } ); return 0; } But when I attempt to split "t" into a .h and .cpp file with a separate file for main to test with, my linking does not work. The make output is: g++ test_t.o t.o -o test_t test_t.o: In function `__static_initialization_and_destruction_0(int, int)': test_t.cpp:(.text+0x6e9): undefined reference to `boost::system::generic_category()' test_t.cpp:(.text+0x6f5): undefined reference to `boost::system::generic_category()' The files look as follows: # the makefile: CC=g++ CFLAGS=-c -Wall -std=gnu++14 -lboost_system -lboost_thread -DBOOST_THREAD_VERSION=5 -ldl -lpq all: test_t test_t: t.o test_t.o $(CC) test_t.o t.o -o test_t t.o: t.cpp $(CC) $(CFLAGS) t.cpp test_t.o: test_t.cpp $(CC) $(CFLAGS) test_t.cpp clean: rm *o test_t.o test_t // .h file #ifndef T_H_ #define T_H_ #include <boost/thread.hpp> #include <boost/thread/mutex.hpp> #include <boost/bind.hpp> #include <boost/asio.hpp> class t { private: boost::asio::io_service ios; std::unique_ptr<boost::asio::io_service::work> work_ios; boost::thread_group tg; int f; boost::mutex mx; public: t( int p = 0 ); ~t(); template <typename Job> void run_job( Job job ) { boost::unique_lock< boost::mutex > lock( mx ); if ( 0 == f ) return; --f; ios.dispatch( boost::bind( &t::wrap_job, this, boost::function< void() >(job) )); } private: void wrap_job( boost::function< void() > job ) { try { job(); } catch ( const std::exception& ) {} boost::unique_lock< boost::mutex > lock( mx ); ++f; } }; #endif // .cpp file #include "t.h" // Constructor t::t( int p ) : work_ios{std::make_unique<boost::asio::io_service::work>(ios)}, f{p} { if(p>0) p = boost::thread::hardware_concurrency()*2; for ( int i = 0; i < p; ++i ) tg.create_thread( boost::bind( &boost::asio::io_service::run, &ios ) ); } // Destructor t::~t () { work_ios.reset(); tg.join_all(); ios.stop(); } // main file #include <iostream> #include "t.h" int main() { t tp{4}; tp.run_job( [] () { std::cout << "some work \n"; } ); return 0; } Could somebody point out how the make file should look like ? thanks pkl

4 3

boost::asio::async_read Error Operation canceled
by jupiter 07 Aug '17

07 Aug '17

Hi, I have a client program written by someone who is no longer available. The client program can send a message via async_write to server, but when the server responded back, the client boost::asio::async_read got an error of Operation cancelled. Searching from the Internet, it said the program was caused mostly by using this which should be fixed by using shared_from_this(). But in my client program it does not use this or shared_from_this, could someone explains if it uses some default format implies to this or shared_from_this in following example? (What (=) means, some kind of lambda function?) boost::asio::async_read(this->socket, boost::asio::buffer(this->messageHeader), [=](const boost::system::error_code &error, const uint32_t length) {this->readMessageHeader(error, length);}); Thank you. Kind regards.

1 0

Boost.Test change between 1.56 and 1.64
by Dominique Devienne 06 Aug '17

06 Aug '17

1.56 class BOOST_TEST_DECL test_tree_visitor { public: // test tree visitor interface virtual void visit( test_case const& ) {} virtual bool test_suite_start( test_suite const& ) { return true; } virtual void test_suite_finish( test_suite const& ) {} protected: BOOST_TEST_PROTECTED_VIRTUAL ~test_tree_visitor() {} }; 1.64 class BOOST_TEST_DECL test_tree_visitor { public: // test tree visitor interface virtual bool visit( test_unit const& ) { return true; } virtual void visit( test_case const& tc ) { visit( (test_unit const&)tc ); } virtual bool test_suite_start( test_suite const& ts ){ return visit( (test_unit const&)ts ); } virtual void test_suite_finish( test_suite const& ) {} protected: BOOST_TEST_PROTECTED_VIRTUAL ~test_tree_visitor() {} }; To list test suites and test cases of our test exes, I implemented a custom visitor in Boost 1.56 and simply did const auto& master_ts = but::framework::master_test_suite(); but::traverse_test_tree(master_ts, visitor); This is broken in 1.64, none of the old methods from the visitor are called, and thus no suites or cases are discovered. Two out of 3 of the old methods are forwards to the new visit() method, and obviously the implementation only calls the new visit(). The forwarding should be in the other direction for backward-compatibility. Looking for visit/visitor in http://www.boost.org/doc/libs/1_64_0/libs/test/doc/html/boost_test/change_l… yield nothing. Can someone please shed some light on this incompatible change? Thanks, --DD

2 2

Boost statechart
by Georg Gast 02 Aug '17

02 Aug '17

Hi, as the last changelog entry in statechart is from 1.46. Is it still maintained? Greetings Georg

1 0

[review][mp11] Review report
by Bjorn Reese 02 Aug '17

02 Aug '17

I. VERDICT Mp11 is accepted unconditionally into Boost. There were 14 accept votes and 1 conditional accept vote. See list at end of this report. II. DESIGN Reviewers evaluated the design as very good. Many agreed with the design principle of using template aliases on type lists, which means that Mp11 can be used on std, boost, and custom type lists. Integration with MPL was discussed. This resulted in a new header file <boost/mp11/mpl.hpp> that enables the conversion between mp_list (and std::tuple) and MPL sequences. A version of mp_eval_if that can apply a metafunction to type lists in both the true and false branch was requested. This is not possible due to C++ limitations (template parameter pack must be at the end.) Instead two alternatives were suggested: (1) use a nested mp_eval_if in the true branch, or (2) use mp_if<>::type with mp_defer in both branches. Extra metafunctions were added for working with map and sets: mp_is_set, mp_is_map, and mp_map_keys which returns a list of all keys. No review without a discussion about names. The mp_ prefix received most comments. The prefix is used to avoid collision between mp11 names and C++ keywords. The argument against the mp_ prefix was that MPL and other Boost libraries already have established trailing underscore as the naming convention. The argument in favor is that the mp_ prefix is better suited for later C++ standardization. Other names that deviate from MPL, such as apply versus fn, were also pointed out, and the names of tuple operations were also discussed. III. IMPLEMENTATION The reviewers who looked at the implementation were generally pleased with its quality and simplicity. A faster version of mp_find was proposed during review. On reviewer pointed out that const lists causes obscure compilation errors. IV. DOCUMENTATION The evaluation of the documentation was more mixed. Some found it good, while others found it too terse. A recurring comment was that the documentation is missing beginner-level explanations and examples. For instance, the tuple_cat example was mentioned as being too advanced for an introduction. More examples with higher-order metafunctions (e.g. mp_bind) was requested. The reference documentation does not state the pre-conditions of the metafunctions. For example, what happens when indices are out of bounds? The description of map (list of lists) lead to confusion. Mp11 map entries have one unique key-type, and zero or more value-types. The ability to have multiple value-types per key-type makes it possible to emulate multi-maps. Some where unsure whether C++11 or C++14 was required for the library. There were plenty of other useful comments that I will omit from the review report for the sake of brevity. V. USEFULNESS The library was generally deemed useful. It was discussed if C++11 (and later) makes it too easy to write our own metaprogramming utilities, and thus not needing a metaprogramming library. This was not directed at Mp11 in particular. Some of the arguments in favor of a metaprogramming library were better performance and portability. I would like to add another advantage of a metaprogramming library, namely that it gives us a common vocabulary. VI. CONCLUSION The library fulfills the quality and usefulness criteria without major outstanding issues. The library is therefore cleared to be included into Boost. My main recommendation as review manager is to make the documentation more beginner-friendly before the library is added to Boost. This is a recommendation, not a requirement. VII. PARTICIPANTS The following formal reviews were posted: * Barrett Adair : Accept * Brook Milligan : Accept * Edward Diener : Accept * Glen Fernandes : Accept * Jason Rice : Accept * Joaquin M López Muñoz : Conditional accept * John P Fletcher : Accept * Lee Clagett : Accept * Paul Fultz : Accept * Peter Koch Larsen : Accept * Robert Ramey : Accept * Roberto Hinz : Accept * Vijayan : Accept * Vinnie Falco : Accept * Zach Laine : Accept I would like to thank all participants for their efforts. I would also like to thank Peter Dimov for bringing such a high-quality library to Boost.

2 1