July 2015 - Boost - lists.boost.org

__NR_eventfd syscall
by Alexey Brodkin 27 Jul '15

27 Jul '15

Hi, When building Boost for ARC architecture we're seeing this failure: --------------------->8--------------------- ./boost/asio/detail/impl/eventfd_select_interrupter.ipp: In member function 'void boost::asio::detail::eventfd_select_interrupter::open_descriptors()': ./boost/asio/detail/impl/eventfd_select_interrupter.ipp:50:50: error: '__NR_eventfd' was not declared in this scope write_descriptor_ = read_descriptor_ = syscall(__NR_eventfd, 0); --------------------->8--------------------- This happens clearly because ARC following Linux kernel's UAPI doesn't define __NR_eventfd syscall. If you look here https://github.com/torvalds/linux/blob/master/include/uapi/asm-generic/unis… you may notice that "eventfd" syscall with some others resides in "#ifdef__ARCH_WANT_SYSCALL_NO_FLAGS". And from what I may see only "score" architecture has this __ARCH_WANT_SYSCALL_NO_FLAGS defined. Most of other arches that don't use unistd.h from "include/uapi/asm-genereic" folder have "eventfd" syscall defined. For example it's true for ARM (both 32 and 64 versions). So I'd say it's not the best way to use directly a syscall that's being obsoleted in "Boost". And so real fix would be to modify Boost's "eventfd_select_interrupter::open_descriptors()" for example with use of really generic "eventfd2" or even better use libc's eventfd() call instead of direct syscall. Any thoughts what would be the best fix here? -Alexey

1 1

[ublas] [1.5.9.0b1] Merge patch for broken boost::numeric::ublas::shallow_array_adaptor since 1.58
by Hugues Malphettes 24 Jul '15

24 Jul '15

Hi everyone, Does somebody knows how to proceed to merge the patch filed here: https://svn.boost.org/trac/boost/ticket/11207 I am forced to remain on 1.57 because of this issue. At the minimum there are 4 projects affected: myself, Mark Moll who filed the issue on track and nasosi and vh4n who filed the same patch here: https://github.com/uBLAS/ublas/pull/30/files I had convinced myself that because it had been merged in github we would be good to go for 1.59. I just tested 1.59.0b1 and it has not been merged. Many thanks for your help! Hugues

1 0

Test Runner Update to vc14.0 - CTP 6
by Tom Kent 23 Jul '15

23 Jul '15

Just a heads up, I have just updated the test runner teeks99-08f-win2012R2-64on64 from vc14.0 - CTP 4 to vc14.0 - CTP 6. The change should show up in the next run of that runner in a few hours. I think some people were waiting to see if MS was fixing some things, so I thought I'd send a message letting people know these results would be available. Tom

7 22

Genetics library: Volunteers needed
by Andy Thomason 23 Jul '15

23 Jul '15

Hi All, I am recruiting users for the putative genetics library. https://github.com/andy-thomason/genetics We have a few simple examples of gene searching and I am working on a more complete aligner example and some performance improvements to the index data structure. For data, you can obtain the human genome from: ftp://ftp.ensembl.org/pub/release-81/fasta/homo_sapiens/dna/Homo_sapiens.GR… Interesting problems we would like to solve: Given a 20 character sequence with up to six errors, what is the fastest way to list all possibilities other than a brute force search (CRISPR). Can we use JNI to connect the library to Hadoop and other distributed seach systems? Can we construct a database of all known viral genomes including recombination? Can we detect variations in MHC VDJ regions within a single sample? Many other interesting puzzles are there to be found... Andy. --- This email has been checked for viruses by Avast antivirus software. http://www.avast.com

4 4

Trouble with Boost.Test on ESXi
by William Winder 23 Jul '15

23 Jul '15

I'm using Boost.Test and Boost v1.55 to unit test an application on Windows/Linux/ESXi. The ESXi build is done on a CentOS 5.10 machine, this has been working well for the main application, but the Boost.Test binary hits an assert before running any tests: /tmp # ./MyTests Test setup error: system_error produced by: ::sigaltstack( 0, &sigstk ) != -1: Function not implemented The "Function not implemented" problem has been a recurring problem for me while making my application compatible with ESXi. My basic understanding is that ESXi implements a subset of glibc. I saw a similar issue here: http://comments.gmane.org/gmane.comp.lib.boost.testing/7782 I'm wondering how I can disable this assert and what the repercussions would be. Thanks

