- Boost-users - lists.boost.org

Problems building with Windows 10.0.10586.0 SDK
by Isaac Lascasas 22 Dec '15

22 Dec '15

I have just downloaded boost 1.60 for a regular update, I have found some kind of build problem with my environment (vs2015 update 1 with Windows SDK 10.0.10586.0). I usually just do this to get a build: call bootstrap b2 headers bjam --build-type=complete --toolset=msvc-14.0 -j13 address-model=64 stage I have never required vcvarsall.bat as boost build allways finds its way. However today it wasn't able to find my windows headers so I manually did this: %comspec% /k ""C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat"" x86_amd64 10.0.10586.0 Even so I found that boost was looking for sdk 10.0.10240.0 (an older one). In my system I still had that sdk directory, however it only contained some UCRT stuff. I uninstalled deliberately that version with my visual studio setup some days ago to upgrade to the new SDK. Until now I didn't found any problems. Maybe you should check this out a bit, I can't figure out if this is a problem of my environment, microsoft or boost build. Bringing 10240 back allows me to build boost 1.60 without any problems. My biggest concern is that boost is building against 10240 when 10586 is available and both are installed, even after an explicit vcvars call to stick to 10586. Best, Isaac Lascasas.

1 0

Duplicate function in composite_key.hpp ?
by John M. Dlugosz 22 Dec '15

22 Dec '15

I'm getting E:\C++Libs\boost_1_59_0\boost/multi_index/composite_key.hpp(638): error C2535: 'boost::multi_index::composite_key_result<boost::multi_index::composite_key<const vst::Foo1::Bar2::Baz3,boost::multi_index::const_mem_fun<vst::Foo1::Bar2::Baz3,UID,UID vst::Foo1::Bar2::Baz3::owner(void) const>,boost::multi_index::member<vst::Foo1::Bar2::Baz3,const uint32_t,pointer-to-member(0x18)>,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type>> boost::multi_index::composite_key<const vst::Foo1::Bar2::Baz3,boost::multi_index::const_mem_fun<vst::Foo1::Bar2::Baz3,UID,UID vst::Foo1::Bar2::Baz3::owner(void) const>,boost::multi_index::member<vst::Foo1::Bar2::Baz3,const uint32_t,pointer-to-member(0x18)>,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type>::operator ()(const boost::reference_wrapper<const Class> &) const': member function already defined or declared with [ Class=vst::Foo1::Bar2::Baz3 ] (compiling source file Bar2\Delta.cpp) (actual names from my code have been sanitized) Using Boost 1.59 and VS2015. The function it points to is result_type operator()(const reference_wrapper<value_type>& x)const but the error message looks like it is duplicating the previous function in the file, result_type operator()(const reference_wrapper<const value_type>& x)const and the chain of instantiation comes through composite_key.hpp, detail/ord_index_args.hpp(46), mpl/eval_if.hpp(41), detail/ord_index_args.hpp(70), ordered_index.hpp(65) with [ Arg1=boost::multi_index::tag<UID,boost::mpl::na,boost::mpl::na,boost::mpl::na,boost::mpl::na,boost::mpl::na,boost::mpl::na,boost::mpl::na,boost::mpl::na,boost::mpl::na,boost::mpl::na,boost::mpl::na,boost::mpl::na,boost::mpl::na,boost::mpl::na,boost::mpl::na,boost::mpl::na,boost::mpl::na,boost::mpl::na,boost::mpl::na>, Arg2=boost::multi_index::composite_key<const vst::Foo1::Bar2::Baz3,boost::multi_index::const_mem_fun<vst::Foo1::Bar2::Baz3,UID,UID vst::Foo1::Bar2::Baz3::owner(void) const>,boost::multi_index::member<vst::Foo1::Bar2::Baz3,const uint32_t,pointer-to-member(0x18)>,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type>, Arg3=boost::mpl::na ] What's going on here? This worked previously with Boost 1.55 and VS2010.

1 0

[serialization] How to serialize an atomic<> value?
by Merrill Cornish 21 Dec '15

21 Dec '15

