- Boost - lists.preview.boost.org

[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

Boost.DLL Review is finished
by Vladimir Prus 14 Jul '15

14 Jul '15

Boosters, the formal review of the Boost.DLL library by Antony Polukhin is now finished. The preliminary results are as follows: The following people have provided reviews: - Ralf Globisch - Yes - Klaim - Joël Lamotte - Yes (*) - Niall Douglas - Yes, conditionally - John P Fletcher - Yes - Bjorn Reese - Yes - Edward Diener - Yes Klaim - Joël has asked that his vote is not counted until he's done trying the library for real, and there was no confirmation it's done yet. The following people have contributed, but did not provide a review - Rodrigo Madera - Thomas Trummer - Rob Stewart - Ion Gaztañaga If anybody would like to amend or clarify anything, or plans to provide additional comments during this week, please contact me off-list. I will post final review result after that. Thanks, Volodya

2 1

Boost.DLL formal review
by Vladimir Prus 14 Jul '15

14 Jul '15

The formal review of Boost.DLL library by Antony Polukhin starts today. 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? This formal review has a couple of adjustments in place: - It will run for two calendar weeks, not for 10 days, as a number of people said 10 days is too little. That said, please try to submit a review during first week, so that necessary discussion can happen conveniently. - The documentation site has Google Analytics enabled, which will allow us to see which pages and navigation paths are most useful for reviewers. No personally identifiable information will be collected. I will post the data after the review is over. Thanks, Volodya

4 6

[1.59] [locale] Merge PR to fix build failures
by Andrey Semashev 13 Jul '15

13 Jul '15

Hi, I've created this pull request [1] a while ago, but it's still not merged. The PR fixes compilation on MSVC and GCC (Ubuntu) and IMO is essential for 1.59. Could someone take a look and merge it? [1] https://github.com/boostorg/locale/pull/9

1 1

[threads] Problem with lambda and tls
by Fu ji 13 Jul '15

13 Jul '15

Hello, I have a problem when I use lambda in lambda and I want to obtain thread local storage. Here is simple example: auto late_connect = wakeup_signal_notify_to_connect.connect([this](){ auto* alias_to_this = this; this->OnInvokeUpdate(); //here I can obtain thread local storage from boost auto wakeup = wakeup_signal_ptr->connect([alias_to_this]() { alias_to_this->OnInvokeUpdate(); //here I cannot obtain thread local storage from boost } });}); Between first and second of invoke OnInvokeUpdate function there was no destructor call. Someone have idei why ? If I don't use alias for this in capture list there is the same effet. Best regards

2 2

[Boost-announce] [review] Metaparse Review Result
by Christophe Henry 13 Jul '15

13 Jul '15

Hi all, First of all, the final result. Metaparse is formally unconditionally accepted into Boost. We had 11 reviews, all "Yes" votes. 2 "No" reviews based on formality were later reversed to a "Yes". The review was lively, with a general agreement that the library is very useful, the design of high quality and the documentation great. Here are some noticeable quotes which helped me take my decision: - "thank you Abel for submitting such an amazing library. The quality of the documentation and code is wonderful and it has been a pleasure to review Metaparse." (Michael Caisse) - (Design) "Of high quality. Based on the MPL paradigm, but I don't view this as a problem." (Peter Dimov) - "Part of the role of boost is to push compilers to the limit (and sometimes beyond). This library certainly has the capabilities to do so." (Roland Bock) Worth noticing is the review of Gordon Woodhull. I myself wrote a new front-end for MSM using Metaparse, and other use cases were very welcome and Gordon managed to produce one for his compile-time graph library by the end of the review, which I found impressive (for both the reviewer and the library). Thank you for investing time in this review. Another important factor for me for acceptance is how well the author is going to maintain his library. We have too many abandoned libraries. Abel went out of his way to oblige remarks and demands made by reviewers. Long before the reviews he also had obliged my many critics and demands. He also showed himself open for experiments. All this while keeping a very calm and professional tone. This is for me a very good sign of a library which will be well-maintained. Finally, there were some repeated important comments which I see as adressed to the rest of Boost that the library is targeted towards library writers. >From Peter Dimov: > - Are you knowledgeable about the problem domain? "I'm not sure if anybody is. :-)" It all depends on us, library and potential library writers to become knowledgeable about this domain and make this library move from potentially useful to very useful. We need to use it to write more cool libraries. I notice a recurring theme where Boost would be dead or on the way to doom etc etc. Some very popular Boost libraries are now part of the Standard, and so what? We need to make new ones. Metaparse is one of them. Let's build more, using it! Yes Reviews(11): Andrzej Krzemienski Bjorn Reese Gordon Woodhull Lee Clagett Louis Dionne Michael Caisse Paul A. Bristow Peter Dimov Roland Bock Edward Diener Niall Douglas I want to thank all the reviewers who invested their time in this review and those who provided some usefuls comments. I also want to thank Abel for presenting this great library. Christophe Henry Metaparse Review Manager

3 2

Re: [boost] [Boost-users] Boost.DLL formal review is ending soon - submit your reviews
by Klaim - Joël Lamotte 12 Jul '15

12 Jul '15

On 12 July 2015 at 21:24, Edward Diener <eldiener(a)tropicsoft.com> wrote: > The name of the library seems Windows specific, since DLL is the term that > Windows uses for shared libraries. Would not Boost DLM ( for dynamic > loadable modules ) or Boost Loadable Library be clearer ? If I remember correctly, there was a long discussion about the naming of the library before the majority seemed ok with DLL because it's explicitely only about loading libraries, not "modules"(which is misleading) nor "plugins" (which would require a lot more features). The name, if my memory is correct, was not particularly thought to be about the Windows context. Other libraries also already took the other names like Boost.SharedObject so it was not an option.

1 0

[msm][eUML2][metaparse] Compile time
by Christophe Henry 12 Jul '15

12 Jul '15

Michael Caisse wrote: >> >> Boost.Msm v3 also implements a new compile-time strings based front-end >> called eUML2 to demonstrate the power of the library and the conciseness >> and expressiveness it allows. >> Please have a look at the documentation: >> >> https://htmlpreview.github.io/?https://raw.githubusercontent.com/boostorg/m… >> >> > >Christophe, this is wonderful work and a great example of the usefulness >of Metaparse. Can you comment on the compile time compared to eUML? Hi Michael, sorry, I had completely forgotten this post and saw it while preparing the review results (which will be done soon). Please allow me to answer this question, with my apologies. I added in the msm3 branch a CompareFrontEnds.cpp example. It is a simple fsm with 12 transitions. I tried with gcc-4.9 and clang-3.5, using -O2 on a i7-5960X processor, suse linux 13.2. Here are the results. eUML clang 4s g++ 5s eUML2 clang 9s g++ 14s Clang is clearly much faster than g++, with about 0.5s added compile-time per transition. With g++ it does not look so good. I already noticed that compile times of most production code at work with g++ is much higher than with clang. Regards, Christophe

2 1