2 1

Re: [boost] Genetics Library:Volunteers Needed
by Mudit Sharma 23 Jul '15

23 Jul '15

Hi! I am deeply interested in volunteering for genetics library in Boost. I have sound knowledge of boost libraries. Note:This project can help me personally. Thanks! M

1 0

gcc 5.1/6.0 warnings with smart_ptr
by Gennadiy Rozental 23 Jul '15

23 Jul '15

Hi, There are bunch of warnings like these: ../boost/smart_ptr/shared_ptr.hpp:249:65: warning: 'template<class> class std::auto_ptr' is deprecated [-Wdeprecated-declarations] Any chance we can shut these down? Maybe update toolset config? Gennadiy

1 0

[boost.test] Assertion/crash
by Philip Bennefall 23 Jul '15

23 Jul '15

Hi all, I am having an issue where boost.test is triggering an assert when I make a BOOST_REQUIRE_EQUAL check. It always gives me the same assert. I am on Windows 7 with Visual C++ 2013, compiling a 32 bit application. This error happens both with boost_1_57_0 and boost_1_58_0. The assert says: Debug Assertion Failed! Program: C:\Windows\system32\MSVCP120D.dll File: C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\INCLUDE\xstring Line: 168 Expression: string iterator + offset out of range Here's the stack: 0041ef44 0149ca07 015c08f0 015c07e0 000000a8 MSVCP120D!std::_Debug_message+0x26 0041ef60 0149ca93 00000053 0041ef80 0041efa0 my_tests!std::_String_const_iterator<std::_String_val<std::_Simple_types<char> > >::operator+=+0x77 0041ef70 0149c91e 00000053 d4f524ac 07d2cff0 my_tests!std::_String_iterator<std::_String_val<std::_Simple_types<char> > >::operator+=+0x13 0041efa0 0149be76 0041efb4 00000053 d4f524ec my_tests!std::_String_iterator<std::_String_val<std::_Simple_types<char> > >::operator++0x4e 0041efe0 0149bdf6 0041f100 07d2ef28 07d2ef7b my_tests!std::_Transform1<char *,std::_String_iterator<std::_String_val<std::_Simple_types<char> > >,char (__cdecl*)(char)>+0x46 0041f034 0149c1b1 0041f100 07d2ef28 07d2ef7b my_tests!std::_Transform1<char *,std::_String_iterator<std::_String_val<std::_Simple_types<char> > >,char (__cdecl*)(char)>+0x96 0041f0c8 0149b5bf 0041f100 07d2cff0 0041f0e0 my_tests!std::transform<std::_String_iterator<std::_String_val<std::_Simple_types<char> > >,std::_String_iterator<std::_String_val<std::_Simple_types<char> > >,char (__cdecl*)(char)>+0x191 0041f148 0149d6e2 0041f18c 00000000 015c0d18 my_tests!boost::unit_test::unit_test_log_t::operator<<+0x10f 0041f2c8 014315dc 0041f320 0041f3f4 015aa770 my_tests!boost::test_tools::tt_detail::check_impl+0x372 0041f364 01404626 00000000 0041f3f4 015aa770 my_tests!boost::test_tools::tt_detail::check_frwd<boost::test_tools::tt_detail::equal_impl_frwd,int,enum my_error_codes>+0xec 0041f458 014050af 000d7550 d4f53c34 00000000 my_tests!basic_operations::playback_decoders::pull_samples+0x146 0041f738 014053e6 015b223c 015b2234 00000000 my_tests!basic_operations::playback_decoders::iteration+0x8cf 0041f758 01405451 d4f53c70 cccccccc cccccccc my_tests!basic_operations::playback_decoders::playback_decoders_mono::test_method+0x26 0041f77c 014399d1 00000000 cccccccc 0041f7a3 my_tests!basic_operations::playback_decoders::playback_decoders_mono_invoker+0x51 0041f790 0148a54f 0041f7cf 076ecff4 00cccccc my_tests!boost::unit_test::ut_detail::invoker<boost::unit_test::ut_detail::unused>::invoke<void (__cdecl*)(void)>+0x21 0041f7a8 01522cc5 0041f7cf 078c4ff0 076ecff0 my_tests!boost::unit_test::ut_detail::callback0_impl_t<boost::unit_test::ut_detail::unused,void (__cdecl*)(void)>::invoke+0x2f 0041f7bc 01522ce7 0041f7cf 0a66aff4 00000000 my_tests!boost::unit_test::callback0<boost::unit_test::ut_detail::unused>::operator()+0x25 0041f7d0 01522a1f 0041f7ef 0041f7f0 01522dbd my_tests!boost::unit_test::`anonymous namespace'::zero_return_wrapper_t<boost::unit_test::callback0<boost::unit_test::ut_detail::unused> >::operator()+0x17 0041f7dc 01522dbd 0a66aff4 0a66aff0 0041f918 my_tests!boost::unit_test::ut_detail::invoker<int>::invoke<boost::unit_test::`anonymous namespace'::zero_return_wrapper_t<boost::unit_test::callback0<boost::unit_test::ut_detail::unused> > >+0xf 0041f7f0 01521e31 0041f918 0a66aff0 0041f810 my_tests!boost::unit_test::ut_detail::callback0_impl_t<int,boost::unit_test::`anonymous namespace'::zero_return_wrapper_t<boost::unit_test::callback0<boost::unit_test::ut_detail::unused> > >::invoke+0x1d 0041f800 01521b6e 0041f814 538d1e44 0041f87c my_tests!boost::unit_test::callback0<int>::operator()+0x21 0041f810 01521312 01620790 0041f918 d4f53370 my_tests!boost::detail::do_invoke<boost::scoped_ptr<boost::detail::translate_exception_base>,boost::unit_test::callback0<int> >+0x3e 0041f87c 01520dc4 0041f918 d4f533f0 00000000 my_tests!boost::execution_monitor::catch_signals+0xd2 0041f8fc 0152259d 0041f918 d4f53268 00000000 my_tests!boost::execution_monitor::execute+0x54 0041f964 014b6723 078c4fa8 d4f5316c 01574668 my_tests!boost::unit_test::unit_test_monitor_t::execute_and_translate+0xad 0041fa60 014a2565 078c4fa8 0041fa7c 014a259a my_tests!boost::unit_test::framework_impl::visit+0x3c3 0041fa6c 014a259a 078c4fa8 01620750 0041fb38 my_tests!boost::unit_test::traverse_test_tree+0x25 0041fa7c 014a22b2 00010040 01620750 d4f53034 my_tests!boost::unit_test::traverse_test_tree+0x2a 0041fb38 014a25b5 06258fa0 01620750 0041fc04 my_tests!boost::unit_test::traverse_test_tree+0x1e2 0041fb48 014a22b2 00000004 01620750 d4f53708 my_tests!boost::unit_test::traverse_test_tree+0x45 0041fc04 014a25b5 07388f98 01620750 0041fdc0 my_tests!boost::unit_test::traverse_test_tree+0x1e2 0041fc14 014a9ccb 00000001 01620750 d4f536cc my_tests!boost::unit_test::traverse_test_tree+0x45 0041fdc0 014b6bc3 00000001 00000001 d4f53538 my_tests!boost::unit_test::framework::run+0x5db 0041fe34 014b6d5c 013b346d 00000001 066fafb0 my_tests!boost::unit_test::unit_test_main+0xb3 0041fe4c 014996f9 00000001 066fafb0 05f44f28 my_tests!main+0x1c 0041fe9c 0149983d 0041feb0 74e4337a 7efde000 my_tests!__tmainCRTStartup+0x199 0041fea4 74e4337a 7efde000 0041fef0 773892e2 my_tests!mainCRTStartup+0xd 0041feb0 773892e2 7efde000 74959ac7 00000000 kernel32!BaseThreadInitThunk+0x12 0041fef0 773892b5 01499830 7efde000 00000000 ntdll!RtlInitializeExceptionChain+0x63 0041ff08 00000000 01499830 7efde000 00000000 ntdll!RtlInitializeExceptionChain+0x36 Does anyone have any tips for things I might try? Thanks in advance for any help on this! Kind regards, Philip Bennefall