I am running Boost_1_60_0 on Windows 10 64bit on MinGW64: I have this class data member I want to serialize: std::atomic< std::time_t > mUpdate; Since I'm on a 64-bit machine, serialization recognizes that as atomic< long long int >. However, given ar & mUpdate; serialization says it does not know how to serialize atomic< long long int >. My solution, which compiles cleanly, is std::time_t updateTime = mUpdateTime.load(); ar & updateTime; mUpdateTime = updateTime; // assign is atomic My reasoning is that on load (ar => mUpdateTime), the first line is useless, but harmless. Similarly, on save (ar <= mUpdateTime), the last line is redundant, but also harmless. Of course, the application is not executing during serialization and de-serialization. As I said, this compiles without error or warning; but I worry that I have missed something. Any thoughts? Merrill Cornish Once I see how to get the above working, my next project will be std::atomic< std::shared_ptr< boost::variant<...> > mValue;

2 2

Why does BOOST_TEST() treat std::string as a collection?
by Brad Spencer 21 Dec '15

21 Dec '15

Why does BOOST_TEST() compare std::string values as collections instead of scalars (by default)? It's odd that the following produce different output, for example: BOOST_TEST(std::string("a") == "b"); BOOST_TEST(std::string("a") == std::string("b")); This will output: test.cc(6): error: in "test": check std::string("a") == "b" has failed [a != b] test.cc(7): error: in "test": check std::string("a") == std::string("b") has failed Note the lack of "[a != b]" on the second case. Also note that BOOST_CHECK_EQUAL() would emit as in the first form. This seems to be because std::string is_forward_iterable, and thus falls into the collection_comparison_op.hpp comparators instead of the scalar comparators. Is this intentional or an oversight? As a simple fix, adding a condition to the partial specialization of the collection_comparison_op.hpp comparators that specifically excludes std::string is enough to have std::string treated as scalars. For example, to handle std::string but not std::wstring with C++11 support: template<typename Lhs,typename Rhs> struct name<Lhs,Rhs,typename boost::enable_if_c< unit_test::is_forward_iterable<Lhs>::value && unit_test::is_forward_iterable<Rhs>::value && !(std::is_same<typename std::decay<Lhs>::type, std::string>::value || std::is_same<typename std::decay<Rhs>::type, std::string>::value) >::type (The above is an example and not a complete change supporting std::wstring and C++98.) -- Brad Spencer

2 1

Boost.Serialization broken for wchar_t
by gast128 20 Dec '15

20 Dec '15

following code used to work in boost 1.57 void f() { std::wstring wstr = L"\u20AC"; std::wofstream ofs(L"c:\\temp\\bla.xml"); boost::archive::xml_woarchive oa(ofs); oa << boost::serialization::make_nvp("tag", wstr); } However in 1.60 it gives an exception, since it cannot convert the uniocde character. It seems that in 1.57 in xml_woarchive_impl the utf8_codecvt_facet is set, but this has been disabled in 1.60. What is the solution / workaround?

2 3

boost::property_tree::read_json fails on previously supported comments 1.59
by Millman, Mark 19 Dec '15

19 Dec '15

I recently upgraded from 1.56 to 1.59 and my hundreds of well commented JSON parameter files now all fail on the first commented line. This is true for /* */ and // style comments. The exception.what() string thrown by boost::property_tree::read_json(filename,propertyTree) is filename.json(linenumber): expected key string. As I remove comments from my test JSON file the line number advances to the next comment. Any hints as to how to deal with this? Removing all my comments is not an option. Thanks, Mark --

2 5

[boost.users] [statechart] question about event processing rules in orthogonal states.
by Ernesto Rodriguez Reina 19 Dec '15

19 Dec '15