2 1

Boost release 1.59.0 beta 1 is now available from SourceForge
by Marshall Clow 22 Jul '15

22 Jul '15

Boost release 1.59.0 beta 1 is now available from SourceForge See http://sourceforge.net/projects/boost/files/boost/1.59.0.beta.1/ For details of what's in the release, see http://www.boost.org/users/history/version_1_59_0.html. Note that the links to files on this web page are for the final release - use the SourceForge link above to get the beta files. Please download the beta, give it a try, and report any problems you encounter. Thanks, -- The Boost Release Team

3 3

[container] [1.59.0b1] Behavioral (runtime) breakage with flat_xxx + ordered_unique_range + non-default comparator
by Adam Merz 21 Jul '15

21 Jul '15

I've encountered a serious behavioral breakage for code using flat_xxx in conjunction with ordered_unique_range and a non-default comparator in 1.59.0b1. Here is a small repro: #include <initializer_list> #include <algorithm> #include <functional> #include <iterator> #include <iostream> #include <boost/container/flat_set.hpp> int main() { namespace bcont = boost::container; auto const p = [](auto const& desc, auto const& s) { std::cout << desc << ": "; std::copy( s.cbegin(), s.cend(), std::ostream_iterator<int>(std::cout, " ") ); std::cout << '\n'; }; auto const r = {4, 3, 2}; bcont::flat_set<int, std::greater<int>> const s{3, 2, 1}; p("orig set", s); auto s1{s}; s1.insert(r.begin(), r.end()); p("without\tordered_unique_range (expected output)", s1); auto s2{s}; s2.insert(bcont::ordered_unique_range, r.begin(), r.end()); p("with\tordered_unique_range (erroneous output)", s2); } I've worked around this locally by rerouting the ordered_unique_range codepath to the default codepath, but this seems like a showstopper for 1.59.0 as the code's behavior has broken entirely silently. Regards, Adam Merz

2 1

Python bindings for Boost.Interprocess
by Edison Gustavo Muenz 21 Jul '15

21 Jul '15

Hi all, this is my first e-mail on the list, so please be nice, I’m new here. I have this problem in which I need to communicate between two processes, one written in C++ (it’s actually a .so) and one written in python. They need to share large arrays. I’ve searched on the internet for a way to use shared-memory in python, and the only alternative I found was POSIX IPC for Python <http://semanchuk.com/philip/posix_ipc/> (which looks good, but it is *nix only). Also, I find the Boost.Interprocess library to be a joy to use, it worked for the problem I had, so I wanted to use it. Since I didn’t find python bindings for Boost.Interprocess is it desirable to have this? I started writing some code which uses a tiny part of Boost.Interprocess that is necessary to solve my problem. It is working already. I’m asking here to know what do boost experts think about this idea, if it unreasonable or if other developers already had this need. Feedback would be greatly appreciated. Thanks, Edison Gustavo Muenz

2 1

[mpl] Updated fixes on 'master'
by Edward Diener 18 Jul '15

18 Jul '15

A number of fixes in mpl, by Bruno Dutra and Deniz Bahadir, had been tested on 'develop' for quite a long time but had not been merged to 'master' for the upcoming release. The regression tests on 'develop' had shown that the fixes were working properly and I have taken the responsibility of merging them now to 'master' for the upcoming release. I will be checking the 'master' regression tests. If there are any problems I will revert this merge but I am 99.99% certain that the changes are correct, so I take full responsibility for merging. The fixes come from Trac items so I feel that correcting these bugs is important for the upcoming release else I would not have performed the merge and the push to Boost.

1 0

[string_ref] [utility] Add string_view?
by Beman Dawes 18 Jul '15

18 Jul '15