Hi everyone, The statechart search for an event handler in post-order (children first then parent), however when we have orthogonal states involved then the behaviour I am experiencing is different. Let say we have an state X with two children [orthogonal] states Y and W. Assuming none of the handlers discard (or defer) an event, the handler for that event is called in the following order: Y, X, W, X. Note that the handler of X is called twice. The following code demonstrates the issue: <code> struct EvTest : sc::event< EvTest > {}; struct Test; struct Inner1; struct Inner2; struct Machine : sc::state_machine< Machine, Test > {}; struct Test : sc::simple_state<Test, Machine, mpl::list<Inner1, Inner2> >{ typedef sc::custom_reaction< EvTest > reactions; sc::result react( const EvTest){ std::cout << "Test" << std::endl; // return discard_event(); return forward_event(); } }; struct Inner1 : sc::simple_state<Inner1, Test::orthogonal< 0 > >{}; struct Inner2 : sc::simple_state<Inner2, Test::orthogonal< 1 > >{ typedef sc::custom_reaction< EvTest > reactions; sc::result react( const EvTest){ std::cout << "Inner2" << std::endl; return forward_event(); } }; </code> When the event "EvTest" is received, the output I am getting is: <output> Test Inner2 Test </output> If there something that I am missing? Best, Ernesto Rodriguez Reina

1 0

how to help an object to delete itself the boost way
by Ireneusz Szcześniak 18 Dec '15

18 Dec '15

Hi, In my code there are objects created, which delete themselves. They can do it in the constructor, or later in some function. This is ugly, and I'm getting some wierd behaviour, probably because of this bad design. Is there a good Boost way of resolving my problem? Thanks, Irek

6 10

Negative effect of expected-to-fail tests in compiler development projects.
by Sergey Sprogis 18 Dec '15

18 Dec '15

I’m wondering how difficult it would be to add into bjam one option, something like: -negative_tests=off which will not launch any of negative (expected to fail) tests. For people who use Boost to test newly developed compilers negative tests are quite a nuisance. I mean those tests which got “compile_fail” and “run_fail” status inside final *.xml file generated at the end of Boost regression testing. [ they are also marked similarly inside Jamfiles ] That’s because newly developed compilers in their early stages of implementation normally have bugs which produce a lot o false error messages for correct Boost code. Important task here is to extract those messages, to evaluate them, and to prove that they are indeed correct, but compiler is wrong. And when hundreds of such false error messages are mixing together with thousands of legitimate error messages produced by negative tests (there are > 700 of them in boost.1.59.0, for example) it becomes a non-trivial task to filter them out. So the natural desire is not to launch such tests at all. Another, slightly unpleasant effect of negative tests is that they appear during so called “test pass rate” calculations during compiler testing process. Typically managers responsible for compiler development want to know the progress in terms of what “test pass rate” produces new compiler for the whole Boost testing or for the testing of some specific libraries. Normally such pass rate is calculated as the ratio between number of passed tests and the total number of tests. But ideally, tests in those calculations should be correct, so if they fail, it 100% means compiler bugs. And here again, negative tests are not useful, and should be avoided to make calculations more accurate. On a side note, I think it could be also useful to add such total testing pass rates into the Boost Regression Dashboard, so the quality of every tested compiler could be easy to seen. Much more people could be interested in looking at such dashboard, I guess.

5 6

boost::mutex::scoped_lock crashes on OSX
by David Medine 18 Dec '15

18 Dec '15

I am using boost in a python extension and it is having some problems on OSX. Specifically, I use a mutex of type boost::mutex in both the constructor and destructor methods. The constructor goes fine and the destructor crashes. The code works perfectly well on both Windows and Linux. When my class is building itself, it calls functions like this one a bunch of times: void enter_headers_phase(bool phase_locked) { if (phase_locked) { boost::mutex::scoped_lock lock(phase_mut_); headers_to_finish_++; } } where phase_mut_ is of type boost::mutex. When debugging in XCode, I see nice looking members for phase_mut_ at this point in the program: phase_mut_ (boost::mutex) m (pthread_mutex_t) __sig (long) 1297437784 1297437784 __opaque char [56] "" Later, when I am destroying, I make a nearly identical call as before: ... { boost::mutex::scoped_lock lock(phase_mut_); shutdown_ = true; } ... but now, my phase_mut_ looks like it has an apparently empty _sig member: phase_mut_ (boost::mutex) m (pthread_mutex_t) __sig (long) __opaque (char [56]) "" When we go down the line of the mutex code in boost and finally arrive at line 62 in boost/thread/pthread/mutex.hpp: ret = ::pthread_mutex_lock(m); I get a segmentation fault: EXC_BAD_ACCESS It seems like this is becausem->_sig is now empty for some reason, but I can not determine why (XCode's debugger won't let me 'watch' this variable) but it should certainly be the case that it doesn't get touched between the apparently successful constructor routines and now. This all happens on OSX Yosemite. I am compiling my extension with LLVM6.1 and I have gnu++0x as the C++ language dialect and libc++ as the stdlib. I am linking statically to boost 1.57 which I built using this command: sudo ./b2 -a cxxflags="-stdlib=libc++" linkflags="-stdlib=libc++" toolset=clang link=static link=shared threading=multi install --prefix=/opt/local --layout-tagged THX! -David

2 4