Boost has shipped string_ref since 1.53. See www.boost.org/doc/libs/1_58_0/libs/utility/doc/html/string_ref.html In the meantime, the C++ committee has shipped a final version, named string_view, in the Library Fundamentals TS. See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4480.html#string.v… In addition to the name change, the interface in the TS more closely mimics the std::basic_string interface. I'd really like to see the final TS basic_string_view added to Boost so I can start using it now. Using basic_string_ref, and then later having to rename all uses, is less attractive. I suspect others may feel the same way. Because a Boost basic_string_view would be an implementation of a standard library TS class, and because basic_string_ref is already in Boost, it seems a min-review would be sufficient rather than a formal review. So what I'm proposing here is to create a basic_string_view branch of the utility repo, and start working on basic_string_view there. Once it is reasonably compliant with the TS and Boost doc requirements we would hold a mini-review and then merge the branch to develop, and once stable, to release. Comments? --Beman

6 8

Boost 1.57.0 WinCE support/maintenance
by Dennis Driesens 17 Jul '15

17 Jul '15

Hello, We're porting a software product, which uses boost 1.57.0 to Windows embedded compact 7 . In this context I have a few questions. What is the support /maintenance status of boost for Windows embedded compact 7? We patched boost 1.57.0, to make it build for WEC7. Is it possible to have these patches included in boost? Regards, Dennis Driesens Dennis Driesens * Sr. Software Engineer * PU Custom Systems * Dennis.Driesens(a)tomtom.com<mailto:Dennis.Driesens@tomtom.com> * +31 (0) 40 84 44793 office * www.tomtom.com<http://www.tomtom.com>

2 1

svn.boost.org wiki
by Stefan Seefeld 17 Jul '15

17 Jul '15

Hello, I have sent the following to the Boost documentation list, but since this is of broader relevance I have been asked to resend it here... The content of https://svn.boost.org/trac/boost/ seems rather outdated, and it has been confusing me a number of times as it wasn't clear what is and what isn't up-to-date. * There is an entire section "Quick Access to the Boost Subversion Repository". Shouldn't that be removed entirely ? * The section "Git and Modular Boost" starts with "Boost is moving...". Isn't that conversion complete (and thus, shouldn't the docs state that clearly) ? * There are other seemingly outdated bits, but there are relatively minor... What I was actually trying to figure out is how / where to indicate that for Boost.Python I would like issues to be submitted with the respective github issue tracker, rather than the old Boost Trac instance. It's still not clear how to do that (as the Boost docs are again quite monolithic in this respect, i.e. don't allow a per-library policy). So if anyone has suggestions on where / how to express that, please let me know. Thanks ! Stefan -- ...ich hab' noch einen Koffer in Berlin...

4 6

Master branch is open again - for bug fixes, doc updates, etc
by Marshall Clow 16 Jul '15

16 Jul '15

Now that we've shipped the 1.59.0 beta, the master branch is open again for updates. Please do not add new features, etc to the master until after the release. But bug fixes, documentation updates, etc are very welcome. Note that: * GCC 5.2 was released today * VS2015 should be out next week * Clang 3.7 branched for release this week Compatibility with these new compiler releases would be a good thing :-) -- Marshall

1 0

[Iterator][Type_Erasure] Conflicting declaration. (Fix is provided.)
by Deniz Bahadir 16 Jul '15

16 Jul '15

Hi there, I noticed a "conflicting declaration" error when developing a program which uses Boost.Program_Options and Boost.Type_Erasure. Further investigation showed me, that the conflict is actually between Boost.Iterator and Boost.Type_Erasure. A test-case which demonstrates this compiler-error is the following simple two-liner: #include <boost/type_erasure/iterator.hpp> #include <boost/iterator/iterator_adaptor.hpp> Clang is quite verbose and outputs the following: /tmp/boost-1_58/boost/iterator/iterator_adaptor.hpp:44:18: error: target of using declaration conflicts with declaration already in scope using iterators::use_default; ^ /tmp/boost-1_58/boost/iterator/iterator_adaptor.hpp:40:10: note: target of using declaration struct use_default; ^ /tmp/boost-1_58/boost/type_erasure/iterator.hpp:27:8: note: conflicting declaration struct use_default; ^ 1 error generated. The fix is actually quite simple and should be applied to Boost.Iterator. I already provided a pull-request [1] for this. I hope this fix can still make it into the upcoming 1.59 release of Boost. Best regards, Deniz Bahadir [1] https://github.com/boostorg/iterator/pull/15 -- 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

3 2

Boost.DLL formal review is ongoing
by Vladimir Prus 16 Jul '15

16 Jul '15

The formal review of Boost.DLL library by Antony Polukhin is nearing the end of the first week. As of today, over 100 people read through the library's tutorial, suggesting quite some interest. However, no reviews were submitted yet. Please take the time to post your thoughts - even if you don't have time to do a full review, or try the library, comments on design and interfaces are still very valuable. The summary of the library features and review checklists are reproduced below. Boost.DLL is a C++98 library for comfortable work with DLL and DSO. Library provides a portable across platforms way to: - load libraries at runtime - import and export any native functions and variables - make alias names for C++ mangled functions and symbols - query libraries/objects and executables for sections and exported symbols - self loading and self querying - getting program and module location by exported symbol The documentation can be found at: http://apolukhin.github.io/Boost.DLL/index.html and the source can be obtained at: https://github.com/apolukhin/Boost.DLL Please post your reviews on the mailing list and if possible, answer the following questions: - Should the library be accepted? - How useful is it? - What's your evaluation of - Design - Implementation - Documentations - Tests - How much effort did you put into your evaluation? - Did you attempt to use the library? On what systems and compilers? Thanks, Volodya _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

16 42

[afio] AFIO review postponed till Monday
by Niall Douglas 16 Jul '15

16 Jul '15

Just a quick heads up that the AFIO review is postponed till Monday to give me more time to refactor the docs to match the final API. Some quick notes on what will be presented for review, so there are no surprises: 1. I won't have the time to rewrite the code examples into C++ 1z coroutines before the review unfortunately, so you'll get a warning sign in the docs saying that is coming. The code example this matters most to is the find regex in files example as the code is very messy (full of callback handlers) without coroutines. 2. The API presented is expected to be a final API, but the implementation will be a messy conglomeration of the existing mature dispatch engine with the new lightweight future-promises. In other words, code will compile and run, but the internal engine is going to be completely replaced eventually as I debug lightweight future-promises. As lightweight future-promises is all brand new code mostly written between 12am and 4am each night since May after a work day, I don't hugely trust it enough to present you guys with an engine based on it. Just because it passes a conformance suite doesn't mean it is without quirks - plus, I discovered some surprises in the Concurrency TS about which I'll need to get some clarifications. As I mentioned though, the user facing API will be final, as promised. And it does use monads and lightweight future-promise. 3. Minimum compilers will unfortunately be GCC 4.8, clang 3.2 and VS2015. Sorry about that, lightweight monadic future-promises substantially bumped the compiler requirements, even as it is I have several GCC 4.8 specific workarounds. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

1 0

[predef] The predef-check functionality is not working on the Android regression tests
by Edward Diener 15 Jul '15

15 Jul '15

I do not believe that predef-check is working at all on the Android regression tests. Predef itself appears to be working as far as the predef macro values. But attempting to use predef-check to set a <cxxflags> value is just not happening. I can attest that just setting a <cxxflags> value, outside of using predef-check, does work correctly on the Android regression tests. The failure is occurring on my VMD tests. But you can also see the failure on the predef tests also. Looking at the info_as_cpp test output at http://www.boost.org/development/tests/develop/developer/CrystaX-NET-apilev… you can see that BOOST_COMP_CLANG > 0 and BOOST_OS_LINUX = 0. Yet if you look at the corresponding check_value test at http://www.boost.org/development/tests/develop/developer/CrystaX-NET-apilev… you will see that the output is 'CHECK_VALUE == undefined', whereas if predef-check were actually working the output should be 'CHECK_VALUE == 1' ( or 'true' ). In all other environments predef-check is working. Maybe this failure of predef-check somehow occurs because the Android tests are a cross-compile, being done on a Unix system but targeting the Android. But for whatever reason the inability of getting predef-check to work keeps my VMD tests from adding the '-std=c++0x' option and the VMD tests all fail without that option since the variadic macro support in VMD for gcc needs C++11 support or better.

3 6

Re: [boost] [Boost-users] Boost 1_59_0_b1_rc1 is available for testing
by Marshall Clow 15 Jul '15

15 Jul '15

On Tue, Jul 14, 2015 at 9:20 PM, Gavin Lambert <gavinl(a)compacsort.com> wrote: > On 15/07/2015 14:59, Edward Diener wrote: > >> Because MPL is so central to everything it seems it is too late to get >> these fixes into 'master', have the regression tested on 'master' and >> into the upcoming release at this point. >> > > Take this with a grain of salt, since I'm not a library maintainer or > release manager, but: > > Since it's still at a beta release stage (if I'm understanding correctly), > this seems to me like the perfect time to merge bugfixes, especially ones > that have already been tested on develop. > > Part of the point of having a beta cycle is to discover these > accidentally-left-out elements and correct them. > > After we ship the beta, before the 1.59.0 release, library maintainers will have time to fix bugs that were found in the beta. -- Marshall

1 0

[foreach] use of boost_foreach_argument_dependent_lookup_hack
by Joaquin M López Muñoz 15 Jul '15

15 Jul '15

Hi, Boost.MultiIndex indices, which are not copyable, interoperate with Boost.Foreach by defining the following: template<typename SuperMeta,typename TagList> inline boost::mpl::true_* boost_foreach_is_noncopyable( boost::multi_index::detail::sequenced_index<SuperMeta,TagList>*&, boost::foreach::tag) { return 0; } Unfortunately Qt (in some configuration modes, at least), defines a macro foreach to Q_FOREACH, which produces the following problem, even if Boost.Foreach was not intended to be used: http://tinyurl.com/nq52xho My question is: would it be OK if the code above was rewritten like template<typename SuperMeta,typename TagList> inline boost::mpl::true_* boost_foreach_is_noncopyable( boost::multi_index::detail::sequenced_index<SuperMeta,TagList>*&, boost_foreach_argument_dependent_lookup_hack) { return 0; } so that "foreach" is not ever mentioned? I understand that Boost.Foreach would still not work unless the macro is not defined, but this would at least save Boost.MultiIndex, which doesn't really depend on Boost.Foreach. Thanks for your comments, Joaquín M López Muñoz Telefónica

4 12

Serializing shared_ptr fails on .template
by Jared McIntyre 15 Jul '15

15 Jul '15

I've run into an issue where VS 2013, and likely earlier versions, fail to serialize a shared_ptr because Visual Studio is choking on the use of ar.template get_helper in load() to remove ambiguity. The issue appears to replicate previous bug report here: https://svn.boost.org/trac/boost/ticket/10727 That report didn't post an example, so instead of adding a new bug, I've posted example code to that existing report. VS 2013 Boost 1.57 Jared McIntyre

3 8

[variant] Maintainer
by Antony Polukhin 15 Jul '15

15 Jul '15

Hi, I've been keeping an eye on Boost.Varinat for a few years. Since then multiple issues were closed; support for rvalues and variadic templates was added; other good things happened. Could I be promoted to an official maintainer of Variant? This will help me to react on issues faster (email notifications) which is essential. I'm also planning to add missing features from N4450 without affecting the current never-empty behaviour and without breaking existing code. -- Best regards, Antony Polukhin

27 75

Re: [boost] [Boost-users] Boost 1_59_0_b1_rc1 regression in spirit::qi
by Lee Clagett 14 Jul '15

14 Jul '15

On Tue, Jul 14, 2015 at 8:10 AM, Oswin Krause < Oswin.Krause(a)ruhr-uni-bochum.de> wrote: > Hi, > > On 2015-07-14 05:54, Marshall Clow wrote: > >> Release candidate files for 1.59.0 beta 1 are available at >> http://boost.cowic.de/rc/ [1] >> >> 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. >> > > Boost compiles fine, OS Arch Linux, x86_64. > > However, i got a regression in my software using boost::spirit::qi > > See attached the program (i guess it does not qualify minimal, but i do > not have time to trace it further), output of g++/valgrind for boost 1.58 > and for 1.59. There seems to be a signed/unsigned comparison issue and > valgrind detects a conditional jump that depends on unintialized memory. In > my code this showed up as 4 values read from the parsed file have wrong > values albeit the 200 or so other values before and after are fine. > > Best, > Oswin > > I found the issue, and issued a pull request to fix it. Joel let me know if you want a test case; a variable currently unitialized (presumably intentionally) would have to be value-initialized to make it reliably catch this particular case (and then it could suppress errors if the float is `0`). Lee

1 0