- Boost - lists.preview.boost.org

[config] BOOST_NO_CXX11_HDR_CODECVT is not defined for VC14
by Andrey Semashev 27 Jul '15

27 Jul '15

Hi, I see that BOOST_NO_CXX11_HDR_CODECVT is not defined for MSVC-14, although it is known that the codecvt facets are unusable because of linkin errors: https://connect.microsoft.com/VisualStudio/feedback/details/1348277/link-er… You can also see STL mentioning DevDiv#1060849 here: http://blogs.msdn.com/b/vcblog/archive/2014/11/12/visual-studio-2015-previe… and I can see that the problem is not fixed in RTM. This also concerns std::codecvt specializations for char16_t and char32_t. Can we define the BOOST_NO_CXX11_HDR_CODECVT macro for MSVC?

3 6

[predef] Fails on Intel/win
by John Maddock 27 Jul '15

27 Jul '15

BOOST_COMP_INTEL is set to 0, which means that [ predef-require "BOOST_COMP_INTEL" ] fails. __INTEL_COMPILER is set to 1500. BOOST_COMP_INTEL is set to ( (((0)%100)*10000000) + (((0)%100)*100000) + ((0)%100000) ) Thanks, John.

6 17

__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

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

[Better Enums] Maps between enums and other types
by Anton Bachin 12 Jul '15

12 Jul '15

Hello, In past exchanges on this list, several people expressed a desire for bidirectional maps on enums. I've made a simple implementation [1] that relies on constexpr functions containing a switch. The switch forces case exhaustiveness checking. This method therefore requires C++14 to be truly useful. Usage is: ENUM(Channel, int, Red, Green, Blue) constexpr const char* describe(Channel channel) { switch(channel) { case Channel::Red: return "the red channel"; case Channel::Green: return "the green channel"; case Channel::Blue: return "the blue channel"; } } constexpr auto descriptions = better_enums::make_map(describe); int main() { std::cout << descriptions.from_enum(Channel::Red) << std::endl; std::cout << descriptions.to_enum("the green channel") << std::endl; } This prints the red channel Green In principle, make_map should enumerate the function by passing every possible value of Channel, and use the results to build up some lookup data structure. I am not doing that right now because I haven't found a compile-time data structure with fast enough generation to be practical. I suppose with reflective information, there are other ways to check for exhaustiveness besides using a switch. The implementation is currently inefficient (it uses a linear scan to do the reverse mapping). There is also no support for multimaps or partial maps. I could probably support the latter easily by having the function return an option type. I am not sure multimaps are a good idea at all. The only point of them would be to do a reverse mapping from multiple values to the same enum. Interested to hear any opinions. Anton [1] http://aantron.github.io/better-enums/tutorial/Maps.html

1 0

Another Problem (was RE: [type_traits] Another big update in develop)
by Fletcher, John P 11 Jul '15

11 Jul '15

A recent change on develop is breaking something in boost function: _In file included from ../../../boost/function/function_base.hpp:22:0, from ../../../boost/function/detail/prologue.hpp:17, from ../../../boost/function.hpp:24, from ../../../boost/thread/future.hpp:52, from ../../../libs/thread/src/pthread/thread.cpp:19: ../../../boost/type_traits/has_trivial_copy.hpp:47:47: error: template argument 1 is invalid This was not there yesterday. John Fletcher

3 6

Boost.Hana
by Glen Fernandes 11 Jul '15

11 Jul '15

Dear Ron, Louis, and Boost developers, The review period for Hana has concluded. 18 reviews were submitted: - 17 votes for acceptance. (1 of these was conditional upon Hana wholly supporting a second C++ implementation however). - 1 vote for rejection; for lack of compiler support. I submit that Hana be accepted into Boost. I want to congratulate Louis: the Boost community wants Hana to become an official Boost library. Thank you again, Louis, for your work on Hana and for contributing it to Boost. I propose we require, prior to Hana's inclusion in a Boost release, only that: 1. Hana's unit tests to be integrated into Boost's regression tests. If this requires maintaining both CMakeLists.txt and .b2 files, it is still worth it. I am willing to assist with this effort (and the invitation extends to anyone in the community to also contribute to the task). For release managers, potential Hana contributors, or just the general developer community in Boost, to see Hana's test cases in http://boost.org/development/tests/master/developer/summary.html will be useful. I trust, but do not mandate before Hana is officially accepted into Boost, that: 1. All GitHub issues pertaining to implementation and documentation that were opened by Louis in response to review feedback (or by others, such as Vincente, that were approved by Louis) will be addressed eventually (as long as they remain relevant). I personally would ask for, but do not require for Hana's acceptance, that: 1. That Hana's non-reference documentation live outside of the source code. The presentation of Hana's documentation is great; it looks modern, is easy to browse. I am not a fan of the prose living inside hana.hpp though (API reference documentation is the only exception). 2. Louis to investigate further the possibility of a Hana core library if such can be achieved with zero overhead (instead of focusing that effort onto a separate library that provides only a subset of Hana's functionality). On the note of Hana's current support in existing C++ implementations: - While Hana is wholly only supported by clang at present, gcc is not far behind. Given the trend of language conformance, it is reasonable to expect Hana will be entirely supported in a future gcc release. - Hana targets the C++ standard (i.e. This isn't a case of targeting any compiler-vendor specific extensions) and any highly-contentious C++ language features within (e.g. This isn't something like a pre-C++11 library that uses 'export' that only builds with an EDG compiler). - The community now has expressed sufficient interest in both kinds of libraries being part of Boost: Highly portable libraries that target implementation-specific features, and maintain compatibility with even legacy compilers; standard conforming, modern, libraries that are free of the maintenance debt of ancient compiler support. - We need more libraries taking advantage of C++14 language features to drive vendor conformance. A standard may only be as potent as the C++ implementations that support support it, but when one (such as clang does) does, others will be more driven to follow suit when real (and highly desired) projects take advantage of it. My thanks to everyone that participated in Hana's review with a review (Edouard, John Fletcher, John Bytheway, Niall, Krzysztof, Manuel, Roland, Christophe, David Stone, David Sankel, Lorenzo, John, Paul, Zach, Kohei, Charley, Vincente, Abel) as well as discussion and bug reports. Best, Glen

7 9

[BestPracticeHandbook] Run this code online
by Krzysztof Jusiak 11 Jul '15

11 Jul '15

Hi, I've recently added a new functionality to proposed boost.di library documentation. After `try it online` the natural next step was to add `run this code` functionality like in http://en.cppreference.com/w/ or http://www.rust-lang.org/ programming language. Powered by Wandbox and CodeMirror approach, let you play with the particular example and switch between normal quick book programming listing mode and the editor/compiler mode. You can check it here: http://krzysztof-jusiak.github.io/di/cpp14/boost/libs/di/doc/html/di/exampl… Just click on `Run this code` button and you will be switched to the editor mode, where you would be able to edit the code and compile it online using the newest version of the library. Implementation details: https://github.com/krzysztof-jusiak/di/blob/cpp14/doc/js/run_this_code.js It's basically the same solution as `try it online`, just implemented in js instead. Additionally, it also takes the newest version of the library from github. Minimal html: <link rel="stylesheet" href="CodeMirror/lib/codemirror.css"> <link rel="stylesheet" href="CodeMirror/theme/zenburn.css"> <script src="CodeMirror/lib/codemirror.js"></script> <script src="CodeMirror/mode/clike/clike.js"></script> <script src="CodeMirror/addon/selection/active-line.js"></script> <script src="run_this_code.js"></script> <button class="TryItBtn" id="run_it_btn" onclick="show(' https://raw.githubusercontent.com/krzysztof-jusiak/di/cpp14/examples/hello_…)">Run this code!<\/button> <textarea style="display: none" id="code"></textarea> <textarea style="display: none" id="output"></textarea> <div id="code_listing"> //quick book programming listing here or anything else, which should be hidden when editor mode is enabled </div> Let me know, what do you think. Cheers, Kris

3 2

Using clang on Windows with mingw-64
by Edward Diener 11 Jul '15

11 Jul '15

This is just a heads up about testing with clang on Windows. The latest clang, when built from the latest source, is now capable on Windows of using the mingw-64/gcc RTL. Furthermore it is no longer necessary to have the mingw/mingw-64 implementation hardcoded or linked from c:\mingw. With the latest clang the executable will look for a mingw/mingw-64 implementation on the PATH, meaning that the if the implementation's 'bin' directory is on the PATH clang will find it and use its RTL. The ability of the latest clang to use mingw-64 means that clang can use the latest gcc-5.1 RTL on Windows. The mingw-64 implementation offers more up to date and better implementations of gcc than mingw. There is one "gotcha" I have found with this setup on Windows when using clang on Windows with gcc-4.9 on up. The gcc intrin.h implementation of mingw-64 for gcc-4.9 on up has a bug where if the gcc version is less than 4.9 a compiler error will occur. I have reported this to mingw-64 on their developer's mailing list but it has been ignored. Unfortunately clang still sets itself to gcc version 4.2.1. But a workaround solves the problem and that workaround is that when using clang you define '__MINGW_FORCE_SYS_INTRINS', which causes the bug in the mingw-64 intrin.h header file to not trigger. Previous versions of clang on Windows ( 3.4, 3.5, 3.6 ) of course still have the limitation of only working with mingw and needing the mingw implementation hardcoded at c:\mingw. But at least with the latest clang built from source this has changed as explained above. The Boost build clang toolset, which on Windows is really clang-linux, should continue to work with this latest change of clang.

2 2

[1.59] Boost 1.59 schedule?
by Joaquin M López Muñoz 09 Jul '15

09 Jul '15

Hi, The official release schedule at http://www.boost.org/development/index.html seems to indicate we're now really close to the first beta of Boost 1.59, yet I don't see much activity in the mailing list and, for instance, the release notes are almost empty now: https://github.com/boostorg/website/blob/master/feed/history/boost_1_59_0.q… Is this schedule still valid? Thank you, Joaquín M López Muñoz Telefónica

6 7

Problem cross-compiling boost.context for Raspberry Pi (2)
by Biddiscombe, John A. 09 Jul '15

09 Jul '15

Hello list, I am able to compile the full set of boost libraries on the Raspberry Pi, and I get all the libraries successfully built, including context and coroutine which I need. However, when I cross compile on an Ubuntu virtual machine setup for the job, all the libraries except context/coroutine are built. The problem seems to be that when cross compiling, the file "unsupported.cpp" is being pulled in (here is a verbose output showing flag I'm using) "/home/biddisco/pi/tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian-x64/bin/arm-linux-gnueabihf-g++" -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall -pthread -fPIC -D__arm__ -std=c++11 -mcpu=cortex-a7 -mfpu=neon-vfpv4 -mfloat-abi=hard -DBOOST_ALL_NO_LIB=1 -DBOOST_CHRONO_DYN_LINK=1 -DBOOST_CONTEXT_DYN_LINK=1 -DBOOST_CONTEXT_SOURCE -DBOOST_SYSTEM_DYN_LINK=1 -DBOOST_SYSTEM_NO_DEPRECATED -DBOOST_THREAD_BUILD_DLL=1 -DBOOST_THREAD_POSIX -DBOOST_THREAD_USE_DLL=1 -DNDEBUG -I"." -c -o "bin.v2/libs/context/build/gcc-arm/release/threading-multi/unsupported.o" "libs/context/src/unsupported.cpp" which emanates from the jamfile boost_1_58_0/libs/context/build/Jamfile.v2 where the following alias asm_context_sources : unsupported.cpp ; is in a section marked #COMBINED Now, when I build on the pi itself, this file is not being added to the build, so it seems to me that during the bootstrap phase on the pi, different flags are being used which trigger the correct behaviour of bjam my user-config.jam looks like this using gcc : : /home/biddisco/pi/tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian-x64/bin/arm-linux-gnueabihf-g++ : <compile-flags>-D__arm__ -mcpu=cortex-a7 -mfpu=neon-vfpv4 -mfloat-abi=hard ; (NB. I added -D__arm__ to see if it helps, but it does not make a difference without it). I have no knowledge of how bjam / boost.build do their things, so I do not know what to try next. It seems that I need to bootstrap the build using the flags for the pi, but built for the host so that it can generate the correct makefiles and this looks like where the problem is arising. the build process seems good apart from this wrinkle The bootstrap command I'm using is ./bootstrap.sh --with-toolset=gcc and the build appears sensible when I use ./b2 cxxflags="-D__arm__ -std=c++11 -mcpu=cortex-a7 -mfpu=neon-vfpv4 -mfloat-abi=hard" --layout=versioned threading=multi link=shared variant=release -j8 Performing configuration checks - 32-bit : yes - arm : yes .... etc etc Can anyone see what I'm doing wrong? (Note : With another project which depends on libpthread, I had to copy libpthread from the pi to the host and force the linker to use the pthread lib from the pi and not the host one, does bjam do something internally which might require a trick like this? - note2 - the binaries generated via this process run without error) Many thanks JB -- John Biddiscombe, email:biddisco @.at.@ cscs.ch http://www.cscs.ch/ CSCS, Swiss National Supercomputing Centre | Tel: +41 (91) 610.82.07 Via Trevano 131, 6900 Lugano, Switzerland | Fax: +41 (91) 610.82.82

4 17

Json read...segment by segment
by vijay.singh＠edisphere.com 07 Jul '15

07 Jul '15

Hi, I am using below code to read load Json file in boost::property_tree::ptree object. Function read_json(.) read all file content at a time. I want to know is there any way to read file content segment by segment. Thanks and regards, Vijay int _tmai3n(int argc, _TCHAR* argv[]) { try { std::stringstream ss; std::ifstream file("D:\\EdisphereComp\\kit\\1003_Kit\\1003\\Inputfiles\\AI98_Test_3.json", std::ios::binary); // Make sure we have something to read. if (!file.is_open()) { throw (std::exception("Could not open file.")); } // Copy contents "as efficiently as possible". ss << file.rdbuf(); boost::property_tree::ptree pt; boost::property_tree::read_json(ss, pt); boost::property_tree::write_json("D:\\EdisphereComp\\kit\\1003_Kit\\1003\\In putfiles\\AI98_Test_3_sprite.json", pt); } catch (boost::property_tree::json_parser_error e) { ; } //} return 0; }

4 7

Boost.Test v3 is in master
by Gennadiy Rozental 07 Jul '15

07 Jul '15

Hi, I've merged new Boost.Test into the master branch. We'll look for any regressions, but I do not expect big changes before release. Gennadiy

2 1

[test] Bug in Mingw support?
by John Maddock 07 Jul '15

07 Jul '15

The short program below passes with MSVC and GCC Linux, but fails with Mingw-x64 at runtime (the expected failures count gets ignored). This is with current develop. Any ideas? BTW the new decorator based approach does work OK, but is only supported on a tiny number of compilers as it seems to rely on the preprocessor lib using variadic macros, as opposed to Boost.Config marking them as available. Here's the program: #define BOOST_TEST_MAIN #include <boost/test/unit_test.hpp> BOOST_AUTO_TEST_CASE_EXPECTED_FAILURES(test_main, 10000); BOOST_AUTO_TEST_CASE(test_main) { BOOST_ERROR("one"); BOOST_ERROR("two"); } Thanks, John.

3 7

Boost Graph maintenance
by Oodini 07 Jul '15

07 Jul '15

Hello, I've been working on BGL for several days, and I'll probably have to work on it for a long time. The documentation is not very clear (I suspect it is outdated on some points), and as it doesn't seem complete. Also, the official maintener, Jeremiah Willcock, hasn't commited since the end of 2013. I'd like to work on the documentation, in the first time on the organization and presentation. If I amend the text later, I will need a reviewer (my english is not good enough). What would be the process ? I havn't participated to any Boost library.

5 5

Boost.Experimental Re: [variant] Maintainer
by Gottlob Frege 07 Jul '15

07 Jul '15

On Sun, Jun 28, 2015 at 10:29 AM, Agustín K-ballo Bergé <kaballo86(a)hotmail.com> wrote: > On 6/28/2015 5:38 AM, Vicente J. Botet Escriba wrote: >> >> Le 27/06/15 21:32, Agustín K-ballo Bergé a écrit : >>> >>> On 6/27/2015 12:38 PM, Vicente J. Botet Escriba wrote: >>>> >>>> I would accept Eggs.Variant without even a review (or with a minimal >>>> review) as an experimental library as part of Boost.Variant after some >>>> minimal adaptation to fit in Boost of course. >>> >>> First of, as I have already said before, Eggs.Variant is an >>> experiment. As such it is highly unstable, and I reserve the right to >>> change things in any way I see fit, with no regards for backwards >>> compatibility, maintenance, or support. I have made these kinds of >>> changes in the past, and I have more planned for the near future. I >>> think it would be unwise to make it a part of Boost, even as an >>> experimental library, until the design has fully hatched ("Eggs", get >>> it?). >> >> Agustin, this is exactly the kind of constraints of an experimental >> library. When the design is fully hatched then it moves to non >> experimental. > > > I fail to see the point in including an experimental library that changes > its interface every month into Boost, which is released every 3 months or > so. By the time you get your hands in a release, the interface of the > library has already changed. And the library as such would only exist for a > single release. > > Who would benefit from Boost packaging old snapshots of experimental > libraries? > > Perhaps you'd wish to bring back the Sandbox > (http://www.boost.org/community/sandbox.html) which has been superseded by > standalone repositories since the move to Git. > I think we need *something* for experimental libraries. Even if it is just someone's own git repository stamped (but not endorsed) with the Boost "brand". Or a page in boost.org listing current experiments. Or... something. There are (at least) 2 needs that Boost tackles: 1. great libraries that solve problems for developers 2. great libraries that can turn into std:: libraries I think we are doing better on 1 than 2. I think 2 requires more experimentation (whereas 1 requires more stability). Yes I know 2 looks successful - just look at how much of boost is in C++11. But when each Boost library is brought to the committee, we have 2 choices: - make design changes before going into std - take as is Making design choices in a committee (and without experimenting) is not always a good idea. We are, in theory at least, suppose to standardize existing behaviour. Taking as is means we are accepting whatever was good enough to pass Boost review as *best*. Boost review is a high bar, but the std:: should be higher. It is common for the committee to hear/say "boost users have been using it this way for years". That is usually a good strong argument - we want/need implementation and usage experience. But saying "this works" doesn't mean something else could work better. Implementation/usage experience is most accurate when it says "this does NOT work", because then you have ruled out an option. When you say "this works", it doesn't rule out options that might work _better_. We are increasingly going with option 3: - put into std::experimental which delays the desired outcome of getting great libraries into the standard. I'd like some kind of experimental area that would help find the best possible libraries. What I'd _really_ like is more experimentation in _current_ Boost libraries, breaking users left and right - I'd rather break boost users than std:: users. (We have and will make breaking changes in the standard library). But I understand that current users wouldn't be too happy about breaking changes _just for experimentation's sake_. And if we lost the boost user base, boost would no longer be helpful to the standard at all. (As a reasonable example of not being afraid of breaking changes: Sean Parent's Adobe Standard Library would boldly break whenever he thought something could be made better. It didn't break just for experimenting, but he wasn't afraid to make breaking changes for the better.)

6 11

[predef] Using predef-check on 'develop' problem
by Edward Diener 06 Jul '15

06 Jul '15

In a jam file I have for a run test a predef-check which looks like: run test_variadic_macro.cpp : : : [ predef-check "BOOST_COMP_GNUC >= 4.3" "BOOST_OS_QNX == 0" : : <cxxflags>-std=c++0x ] ; When running on QNX with the gcc version greater than 4.3 I would expect that -std=c++0x would not be added as a C++ compile parameter to the run. Yet it is being added to the run. Another test confirms that BOOST_OS_QNX is indeed being set to a non-zero value. Is there a bug in predef-check ? Am I using it incorrectly ?

4 45

Testing InputIterator on the interface
by Benedek Thaler 05 Jul '15

05 Jul '15

Hi, I'd like to verify my methods accepting an input range (two iterators modelling InputIterator) do a single pass over the range at most. I'd like to have an iterator adaptor, which erases the visited element upon incrementing. So far, I found these: 1) https://github.com/boostorg/test/blob/master/include/boost/test/utils/itera… I couldn't find its documentation, and does not seem to what I want. 2) https://github.com/boostorg/container/blob/master/test/input_from_forward_i… Despite the name, still not something I want. I'm developing a Boost.Container class [0], so using container/test would be okay. Is there such a thing ready somewhere or shall I roll my own? Thanks, Benedek [0]: https://github.com/erenon/container/blob/devector/include/boost/container/d…

2 3

Re: [boost] [Boost-users] Boost.DLL formal review is ongoing
by Klaim - Joël Lamotte 04 Jul '15

04 Jul '15

On 4 July 2015 at 11:38, Antony Polukhin <antoshkka(a)gmail.com> wrote: > 2015-07-04 0:16 GMT+03:00 Klaim - Joël Lamotte <mjklaim(a)gmail.com>: >> >> >> On 3 July 2015 at 15:50, Vladimir Prus <vladimir.prus(a)gmail.com> wrote: >>> >>> - What's your evaluation of >>> - Design >>> >> >> I consider the solutions provided to solve each usual issue with plugin >> systems to be simple >> and clear, easy to use (as long as you understand what loading plugins >> imply). >> >> Until I check in some complex cases, I think the design is very good. >> The symbol name magic might be tricky to understand sometime but it's an >> issue which is a side effect of providing >> a simple tool to manage symbole names, so it's still good. >> >> One thing I was wondering: would it be possible to provide a way to load >> shared libraries from >> raw memory? Or does the OS APIs all requires that the library have to be >> on a file sytem? >> > > Unfortunately, there's no portable way to load libraries from raw memory. > However you can always mount a filesystem that directly maps to memory (for > example Tmpfs on Linux) and store your data in there. This may look like a > big performance overhead, but actually loading a shared library takes much > time so you won't probably notice the overhead of additional create_file + > memcpy. > It's ok, the solution to write a shared library in the the filesystem before loading it is what Ihave been doing so far and it works well. I was just wondering if it was possible with memory. :) If the plugin is in an archive file, I have to extract it in a temporary directory before loading it, which is what I would like to avoid, but it seems unavoidable. > > If you're planing this feature to write interpreters\JIT compillers and > you just need a place to store end execute generated native code, then > Boost.Interprocess's memory mapped files fill probably suit you better. > Shared libraries contain a lot of headers, helper data for load and a bunch > of other stuff that would be really hard to generate. > I don't write an interpreter (I'm really just managing plugins) but I didn't know that, it seems useful in some other contexts. Thanks for the pointer.

1 0

Fwd: [Boost-users] Boost.DLL formal review is ongoing
by Antony Polukhin 04 Jul '15

04 Jul '15

2015-07-04 0:16 GMT+03:00 Klaim - Joël Lamotte <mjklaim(a)gmail.com>: > > > On 3 July 2015 at 15:50, Vladimir Prus <vladimir.prus(a)gmail.com> wrote: >> >> - What's your evaluation of >> - Design >> > > I consider the solutions provided to solve each usual issue with plugin > systems to be simple > and clear, easy to use (as long as you understand what loading plugins > imply). > > Until I check in some complex cases, I think the design is very good. > The symbol name magic might be tricky to understand sometime but it's an > issue which is a side effect of providing > a simple tool to manage symbole names, so it's still good. > > One thing I was wondering: would it be possible to provide a way to load > shared libraries from > raw memory? Or does the OS APIs all requires that the library have to be > on a file sytem? > Unfortunately, there's no portable way to load libraries from raw memory. However you can always mount a filesystem that directly maps to memory (for example Tmpfs on Linux) and store your data in there. This may look like a big performance overhead, but actually loading a shared library takes much time so you won't probably notice the overhead of additional create_file + memcpy. If you're planing this feature to write interpreters\JIT compillers and you just need a place to store end execute generated native code, then Boost.Interprocess's memory mapped files fill probably suit you better. Shared libraries contain a lot of headers, helper data for load and a bunch of other stuff that would be really hard to generate. -- Best regards, Antony Polukhin

1 0

[next gen futures] Lightweight monad ready for inspection
by Niall Douglas 03 Jul '15

03 Jul '15

Some may remember the thread starting from http://boost.2283326.n4.nabble.com/next-gen-future-promise-What-to-cal l-the-monadic-return-type-td4676039.html and that I would firstly prepare an optimally lightweight monad<T> for review here before going on to base a next-gen lightweight future-promise on that monad<T>. I didn't expect it would take nearly four weeks to get there, but writing STL quality C++ with full conformance test suite is amazingly labourious. Anyway you can now view the design and tell me what you think. A quick overview of the design: This monad can hold a fixed variant list of empty, a type R, a lightweight error_type or a heavier exception_type at a space cost of max(20, sizeof(R)+4). Features: * Very lightweight on build times and run times up to the point of zero execution cost and just a four byte space overhead. Requires min clang 3.2, GCC 4.7 or VS2015. A quick sample of runtime overhead, min to max opcodes generated by GCC 5.1: 1 opcodes <= Value transport <= 113 opcodes 8 opcodes <= Error transport <= 119 opcodes 22 opcodes <= Exception transport <= 214 opcodes 4 opcodes <= then() <= 154 opcodes 5 opcodes <= bind() <= 44 opcodes * Just enough monad, nothing more, nothing fancy. Replicates the future API with a fair chunk of the Expected<T> API, so if you know how to use a future you already know how to use this. * Enables convenient all-noexcept mathematically verifiable close semantic design, so why bother with Rust anymore? :) * Can replace most uses of optional<T>. * Deep integration with lightweight future-promise (i.e. async monadic programming) also in this library. * Comprehensive unit testing and validation suite. * Mirrors noexcept of type R. * Type R can have no default constructor, move nor copy. * Works inside a STL container, and type R can be a STL container. * No comparison operations nor hashing is provided, deliberately to keep things simple. Documentation page: https://ci.nedprod.com/view/Boost%20Thread-Expected-Permit/job/Boost.S pinlock%20Test%20Linux%20GCC%204.8/doxygen/classboost_1_1spinlock_1_1l ightweight__futures_1_1monad.html Source code: https://github.com/ned14/boost.spinlock/blob/master/include/boost/spin lock/monad.hpp Online wandbox compiler: http://melpon.org/wandbox/permlink/cnZM5KRNpjErXrPH Any opinions or thoughts gratefully received, particularly if I have the exception safety semantics right (i.e. a throw during move or copy leaves the monad empty). Do you also like the polymorphic bind() and map() which does different things depending on the parameter type your callable takes? Do you like that by simply changing the callable's type to a rvalue reference you can move state, or is this being too clever? This monad will become the basis of lightweight future-promise which is essentially a "split monad" with the setter interface and getter interface potentially in different system threads. The then(), bind() and map() work as here but only are triggered at the point of the value being changed. This effectively makes the lightweight future a "lazy continued monad". That lightweight future-promise will then enter AFIO to replace its async_io_op type hopefully in time for the peer review this time next month. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

10 42

Re: [boost] Boost.DLL formal review is ongoing
by Ralf Globisch 03 Jul '15

03 Jul '15

Hi, Firstly, thanks Anthony for submitting this useful library to boost, and to Vladimir for managing the review. - Should the library be accepted? Yes. I had been meaning to test the library for some time, and with the review reminder finally made some time to do so. My vote of yes is based on my (limited) positive experience with the library, as well as having followed past related discussions on the mailing list, in which many questions are addressed. (http://lists.boost.org/Archives/boost/2014/09/216650.php) I think boost.DLL should be accepted unless someone has a serious/valid reservation as to why this library should not to be accepted. - How useful is it? Very useful. It enabled me to add a test-plugin mechanism to an existing application (Windows and Linux) in a matter of minutes. - What's your evaluation of - Design Looks good to me. Simple to use, with good integration into rest of boost (e.g. file_system). I like the fact that the library is header only and minimal effort was required to integrate plug-in like functionality into an existing application. - Implementation I'm not knowledgeable enough to comment on this. - Documentations Good, the tutorials made it fairly easy to get going and covered my common usage scenarios Code is well commented. - How much effort did you put into your evaluation? About three hours worth of effort, reading through documentation and source code, and using library to create a very simple plug-in mechanism in an existing application. Tested basic plug-in functionality on Windows and Linux. - Did you attempt to use the library? On what systems and compilers? Yes -Linux Ubuntu 14.10 with gcc 4.9.1 with boost 1.57 -Window 7 64-bit with VS 2013 community edition with boost 1.58. Initially made the mistake of not checking the boost version (which had been 1.53 and caused lots of compilation errors.) Minor typo in documentation: Just above the "Full Sources" for tutorial 4 "If we want o make a traditional" should be "If we want to make a traditional" Regards, Ralf >>> Vladimir Prus <vladimir.prus(a)gmail.com> 07/03/15 3:52 PM >>> 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 _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. Please consider the environment before printing this email. -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. Please consider the environment before printing this email.

1 0

Metaprogramming: parameter pack expansion/evaluation trick
by Antony Polukhin 03 Jul '15

03 Jul '15

Hi, Straight to the problem. Consider the situation, were a function accepts parameter pack and something need to be done with each argument (for example, we want to print each argument on a new line): template <typename... Args> void print(Args&&... a) { // print each a on a separate line } There's a known trick to do that: template <typename... Args> void print(Args&&... a) { (void) (int []){ 0, (std::cout << a << std::endl, 0)... }; } But the syntax is not very readable (and I always forget it and search for an example in Internet). I've tried to improve the syntax, and here's the result: template<typename... Args> void print(Args&&... a) { expand_if<Args...> { std::cout << a << '\n'... }; } Compete source could be found here: http://coliru.stacked-crooked.com/view?id=c2c59f22574671e5 Here's some more usage examples: template<typename... Args> void printer_int(Args&&... args) { expand { std::cout << std::abs(args) << std::endl..., std::cout << "Printing once again all the numbers: " << std::endl, std::cout << " Once again " << std::abs(args) << std::endl..., std::cout << "EOF Printing once again all the numbers." << std::endl }; } template<typename... Args> float sum(Args&&... args) { float res = 0; expand_if<Args...> { res += args... }; return res; } I hope this would be helpful for someone or it could be used as an argument for a proposal to extend C++ and allow simpler syntax: template<typename... Args> void print(Args&&... a) { std::cout << a << '\n'...; } P.S.: There was a nicer solution that newer required "_if<Args..>" : namespace detail { struct expand_impl final { template <class... Arg> constexpr inline expand_impl(Arg&&...) noexcept {} }; } template <class... Arg> using expand = detail::expand_impl; But unfortunately there's no way to force the compiler to evaluate expressions in constructor call from left to right. So it did not work on GCC (but work on Clang). -- Best regards, Antony Polukhin

4 4

[math][website] SVG graphics all missing?
by John Maddock 03 Jul '15

03 Jul '15

It looks like all the SVG graphics used by the Boost.Math docs are missing from the website - is this a release SNAFU? Thanks, John.

1 1

[winapi] Major changes in develop
by Andrey Semashev 02 Jul '15

02 Jul '15

Hi, I've just merged a largely reworked version of Boost.WinAPI to develop. It fixes a few bugs and also changes the implementation for better conformance with the C++ standard. Hopefully, it should fix compilation issues with clang on Windows. Another significant change is that Boost.WinAPI targets Windows Vista and later by default. As before, it is possible to explicitly select another version to target by defining BOOST_USE_WINAPI_VERSION. For example, to build Boost for Windows XP one would invoke: b2 define=BOOST_USE_WINAPI_VERSION=0x0501 If anyone has problems with this change, please let me know.

2 5

[optional] How to use optional to lazy construct obj?
by Mostafa 01 Jul '15

01 Jul '15

I'm interested in doing something along the lines of: lazy_adaptor<obj_type> lz(arg1, arg2, arg3, ...) where then lz.construct() then constructs an object of obj_type with ctor of arguments "arg1, arg2, arg3, ...". So far I have the following: (Am I on the right track?) #include <utility> #include <tuple> #include <string> #include <boost/optional/optional.hpp> template <typename... Args> struct ctor_forwarder; template <typename... Args> ctor_forwarder<Args...> make_ctor_forwarder(Args&&... args) { // Note: The "Args..." template parameter to ctor_forwarder determines how // the caller's arguments are temporarily stored. If it's an rvalue, it's // temporarily stored by value, else it's temporary stored by reference. return ctor_forwarder<Args...>(std::forward<Args>(args)...); } template <typename... Args> struct ctor_forwarder { //TODO: make ctor private. template <typename... A> explicit ctor_forwarder(A&&... args) : m_args( ::std::forward<A>(args)... ) {} /* template <typename Callable> auto forward_to(Callable && caller) -> decltype( caller(::std::forward<Args>(m_args)...) ) { return caller(::std::forward<Args>(m_args)...); } */ template <typename T> void forward_to(::boost::optional<T> & obj) { obj.emplace(::std::forward<Args>(m_args)...); } private: typedef ::std::tuple<Args...> args_t; private: args_t m_args; }; template <typename Obj, typename... Args> struct lazy_adaptor { Obj on_enter() { m_args_forwarder.forward_to(m_obj); } private: ::boost::optional<Obj> m_obj; ctor_forwarder<Args...> m_args_forwarder; }; template <typename Obj, typename... Args> lazy_adaptor<Obj, Args...> make_lazy_adaptor(Args&&... args) { return lazy_adaptor<Obj, Args...>(); } struct Sample1 { Sample1(int num, std::string str) {} }; int main() { auto df = make_ctor_forwarder(10, "Ten"); //ctor_forwarder<int, std::string> df(10, "Ten"); auto lazy_ctor = make_lazy_adaptor<Sample1>(10, "Ten"); return 0; }

1 0

Fwd: [SORT] Parallel Algorithms
by Francisco José Tapia 01 Jul '15

01 Jul '15

Hi Steven I had been revising and testing spreadsort, and the results are impressive. I have prepared the benchmarks and include spreadsort. Now the numbers are extracted from a file generated with a random number generator. In a few days I will put all in a git repository for a easy access As I had seen, you use boost::sort for to invoke to spreadsort. If you use this name, which name use for to invoke introsort? I think a good idea can be call the algorithms by their name. If we do this we have the next algorithm list : - spreadsort - spreadsort_integer - spreadsort_float - spreadsort_string - introsort - parallel_introsort - smart_merge_sort - parallel_stable_sort - sample_sort I think it's a simple and easy to understand, because with the name sort, many people think about an algorithm as introsort ( general , not specific for several data types) and not stable. What's your opinion ?

3 19

[Boost] [Hana] Formal review for Hana (Submissions closed)
by Glen Fernandes 30 Jun '15

30 Jun '15

Dear Boost community, The period for Hana review submissions has ended. The result will be announced on the list during this week. I would like to thank everyone on this list for your submission of a review: - Edouard Alligand - John P. Fletcher - Niall Douglas - Krzysztof Jusiak - Roland Bock - Vicente J. Botet Escriba - David Sankel - Zach Laine - Kohei Takahashi - Charley Bay - Bruno Dutra - Christophe Henry - David Stone - Lorenzo Caminiti - John Bytheway - Manuel Sánchez As well as the following people for your discussion during the review period: - Phil Endecott - Larry Evans - Abel SInkovics - Gavin Lambert - Jeremy Maitin-Shepard - Joel de Guzman - Edward Diener - Paul A. Bristow - Peter Dimov - Bjorn Reese - Paul Fultz II - Lee Clagett Once again, thank you to Louis for all your work on Hana and submitting it for Boost inclusion. Glen

2 1

[Circular Buffer]Could erase_begin run in constant time for trivially destructible objects?
by Pradhan Kumar 30 Jun '15

30 Jun '15

Hello everyone, The implementation of circular_buffer<T>::erase_begin(n) is tag-dispatched on is_scalar<T>, to use a constant time implementation for scalar types. For non-scalar types, it falls back to using rerase(begin(), begin()+n). Could we change this to dispatch on std::is_trivially_destructible? Examining the generated code, I see that the below loop has not been completed optimized out for a POD-type. (I am using Boost 1.58 and gcc4.9.2. The compile option was g++ -O3 -std=c++11 -g -DBOOST_CB_DISABLE_DEBUG -fno-inline to make it easier for me to understand the assembly.) do { destroy_item(m_first); increment(m_first); --m_size; } while(m_first != p); destroy_item is optimized out, as expected. However, increment has a "modulo" check and this prevents the above while loop from getting optimized to one instruction. template <class Pointer> void increment(Pointer& p) const { if (++p == m_end) p = m_buff; } Thoughts? Thanks, Pradhan

1 0

Change to guidelines for characters in C++ source files
by Beman Dawes 29 Jun '15

29 Jun '15

Since the very early days of Boost the guidelines for acceptable characters in C++ source files has been the 96 characters of C++ standard's basic source character set encoded in 7-bit ASCII. The inspect program also allowed several additional 7-bit ASCII characters that sometimes appear in comments. The rationale was to ensure that Boost code was portable to all compilers available at that time. We had gotten complaints that even a character as innocuous as a copyright sign (U+00A9) was causing compiles to fail on some compiler releases targeting Asian languages. UTF-8 support was far from universal. Times have changed: * Source files encoded in UTF-8 with a leading byte order mark (BOM) of the byte sequence 0xEF,0xBB,0xBF are supported by all C++ compilers that we are aware of, and this has been true for many years now. * As of C++11, the C++ language now includes types and literals directly supporting UTF-8, UTF-16, and UTF-32, and creating code points above 7-bit ASCII in such literals is much easier if UTF-8 source encoding is used. Even editors as dumb as Windows Notepad have supported UTF-8 with BOM for some time now. * As Boost Libraries start to incorporate C++11 Unicode related features, it becomes difficult to write test programs if limited to 7-bit ASCII. For example, incorporating the Filesystem TS into Boost.Filesystem requires test cases with UTF-8, UTF-16, and UTF-32 and that's painful under the current 7-bit ASCII guidelines. So... It looks to me like it is high time to change the Boost guideline for C++ source file encoding to 7-bit ASCII without BOM or UTF-8 with BOM, and to change the inspect program accordingly. Comments? --Beman

9 12

[thread] Change broken on Windows
by Edward Diener 29 Jun '15

29 Jun '15

The 8c974800f90dc5f644895f2d7247364710edcf76 change to thread made on June 23 broke its functionality on Windows. The changes to lines 642 and 659 of thread\include\boost\thread\win32\thread_primitives.hpp is obviously wrong. While I can fix locally easily enough this needs to be fixed on 'develop' ASAP.

3 2

merging from develop to master
by Stefan Seefeld 29 Jun '15

29 Jun '15

Hello, I'm trying to compare Boost.Python's develop branch with master, to decide how to proceed. I was naively assuming that develop would regularly be rebased so it's easy to merge patches. However, https://github.com/boostorg/python/branches/active indicates develop is "276 commits ahead". How is that possible ? How did previous maintainers keep the develop branch in sync with master ? How is this handled in other Boost libraries ? Thanks, Stefan -- ...ich hab' noch einen Koffer in Berlin...

6 6

[Hana] Formal review
by Manu343726 28 Jun '15

28 Jun '15

Here's my formal review of Hana - Whether you believe the library should be accepted into Boost Yes - Your name Manuel Sánchez - Your knowledge of the problem domain. I have been doing TMP side projects as a hobby, including my own tmp library in the same sense of Hana but metafunction based (Like Boost.MPL). - What is your evaluation of the library's: * Design Hana design and wording makes it look more like a Hakell library than a C++ one (All the functional concepts, algorithms etc). I think it's fine since Hana algorithms are about declarative data transformation. C++ needs that change in the way of thinking, but I expect some others (more conservative C++ programmers) to not accept Hana for not being too much "C++ish". About metaprogramming, wrapping types into template variables is a game changer. Some others noticed that doing type and value manipulation with the same code may be confusing since with templates there is a clear line between type manipulation code (templates) and value manipulation code (normal C++). I'm partially agree, but I prefer not to write/maintain two different libraries for exactly the same algorithms. That's the core value of Hana. * Implementation Tmp is usually ugly, but Louis does a great work at making code as clear as possible. Code is well divided and documented. * Documentation The library is documented in depth. I have mainly two issues: More references about basic concepts and navigation. Both are already covered by issues at github, so I will not dive into them here. * Tests Not looked. * Usefulness There are only a few libraries out there that provide this kind of STL-quality set of algorithms. Having those work with types and values worths it. As others said, there's a problem on current compiler support (Only recent versions of Clang). I like the idea of pushing towards compiler vendors, but it's true that since the beginning Boost libraries were designed to work on any C++ platform available. In my opinion, we should give Louis an opportunity, while giving vendors time to update their implementations. - Did you attempt to use the library? If so: * Which compiler(s) clang 3.6.1 * What was the experience? Any problems? I tried some experiments regarding type manipulation. No special issues raised out. It worked as expected. - How much effort did you put into your evaluation of the review? A few hours playing with the lib, plus a couple of hours to write the review. -- View this message in context: http://boost.2283326.n4.nabble.com/Hana-Formal-review-tp4677606.html Sent from the Boost - Dev mailing list archive at Nabble.com.

2 1

[hana] Review
by John Bytheway 28 Jun '15

28 Jun '15

This is a somewhat perfunctory review of Hana, because I wanted to get something in before the end of the review period. I have submitted a few issues on GitHub, for minor things that need not be repeated here. Below are the things I found that might warrant more discussion. - Whether you believe the library should be accepted into Boost * Conditions for acceptance Yes it should. No specific conditions. - Your name John Bytheway - Your knowledge of the problem domain. User of TMP for years. Once wrote a source-to-source translator to help me write MPL programs because it was prohibitively difficult to write them correctly by hand. - What is your evaluation of the library's: * Design The design seems reasonable, and I like the adherence to mathematical concepts. The most difficult thing is getting the names right, and I know there's been plenty of debate on that. The name that most concerns me is Range, given that that term is already commonly used in Boost as a concept with a completely different meaning (in the Boost.Range sense). * Implementation Did not look. * Documentation Mostly very good, but of course there is always room for improvement. One particular thing I wanted to raise here is that I struggled to find enough information about Hana-convertibility (i.e. using the 'to' function). For example, I wondered if I could create a Tuple from a Range, and it seems I can. Then I wondered whether I could create a std::Array from a homogeneous Tuple, but it seems I cannot. How should I know these things? (This latter case of converting to an array is something I feel ought to be supported for easing the boundary between runtime and compile-time sequences) * Tests Did not look. * Usefulness Very, although not useful for me personally until I decide to bite the ABI-breaking bullet and recompile all my code in gcc 5.x with the new libstdc++. The biggest risk I see is MSVC support. Microsoft seem to be much more standards-gung-ho than they once were, so I hope it won't take too much longer before we see support. But I do encourage Louis to be wary of taking advantage of any new language features (e.g. a potential change in C++17 lambdas-in-unevaluated-contexts rules, or the compiler extension for compile-time string literals) lest it delay MSVC support. - Did you attempt to use the library? If so: * Which compiler(s) clang 3.6.1 * What was the experience? Any problems? I played around a bit, mostly with a view to finding out how bad the compiler errors are when things go wrong. The results were promising. I went looking for some code of mine to try porting to Hana, and got sidetracked by one difficulty. The first project I came across using Boost.Fusion was passing a lot of fusion::vectors across function interfaces, but the vector types were specific and the functions not defined in headers. Hana's tuple cannot easily be used in this way since the type is unspecified. I don't think this is a problem, because (a) that code was just poorly written and ought instead to be using adapted structs, which Hana does support, and (b) I can use Hana algorithms with Fusion's tuples anyway. - How much effort did you put into your evaluation of the review? A few hours reading and playing. Thanks very much to Louis for his effort. I look forward to being able to use Hana in the not-too-distant future, and I'll make GitHub issues for any more things I discover in my testing. John

3 6

Hana Views and References
by Joel de Guzman 27 Jun '15

27 Jun '15

Hello Louis, Mario Lang, a Spirit developer, played around with Hana and investigated on it's suitability for Spirit. His conclusion is that "Hana is really quite nice!". Then, he adds that: "However, Hana lacks a way to retrieve the members of a struct as references currently, which will pretty much kill a Hana based Spirit effort." So the question is: will Hana support references without resorting to using reference wrappers? I do appreciate the FP nature of Hana, but please be reminded that we're in C++. I also recall some discussion that Hana also does not support Fusion-like lightweight views. Is there a plan to support them? I haven't fully investigated yet what else Hana does not support that Fusion does, but at least these two important aspects of fusion come to mind. At the very least, I don't think Hana should advertize itself as a superset of Boost.Fusion. Faster runtime performance is also questionable, when lightweight views and reference members come into play. Regards, -- Joel de Guzman http://www.ciere.com http://boost-spirit.com http://www.cycfi.com/

5 9

Re: [boost] [hana] Lorenzo's Formal review for Hana
by Brian Wood 27 Jun '15

27 Jun '15

Louis Dionne writes: > I'm coding against a standard, not a specific compiler. If I introduce > workarounds in Hana, the whole purpose of the library is lost. Performance, > ease of use, and most importantly hackability will be lost. > Hmm. > Quite honestly, I'd rather have my library never get into Boost than > bastardize it so it works on MSVC. If it can be made to work on MSVC > without bastardizing it, however, I'm all for it. I face similar issues and agree with your remarks here. It seems like it's easier to use MSVC and Windows than it used to be, but it's still not easy. I've recently reduced my Windows support and feel a burden lifted. -- Brian Ebenezer Enterprises - "Free at last; free at last. Thank G-d Almighty we are free at last." Martin Luther King Jr. http://webEbenezer.net

3 3

[Boost] [Hana] David Stone's formal review
by David Stone 27 Jun '15

27 Jun '15

- Whether you believe the library should be accepted into Boost Yes - Your name > David Stone > - Your knowledge of the problem domain. > Advanced > - What is your evaluation of the library's: > * Design Good. It seems like most of the library follows the naming conventions of boost and the standard library (identifiers_like_this), but there are a few exceptions. The most notable is boost::hana::IntegralConstant. Why not integral_constant? Aside from minor issues like this, I am a huge fan of the overall idea of making compile-time and run-time code the same. Ideally we would have just a single language in C++ (as opposed to plain C++, template C++, constexpr C++, macro C++, and concept C++) and a single style of programming. The design of this library follows and extends this general trend in C++ that started with constexpr. > * Implementation > Looking through the source, it seems to flow naturally. Most of the code looks essentially the same as I would have written it. It has small, self-contained functions and appropriate use of macros, comments, and static_asserts. It would be nice if your IntegralConstant provided a specialization of std::numeric_limits. This would allow it to work properly with a few libraries (two examples are my bounded::integer library and this fixed point library: https://github.com/mizvekov/fp) You could then detect type-level compile-time constants as being any integer type for which std::numeric_limits<T>::min() == std::numeric_limits<T>::max(), which would allow the interoperability to flow the other way, but I do not know if the library ever requires this information or if it just relies on the compiler to complain about things that are not constexpr. > * Documentation > Very good from some perspectives. I started using the library by trying out checking expression validity, and it followed a logical progression, covering all types of members. This naturally led to me wondering if it is possible to use the library to test for the existence of a member named `blah`, but without knowing what category of member it is (variable, function, type, or template). I am assuming that this is as simple as saying `is_valid(variable) or is_valid(function) or ...` However, I feel that the documentation is trying to serve two incompatible purposes. On the one hand, it is trying to explain the theory of type computation using terms from functional programming. On the other hand, it also trying to be a practical guide to using the library. I feel that the second goal is compromised by the first. It seems that most of the content needed for the "cut to the chase" user is present, but by having this presentation in the form of a single document dilutes it. In other words, I don't know that the documentation passes the coworker test. If I were to show it to my coworkers, I can already hear them saying "All this stuff about computational quadrants and heterogeneous algorithms is all well and good, but how do I actually use this thing?". >From the perspective of someone who has never used MPL or Fusion (I started metaprogramming in C++11 and C++14 and never found a need for them), I do not have a problem with the comparisons to the other libraries in the documentation. I know another reviewer had mentioned that as a concern, but it just reads as evaluating prior art rather than reading as assuming prior knowledge. * Tests > I have not looked at the library's tests, I just tried to use it. > * Usefulness > The lack of constexpr lambdas really hurts the library's usefulness. It is because of this hole in the language that it can be difficult to slowly move to hana. I would like to just replace the implementation of a few functions with hana implementations at first, but then my functions are no longer constexpr if I do the obvious implementation. I have to make sure to change all of my types to IntegralConstant, for instance, to get a non-constexpr value from which I can extract a constexpr value from its type. This has a larger ripple throughout than I would like for just testing out a library before committing to it. That being said, once updating your code to fit into this paradigm, it does seem to simplify things a bit. I expect that as I update my library to be more hana friendly throughout, this simplification will increase. It was a bit disheartening at first when my code size grew slightly as I wrote various shims to translate to the correct types (I had more constexpr functions returning bool, and not so much classes that derive from integral_constant), but that ended up being a temporary state until I worked through more code. I wonder if I passed a constexpr function object rather than a non-constexpr lambda if these limitations would be removed? In practice this would probably lead to more code in the intermediate step even if it did work due to the boilerplate of defining a non-lambda function object. > - Did you attempt to use the library? If so: > * Which compiler(s)? > * What was the experience? Any problems? > clang 3.6.0 The first thing I tried was to use is_valid to determine the existence of a member type. This immediately crashed clang in the parser (I haven't had time to extract the bug report yet, but I will). It didn't seem to be the library directly, especially since others have used this feature, but the combination of my library (bounded::integer) with this feature of hana seemed to interact to cause a crash. clang seemed to perform a bit better with my second test, which was to replace some enable_if with if_. > - How much effort did you put into your evaluation of the review? > > In addition to talking with Louis at C++Now, I spent a few days trying out the library.

2 1

comparing test results between master and develop
by Stefan Seefeld 26 Jun '15

26 Jun '15

Hello, I'm trying to compare the state of the develop and master branch for the Boost.Python project, to figure out whether I can merge the develop branch to master. I find that a bit difficult, though, and was wondering whether people here have any advice. Are there any tools to generate an easy-to-analyze diff ? Right now I'm visually inspecting http://www.boost.org/development/tests/master/developer/python.html and http://www.boost.org/development/tests/develop/developer/python.html, which in itself is non-trivial given the size of the table. In addition, some testers only run on develop, some only on master, creating incommensurable results. Is there a better way to do this ? Thanks, Stefan -- ...ich hab' noch einen Koffer in Berlin...

1 0

[build] msvc-14.0 toolset can't find mt.exe?
by Peter Dimov 26 Jun '15

26 Jun '15

I've installed Visual Studio 2015 RC Community, and the msvc-14.0 toolset can't find mt.exe. I have mt.exe (twice), once in the 7.1A SDK, once in the 8.1 SDK. Does anyone have an idea what's wrong?

2 1

[hana]recursive data type?
by Larry Evans 25 Jun '15

25 Jun '15

How would one define a recursive data type in hana something described by the type equation: hana_list<T> = hana::nothing | std::pair<T,hana_list<T> > where hana_list<T> is a list of T's terminated by nothing?

2 2

future/packaged_task Sean Parent design
by Vicente J. Botet Escriba 25 Jun '15

25 Jun '15

Hi, Sean Parent suggests (See [1] Better Code: Concurrency) to remove the promise and left the packaged_task serve as single provider of a future. Both are created at once using the package factory. His future library doesn't include a shared_future as the future contains a value that can be observed several times. The continuation takes the value and not the future. So a future can have several continuations. If the store type is movable only, then the future can have only one continuation. Not really strange coming from Sean, future and packaged_task are copyables :) One more thing, there is not get no wait, but a get_try that return an optional<T>. Scales better. IIUC the implementation allows to implement when_all on top of future/packaged_task. The trick is that that the packaged_task can store some context. async has always an Scheduler as parameter. Scheculers are just Copyable Callables having this signature void(void()). There is no need for function add/spawn. when_all has also a callable as argument. I find the Sean's design clean and simple (See the code [2]). What do you think of it? Do you see any issues on it? * I don't understand why when_all continuation has the futures as parameters (I suspect that this is a type on the documentation). * I would rename get_try to try_get. This function could return optional<expected<T>>. What are you missing ? * catch_error/recover that is already planed. * when_any Best, Vicente [1] https://github.com/sean-parent/sean-parent.github.io/wiki/Papers-and-Presen… [2] https://github.com/stlab/libraries/tree/develop

3 5

Using Clang compiler in place of GCC
by Paul A. Bristow 25 Jun '15

25 Jun '15

I have installed Clang 3.6.1 (along with previously used versions of GCC) downloaded from LLVM and using the clang for LLVM Windows installer on Windows 8.1 I:\modular-boost\libs\fixed_point\example>clang++ --version clang version 3.6.1 (tags/RELEASE_361/final) Target: i686-pc-windows-gnu Thread model: posix suggests that I have the compiler in place OK and it should be in my PATH (becos I asked for it to be). --debug-configuration notice: will use 'C:/LLVM/bin/clang++.exe' for clang-linux, condition <toolset>clang-linux-3.6.1 For a project, I have a jamfile starting project : requirements <include>../include # quickdox/include <include>../../.. # modular-boost root #toolset requirements. # GCC requirements. #<toolset>gcc:<cxxflags>-std=gnu++11 # If requires C++11 library. <toolset>gcc:<cxxflags>-Wno-unused-local-typedefs <toolset>gcc:<cxxflags>-Wno-missing-braces # Clang requirements. #<toolset>clang:<cxxflags>-std=c++11 # If requires C++11 library. (I also have environment BOOST_ROOT = I:\modular-boost) when I run b2 toolset=gcc all compiles and run as expected. when I run b2 toolset=clang I get messages like common.mkdir ..\..\..\bin.v2\libs\quickdox\example\quick_auto_dox_index.test\clang-linux-3.6.1 common.mkdir ..\..\..\bin.v2\libs\quickdox\example\quick_auto_dox_index.test\clang-linux-3.6.1\debug clang-linux.compile.c++.without-pth ..\..\..\bin.v2\libs\quickdox\example\quick_auto_dox_index.test\ clang-linux-3.6.1\debug\quick_auto_dox_index.obj quick_auto_dox_index.cpp:53:10: fatal error: 'iostream' file not found (or other files like cstddef, iomanip on other projects) #include <iostream> ^ 1 error generated. "C:/LLVM/bin/clang++.exe" -c -x c++ -O0 -g -fno-inline -Wall -g -march=i686 -m32 -DBOOST_ALL_NO_L IB=1 -I"..\..\.." -I"..\include" -o "..\..\..\bin.v2\libs\quickdox\example\quick_auto_dox_index.test \clang-linux-3.6.1\debug\quick_auto_dox_index.obj" "quick_auto_dox_index.cpp" (Full log attached). This suggests that it is not finding the system file <iostream> ... but I'm puzzled at what is missing (and why). Suggestions most welcome. Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830

5 11

Stupid Constexpr Lambda Trick
by Giovanni Piero Deretta 24 Jun '15

24 Jun '15

Hi All, In the last few months constexpr lambdas and their absence in the standard came up multiple times in boost-devel, expecially when discussing the Hana library. I just wanted to share a C++14 emulation of the feature. The emulation uses both the already known conditional operator trick to allow constepr function objects to be initialized from lambda expressions, plus what I think is a novel trick to allow the actual function object operator() to be constexpr. Implementation + example is here: https://github.com/gpderetta/libtask/blob/master/lambda.cpp Sorry about the macro obfuscation, I was experimenting with a 'cute' lambda interface, but the underlying idea is very simple and pretty obvious in retrospect. I haven't tested that forwarding is always correc and I probably got some cases wrong. Lambda captures and multiple statemens are doable, but are left as an exercise for the reader :) I came up with the trick when trying to implement an emulation of N3617 (Lifting overload sets into function objects). Turns out that implementing the 'quote' syntax is almost trivial in C++14 with generic lambdas, but making it constexpr reliably has so far eluded me as all implementations I have tried ICE both gcc and clang. Still the constexpr lambda emulation itself seems to work. HTH, -- gpd

2 2

Re: [boost] future/packaged_task Sean Parent designn
by Giovanni Piero Deretta 24 Jun '15

24 Jun '15

On 24 Jun 2015 10:11 am, "Niall Douglas" <s_sourceforge(a)nedprod.com> wrote: > > On 24 Jun 2015 at 1:09, Vicente J. Botet Escriba wrote: > > > Sean Parent suggests (See [1] Better Code: Concurrency) to remove the > > promise and left the packaged_task serve as single provider of a future. > > Both are created at once using the package factory. > > I was at his talk at C++ Now. > > The first thing which put me off his proposal was that he appears to > be unaware of the highly optimised and very flexible de facto task > concurrency system in C++ which has been around for years, and has > just recently been standardised. It's called ASIO. > > I also think packaged_task is overkill for creating futures. There > are some times you really do just want a promise and nothing more. There is no reason for a packaged task implementation to be more heavy weight than a promise. If the packaged task is [](T x) { return x; } then it is also semantically equivalent to promise<T>, just in a nicer interface. Bonus points it works beautifully with ASIO without any explicit support from ASIO itself. > There are even times you just want to create a future standalone, and > for that we now have make_ready_future(). > > > His future library doesn't include a shared_future as the future > > contains a value that can be observed several times. > > If I remember rightly, internally his future has a shared_ptr, which > really means he's proposing that future becomes a shared_future. I > had doubts before until that part, but that killed his proposal for > me. It's a non-starter as a practical design for my needs, but is > still useful for ideas. > His implementation uses a shared ptr, but I think you could do without by deep copying the futures and internally chaining via then. This way you only pay the cost if you actually copy. I strongly believe that 'then' and other accessors should be non const so that concurrent calls *on the same future* need not be supported. -- gpd

3 4

[hana] Formal review
by Christophe Henry 24 Jun '15

24 Jun '15

Dear all, Following is my review of Hana. - Whether you believe the library should be accepted into Boost Yes, unconditionally. Having only one compiler compiling it is not the library's fault and it should not be held against it. If possible, I'd like to have some gcc support (and a clear note of what can be used with gcc). - Your name Christophe Henry - Your knowledge of the problem domain. Good knowledge of TMP, MPL and Fusion through my authoring of MSM. No expert of C++14 - What is your evaluation of the library's: * Design Very nice and interesting. What really slapped me in the face is writing this: template <typename ...T> auto smallest = minimum(make_tuple(type<T>...), [](auto t, auto u) { return sizeof_(t) < sizeof_(u); }); Instead of with MPL: template <typename ...T> struct smallest : deref< typename min_element< vector<T...>, less<sizeof_<_1>, sizeof_<_2>> >::type > { }; Ouch! I had forgotten how hard MPL can be... However, being value-based instead of type-based turns out to be a strength but also a weakness. To test the library, I replaced some simple MPL-based implementation parts of MSM with Hana. It works, but the code is not as simple and clean as I had hoped. For example: typedef typename ::boost::mpl::fold< stt_simulated,mpl::vector0<>, ::boost::mpl::push_back< ::boost::mpl::placeholders::_1, make_row_tag< ::boost::mpl::placeholders::_2 , BaseType > > >::type type; Became: static auto fold() { return boost::hana::fold.left(stt_simulated{}, boost::mpl::vector0<>{}, [](auto vec, auto t) { return typename ::boost::mpl::push_back< decltype(vec), typename make_row_tag <typename decltype(t)::type, BaseType>::type>::type{}; }); } typedef decltype(fold()) type; I had to create object where I actually just wanted types and also a static function so I can decltype. This is because this code was written within a struct (serving as metafunction). Honestly, my win in readability is limited ;-) But my problems started earlier. The heart of MSM is the transition table: struct transition_table : mpl::vector< Row < Stopped , stop , Stopped , none , none >, ... >{} All states and events being types, using Hana would lead me to write: Row < Stopped{} , stop{} , Stopped{} , none{} , none{} > which would be a regression. I'd love to get rid of my mpl::vector but Hana won't help me there. Maybe MSM was the wrong test object. The lack of support for mpl::set reduces to a very small part the algorithms I could port to Hana. Louis seems to want to change this, which I can only welcome. In the end, I feel that using Hana with MSM would be a take all or nothing choice. With the current compiler support, it is not something I will do in the next few months. Still, the library has a nice design and potential and I will probably use it either later in other use cases (or with MSM with better support of MPL). * Implementation I had a short glance and found it very clean. I found only one thing which bugged me, the use of non fully qualified names in some places. True, many other boost libraries do the same and it brings a lot of problems (anyone who tried to include Geometry and TypeErasure in one TU will love the duplicate definition of use_default). Still, a "return true_;" is begging for conflicts. * Documentation Great! Way above Boost level. As others said, please use fully qualified names where possible. It makes it much easier to follow. * Tests Did not look. * Usefulness Very useful if you have objects in the first place, maybe less to do TMP. - Did you attempt to use the library? If so: * Which compiler(s)? Clang 3.5. * What was the experience? Any problems? I got a few compiler errors. - A static_assert "hana::fold.left(xs, state, f) requires xs to be Foldable" when forgetting to #include <boost/hana/ext/boost/mpl/vector.hpp> I had included boost/hana.hpp but it did not include all, which is annoying. - a name conflict with std::size_t, though I deserved punishment by adding a using namespace boost::hana before including other headers. - How much effort did you put into your evaluation of the review? 8 hours reading the doc and rewriting some MSM algorithms with Hana. Thank you Louis for writing this excellent library and thank you Glen for managing the review! Christophe

2 1

[hana] Lorenzo's Formal review for Hana
by Lorenzo Caminiti 24 Jun '15

24 Jun '15

Hello Glen, Louis, and all, Please find below my review of the proposed Boost.Hana library. > - Whether you believe the library should be accepted into Boost Yes, Boost.Hana should be accepted into Boost. I decided to make my acceptance vote unconditional. However, I do have some concerns and I hope these can be addressed if Hana is in fact accepted into Boost. I marked these concerns as "[CONCERN]" below. > - Your name Lorenzo Caminiti. > - Your knowledge of the problem domain. I have been using C++ Template Meta-Programming (TMP) for 10+ years now. I routinely maintain ~23,000 lines of production code that extensively uses Boost.MPL, Boost.Fusion, and a TMP-based serialization mechanism (among a number of other Boost libraries) -- compilation times are a *huge* issue with this code! > You are strongly encouraged to also provide additional information: > - What is your evaluation of the library's: > * Design The library API seems reasonable, consistent, and powerful. * [CONCERN] Assertions should be renamed from ..._CHECK to ..._ASSERT (to be consistent with assert, static_assert, BOOST_STATIC_ASSERT, BOOST_MPL_ASSERT, etc.). * Is there a ..._MSG version for the assertion macros? (These should probably just variadic macros where a second optional parameter represents the error message to display in case the asserted condition if false.) * The following is very nice! auto has_toString = is_valid([](auto&& obj) -> decltype(obj.toString()) { }); I've been wanting to do the above at function scope for a long time (so I can program it within the function where I actually need it). Now with C++14 generic lambdas we finally can :) Also this is very nice! template <typename T> std::string optionalToString(T const& obj) { return if_(has_toString(obj), [](auto& x) { return x.toString(); }, [](auto& x) { return "toString not defined"; } )(obj); } Somewhat similar to my static_if (renamed call_if, after Vicente's suggestion) proposal using C++14 generic lambdas: http://boost.2283326.n4.nabble.com/static-if-Is-there-interest-in-a-static-… BTW, how would you program the following possible implementation of std::advance in Hana? template<typename Iter> struct is_random_access_iterator : std::is_same< typename std::iterator_traits<Iter>::iterator_category, std::random_access_iterator_tag > {}; template<typename Iter> struct is_bidirectional_iterator : std::is_same< typename std::iterator_traits<Iter>::iterator_category, std::bidirectional_iterator_tag > {}; template<typename Iter> struct is_input_iterator : std::is_same< typename std::iterator_traits<Iter>::iterator_category, std::input_iterator_tag > {}; template<typename Iter, typename Dist> void myadvance(Iter& i, Dist n) { Iter *p = &i; // So captures change actual pointed iterator value. call_if<is_random_access_iterator<Iter> >( std::bind([] (auto p, auto n) { *p += n; }, p, n) ).template else_if<is_bidirectional_iterator<Iter> >( std::bind([] (auto p, auto n) { if(n >= 0) while(n--) ++*p; else while(n++) --*p; }, p, n) ).template else_if<is_input_iterator<Iter> >( std::bind([] (auto p, auto n) { while(n--) ++*p; }, p, n) ).else_( std::bind([] (auto false_) { static_assert(false_, "requires at least input iterator"); }, std::false_type()) // Use constexpr value. ); } * This macro: struct Person { BOOST_HANA_DEFINE_STRUCT(Person, (std::string, name), (int, age) ); }; Will it work even if the data member types contain commas? For example, the following is supported, correct? (It should be because these can use variadic macros...) struct Person { BOOST_HANA_DEFINE_STRUCT(Person, (std::map<int, char>, name), (int, age) ); }; P.S. These sort of macros /could/ be implemented as follows if users found this syntax to be more readable (but maybe not...): struct Person { BOOST_HANA_DEFINE_STRUCT(Person, (std::map<int, char>) name, (int) age, ); }; * [CONCERN] The docs say: "Hana's design assumes that most of the time, we want to access all or almost all the elements in a sequence anyway, and hence performance is not a big argument in favor of laziness." Especially given that other well-established libraries like Fusion addressing the same problem domain have gone in favor of laziness instead... Is this a good assumption? If so, why? * [CONCERN] The docs say: "By default, Hana assumes functions to be pure. A pure function is a function that has no side-effects at all." Will this assumption limit what users will be able to do with Hana? Do MPL and Fusion relay on a similar assumption? Yes/no, why... * [CONCERN] I would prefer a descriptive name for the library instead of Hana. I am well aware that Phoenix, Spirit, Wave, etc. are examples of non-descriptive names in Boost. I consider those bad naming choices and I would not follow them. Changing the library name should only take a few days (maybe 2-5 days... especially with tools like grep and sed) so that should not be a problem. Others pointed out that there might be copyright/trademark issues with the name "Hana". The possibility to have to change such name at some point /after/ the library has been released in Boost would be a disaster for the users... such risk should be avoided. Possible names? typeval (given the library is about "TYPEs as VALuses", plus the similar, already familiar, name std::declval) meta metaval metaexpr generic (assuming Matt Calabrese is no longer planning to use this) ... * [CONCERN] Rename Map, Range, etc. to map, range, etc. (all lower case). In Boost and STL capital letters are only used for template parameters, and maybe concepts. (If it is important to distinguish that those are tags (I don't think so) then name them map_tag, range_tag, etc. but still no capital letters.) * [CONCERN] is_empty, length, and few other names should be changed to empty, size, etc. to match STL naming conventions (so I don't have to remember different names for the same thing). > * Implementation Some code can be optimized, but the author already mentioned he will look into that this summer. I did not see any specific issue otherwise. > * Documentation * [CONCERN] The documentation will be much (much!) more readable is the "hana" namespace was not stripped away. Please write hana::..., mpl::... (if not the full boost::hana::..., boost::mpl::...) in the docs. * The docs say: "Notice how we cast the result of x.member to void? This is to make sure that our detection also works for types that can't be returned from functions, like array types." auto has_member = is_valid([](auto&& x) -> decltype((void)x.member) { }); But obviously, the following (without the cast) would work too, correct? auto has_member = is_valid([](auto&& x) -> decltype(x.member, void()) { }); * I would expect the following example to use operator|| instead of or_: auto ts = filter(types, [](auto t) { return or_(is_pointer(t), is_reference(t)); }); * Performance graphs would be more readable if they always used the same color for the same entity. For example, sometimes mpl::vector is blue, other times it is orange... * Why the "Runtime performance of reverse on normal container" for fusion::vector stops at "Number of elements" = 50? > * Tests > > * Usefulness * If not for anything else, I will use this library for its SFINAE facilities. Second, I will use this library in production code for its improved compilation times (assuming these can be confirmed on MSVC). Finally, I am curious to use this library in general because it seems it will improve my meta-programming, also making easier to read. * [CONCERN] The author should be committed to support the library on GCC and MSVC once that becomes feasible, even if that requires a good deal of workarounds. For example, Boost.Preprocessor is full of MSVC workaround (because MSVC preprocessor is still not standard compliant... after 30+ years of existence of the C preprocessor). Maybe MSVC will never be 100% C++14 standard compliant... I don't know. But I do know that if this library is not ported to MSVC at some future point, I won't be able to use it in my production code. I do hope that adoption into Boost will push vendors to support C++14 constructs used by this library TMP techniques. I also hope the author is committed to do whatever it takes to make the library work on MSVC. * [CONCERN] What compiler was used to measure performance? CLang? I hope the promised performance gains (especially compile-time reductions) will be there for GCC, and especially later also for MSVC. If not, that will significantly limit my motivation on using this library in production code. TMP compilation times are largely dependant on specific compiler implementations of C++ template machinery which might vary significantly from vendor to vendor. Therefore, at the moment I only know that the library is expected to compile faster on Clang, but unfortunately that does not tell me anything about expected compilation time improvements on GCC, and even less on MSVC... > - Did you attempt to use the library? If so: > * Which compiler(s)? Clang. > * What was the experience? Any problems? Overall, pretty good experience. No specific issue to report a part from what already noted. > - How much effort did you put into your evaluation of the review? A total of about 2 days between reading docs, playing with some examples, and looking at the code a bit. My thanks to Luis for his outstanding work with this library! --Lorenzo On Wed, Jun 10, 2015 at 2:19 AM, Glen Fernandes <glen.fernandes(a)gmail.com> wrote: > Dear Boost community, > > The formal review of Louis Dionne's Hana library begins today,10th June > and ends on 24th June. > > Hana is a header-only library for C++ metaprogramming that provides > facilities for computations on both types and values. It provides a > superset of the functionality provided by Boost.MPL and Boost.Fusion > but with more expressiveness, faster compilation times, and faster (or > equal) run times. > > To dive right in to examples, please see the Quick start section of the > library's documentation: > http://ldionne.com/hana/index.html#tutorial-quickstart > > Hana makes use of C++14 language features and thus requires a C++14 > conforming compiler. It is recommended you evaluate it with clang 3.5 or > higher. > > Hana's source code is available on Github: > https://github.com/ldionne/hana > > Full documentation is also viewable on Github: > http://ldionne.github.io/hana > > To read the documentation offline: > git clone http://github.com/ldionne/hana --branch=gh-pages doc/gh-pages > > For a gentle introduction to Hana, please see: > 1. C++Now 2015: > http://ldionne.github.io/hana-cppnow-2015 (slides) > 2. C++Con 2014: > https://youtu.be/L2SktfaJPuU (video) > http://ldionne.github.io/hana-cppcon-2014 (slides) > > We encourage your participation in this review. At a minimum, kindly > state: > - Whether you believe the library should be accepted into Boost > * Conditions for acceptance > - Your name > - Your knowledge of the problem domain. > > You are strongly encouraged to also provide additional information: > - What is your evaluation of the library's: > * Design > * Implementation > * Documentation > * Tests > * Usefulness > - Did you attempt to use the library? If so: > * Which compiler(s) > * What was the experience? Any problems? > - How much effort did you put into your evaluation of the review? > > We await your feedback! > > Best, > Glen > > _______________________________________________ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

2 1

[graph] depth_first_visit_impl
by Michael Marcin 24 Jun '15

24 Jun '15

I was doing some work with depth_first_search and came across some issues that seem surprising with the implementation. First vis.finish_edge doesn't seem to ever get called on msvc. Second changing the code to call finish_edge directly instead of through the call_finish_edge machinery seems to result in incorrect edges being finished. Third the implementation of depth_first_visit_impl pushes into a std::vector stack even for vertices with no out_edges. If I have a graph with a large number of vertices but few or no edges this seems bad. This seems to force a dependency on optional as well. Finally the loop as written should probably be a do..while since the stack will never be empty on the first test. I attached a patch that addresses the second and third issues. The tests continue to pass for me with this change.

1 0

[Hana] Formal review
by Bruno Dutra 23 Jun '15

23 Jun '15

Dear all, Following is my review of Hana. - Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. Yes, absolutely, but please read on. - Are you knowledgeable about the problem domain? I've been playing with metaprogramming as a hobby since 2011 when I first came across Boost.MPL. I experimented with a library that implements the unification algorithm at compile time using Boost.MPL for a long time, on and off, and recently I've decided giving a shot at my own implementation of a C++11 version of Boost.MPL. - What is your evaluation of the design? The design seems to be very general and abstract, based on formal mathematical concepts. I've had my dose of FP through SML and lisp, however I've never dug deep into category theory, so I won't venture into judging the way these abstract concepts were translated to C++, but all looks sound to me. I'm very fond of the way type computations are carried out by value through the use of type<> and decltype(). Such an ingenious simplicity. Once one gets it, one realizes how beautifully it merges value and type computations into one. I also like very much the design of compile time constants, their custom _c suffix and operators. To me, that is material for standardization. I would like to point out however, that from the point of view of someone who has basically solely done C++ his entire life, just like myself, Hana can look *very* unfamiliar. I understand it is mostly my fault for not properly having learnt FP before, however I believe I'm not alone among average C++ programmers, so I fear this could prevent many potential users from adopting Hana, simply because one tends to stick to things that look familiar to one. Now I'm not sure that is any easy way around this unfamiliarity. I've seen others pointing out that names could better reproduce the C++ standard library (to what I agree) and perhaps that's indeed all one could do to tighten the gap that separates Hana from mainstream C++ libraries. At any rate, I just felt I should stress this point, to make sure it is not underestimated. - What is your evaluation of the implementation? I've just briefly peeked at the code base out of curiosity and it looks pretty clean and organized. The use of global function objects however intrigues me, why not free functions? I've also found myself stumbling on variable templates. Perhaps that's just me, but really I find they make everything so cryptic. Anyways, I guess it's not Hana's fault to make arguably good use of something that is part of the language. - What is your evaluation of the documentation? I find myself blindly using the search button in hope to find whatever I'm looking for more often than I'd rather do, but perhaps it's just a matter of getting used to how the documentation is organized. One thing I'd like to see improved is the alphabetical index. I'd expect it to be thorough, but at least "is_a" is missing, so I assume a rationale exists to decide what goes there? I think it would be better to list everything exhaustively, so users may rely on the browser's find tool to explore the library. - What is your evaluation of the potential usefulness of the library? At first I was afraid Hana were too academical and abstract to be a good tool for getting down to business, but after playing with it a little bit I can see that, once one gets its design, it does make metaprogramming quite straightforward. I believe however that most users will attain to a very limited subset of functionalities in order to just get their tasks accomplished. So much so, that I'd strongly advise Hana to be split into one highly specialized tool for straightforward metaprogramming and another more abstract halve providing the more generic concepts. This could ease user experience considerably, reducing the novelty presented by Hana and thus tightening the gap I've mentioned before. - Did you try to use the library? With what compiler? Did you have any problems? Yes on Clang 3.6.1. I tried to implement the unification algorithm [1] at compile time using Hana and, though I haven't actually finished, I could see it would be straightforward. In fact I gave up on it when I found a bug which prevented the construction of optional maps, but not too long after I contacted Louis and opened an issue [2] it seems to have already been fixed on develop branch. I didn't test the fix myself though. - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? About 4 hours reading the documentation, another 4 hours trying the library and about 2 hours to write this review. *Bruno C. O. Dutra* [1]: https://en.wikipedia.org/wiki/Unification_(computer_science) [2]: https://github.com/ldionne/hana/issues/149

3 4

[test] Re: [Boost-testing] Develop branch test runners crashing
by Rene Rivera 23 Jun '15

23 Jun '15

Please fix ASAP. On Tue, Jun 23, 2015 at 8:32 AM, Tom Kent <lists(a)teeks99.com> wrote: > Sometime between 22:30 and 03:30 last night (pacific time) all the develop > tests started crashing on windows and linux. > > The tail of results/bjam.log is: > > notice: iostreams: not using bzip2 compression > notice: iostreams: not using bzip2 compression > ..\libs\test\test\Jamfile.v2:59: in docs-example-as-test > *** argument error > * rule boost.test-self-test ( test-rule : test-suite : test-name : > usage-variant ? : pattern_file * : source_files * : extra-libs ? : > extra-options ? ) > * called with: ( : ../doc/examples : : included : : > /D:/t08/run/boost_root/libs/test/doc/examples/boost_test_bitwise.run-fail.cpp > ) > * missing argument test-rule > ..\libs\test\test\Jamfile.v2:18:see definition of rule > 'boost.test-self-test' being called > (builtin): in sequence.transform > ..\libs\test\test\Jamfile.v2:162: in modules.load > D:/t08/run/boost_bb/src/build\project.jam:325: in load-jamfile > D:/t08/run/boost_bb/src/build\project.jam:64: in load > D:/t08/run/boost_bb/src/build\project.jam:145: in project.find > D:/t08/run/boost_bb/src/build\targets.jam:452: in find-really > D:/t08/run/boost_bb/src/build\targets.jam:474: in find > D:/t08/run/boost_bb/src/build\targets.jam:305: in targets-to-build > D:/t08/run/boost_bb/src/build\targets.jam:270: in > class(a)project-target.generate > D:/t08/run/boost_bb/src\build-system.jam:707: in load > D:\t08\run\boost_bb\src/kernel\modules.jam:295: in import > D:\t08\run\boost_bb\src/kernel/bootstrap.jam:139: in boost-build > D:\t08\run\boost_root\boost-build.jam:17: in module scope > > Any thoughts? > > _______________________________________________ > Boost-Testing mailing list > Boost-Testing(a)lists.boost.org > http://lists.boost.org/mailman/listinfo.cgi/boost-testing > -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

1 0

Re: [boost] [test] Develop branch test runners crashing
by Andrey Semashev 23 Jun '15

23 Jun '15

On Tue, Jun 23, 2015 at 4:32 PM, Tom Kent <lists(a)teeks99.com> wrote: > Sometime between 22:30 and 03:30 last night (pacific time) all the develop > tests started crashing on windows and linux. > > The tail of results/bjam.log is: > > notice: iostreams: not using bzip2 compression > notice: iostreams: not using bzip2 compression > ..\libs\test\test\Jamfile.v2:59: in docs-example-as-test > *** argument error > * rule boost.test-self-test ( test-rule : test-suite : test-name : > usage-variant ? : pattern_file * : source_files * : extra-libs ? : > extra-options ? ) > * called with: ( : ../doc/examples : : included : : > /D:/t08/run/boost_root/libs/test/doc/examples/boost_test_bitwise.run-fail.cpp > ) > * missing argument test-rule > ..\libs\test\test\Jamfile.v2:18:see definition of rule > 'boost.test-self-test' being called > (builtin): in sequence.transform > ..\libs\test\test\Jamfile.v2:162: in modules.load > D:/t08/run/boost_bb/src/build\project.jam:325: in load-jamfile > D:/t08/run/boost_bb/src/build\project.jam:64: in load > D:/t08/run/boost_bb/src/build\project.jam:145: in project.find > D:/t08/run/boost_bb/src/build\targets.jam:452: in find-really > D:/t08/run/boost_bb/src/build\targets.jam:474: in find > D:/t08/run/boost_bb/src/build\targets.jam:305: in targets-to-build > D:/t08/run/boost_bb/src/build\targets.jam:270: in > class(a)project-target.generate > D:/t08/run/boost_bb/src\build-system.jam:707: in load > D:\t08\run\boost_bb\src/kernel\modules.jam:295: in import > D:\t08\run\boost_bb\src/kernel/bootstrap.jam:139: in boost-build > D:\t08\run\boost_root\boost-build.jam:17: in module scope > > Any thoughts? Looks like a Boost.Test issue.

1 0

Develop branch test runners crashing
by Tom Kent 23 Jun '15

23 Jun '15

Sometime between 22:30 and 03:30 last night (pacific time) all the develop tests started crashing on windows and linux. The tail of results/bjam.log is: notice: iostreams: not using bzip2 compression notice: iostreams: not using bzip2 compression ..\libs\test\test\Jamfile.v2:59: in docs-example-as-test *** argument error * rule boost.test-self-test ( test-rule : test-suite : test-name : usage-variant ? : pattern_file * : source_files * : extra-libs ? : extra-options ? ) * called with: ( : ../doc/examples : : included : : /D:/t08/run/boost_root/libs/test/doc/examples/boost_test_bitwise.run-fail.cpp ) * missing argument test-rule ..\libs\test\test\Jamfile.v2:18:see definition of rule 'boost.test-self-test' being called (builtin): in sequence.transform ..\libs\test\test\Jamfile.v2:162: in modules.load D:/t08/run/boost_bb/src/build\project.jam:325: in load-jamfile D:/t08/run/boost_bb/src/build\project.jam:64: in load D:/t08/run/boost_bb/src/build\project.jam:145: in project.find D:/t08/run/boost_bb/src/build\targets.jam:452: in find-really D:/t08/run/boost_bb/src/build\targets.jam:474: in find D:/t08/run/boost_bb/src/build\targets.jam:305: in targets-to-build D:/t08/run/boost_bb/src/build\targets.jam:270: in class(a)project-target.generate D:/t08/run/boost_bb/src\build-system.jam:707: in load D:\t08\run\boost_bb\src/kernel\modules.jam:295: in import D:\t08\run\boost_bb\src/kernel/bootstrap.jam:139: in boost-build D:\t08\run\boost_root\boost-build.jam:17: in module scope Any thoughts?

1 0

[coroutine2] Difference between coroutine and coroutine2
by Aaron Levy 23 Jun '15

23 Jun '15

Are boost::coroutines::symmetric_coroutine<> and boost::coroutines::asymmetric_coroutine<> part of the coroutine library or coroutine2 library. Besides being C++14-only, in what ways does coroutine2 differ from coroutine? -- Aaron Levy aaron.levy(a)yandex.com

5 7

[Optional] Monadic bind
by Tobias Loew 23 Jun '15

23 Jun '15

While playing around with boost::optionals I had code like the following struct A { ... int i; ... }; boost::optional a; // do something with 'a' // optional-projection to a::i boost::optional<int> a_i; if(a) a_i = a->i; which seemed quite verbose for something that's rather natural in functional languages: boost::optional is a monadic structure, which lifts a type T by extending it with a new bottom-element (represented by the empty optional<T>), thus it should also have a "bind" and a "map"-equivalent, which could be implemented for instance as as member functions of optional template<class B> auto bind(B&& binder) const -> boost::optional<typename std::decay<decltype(std::bind(binder, get())())>::type> { if(this->is_initialized()) { return std::bind(binder, get())(); } else { return boost::none; } } and template<class B> auto map(B&& f) const -> boost::optional<typename std::decay<decltype(std::bind(f, get())())>::type> { if(this->is_initialized()) { return std::bind(f, get())(); } else { return boost::none; } } where map lifts f from A->B to optional -> optional< B > and applies 'this' to it. This would allow things like boost::optional a; auto a_i = a.map(&A::i); // "optional-projection"; type of a_i is boost::optional<int> Tobias -- View this message in context: http://boost.2283326.n4.nabble.com/Optional-Monadic-bind-tp4677431.html Sent from the Boost - Dev mailing list archive at Nabble.com.

2 7

[test] Where we are with the new version?
by Vicente J. Botet Escriba 23 Jun '15

23 Jun '15

Hi, I'm wondering if the new Boost.Test will be merged one day to the master branch. Best, Vicente

3 5

[config] 'requres' doesn't take differing -std into account
by Peter Dimov 22 Jun '15

22 Jun '15

I have, in my user-config.jam, using gcc ; feature.subfeature toolset gcc : std : cxx0x cxx11 cxx1y cxx14 : optional composite propagated ; feature.compose <toolset-gcc:std>cxx0x : <cxxflags>-std=c++0x ; feature.compose <toolset-gcc:std>cxx11 : <cxxflags>-std=c++11 ; feature.compose <toolset-gcc:std>cxx1y : <cxxflags>-std=c++1y ; feature.compose <toolset-gcc:std>cxx14 : <cxxflags>-std=c++14 ; using clang : : : <cxxflags>-Wno-variadic-macros <cxxflags>-Wno-c99-extensions ; feature.subfeature toolset clang : std : cxx0x cxx11 cxx1y cxx14 : optional composite propagated ; feature.compose <toolset-clang:std>cxx0x : <cxxflags>-std=c++0x ; feature.compose <toolset-clang:std>cxx11 : <cxxflags>-std=c++11 ; feature.compose <toolset-clang:std>cxx1y : <cxxflags>-std=c++1y ; feature.compose <toolset-clang:std>cxx14 : <cxxflags>-std=c++14 ; This allows me to use toolset=clang (without -std) and toolset=clang-cxx11 (with -std=c++11). The 'requires' rule however caches the results of the configuration check when I run with toolset=clang, and then when I rerun with toolset=clang-cxx11, it uses the cached values, which is wrong. I use something like run test.cpp : : : [ requires cxx11_variadic_templates cxx11_template_aliases cxx11_hdr_type_traits cxx11_hdr_tuple ] ;

6 16

[hana] question
by Christophe Henry 22 Jun '15

22 Jun '15

Hi Louis, I'm experimenting with hana for the review and have one question. I can fold with boost::hana::fold.left(boost::mpl::vector<...>{}...) Do you have a way to iterate on elements of a mpl::set? Thanks, Christophe

2 1

[Boost] [Hana] Formal review for Hana
by Glen Fernandes 22 Jun '15

22 Jun '15

Dear Boost community, The formal review of Louis Dionne's Hana library begins today,10th June and ends on 24th June. Hana is a header-only library for C++ metaprogramming that provides facilities for computations on both types and values. It provides a superset of the functionality provided by Boost.MPL and Boost.Fusion but with more expressiveness, faster compilation times, and faster (or equal) run times. To dive right in to examples, please see the Quick start section of the library's documentation: http://ldionne.com/hana/index.html#tutorial-quickstart Hana makes use of C++14 language features and thus requires a C++14 conforming compiler. It is recommended you evaluate it with clang 3.5 or higher. Hana's source code is available on Github: https://github.com/ldionne/hana Full documentation is also viewable on Github: http://ldionne.github.io/hana To read the documentation offline: git clone http://github.com/ldionne/hana --branch=gh-pages doc/gh-pages For a gentle introduction to Hana, please see: 1. C++Now 2015: http://ldionne.github.io/hana-cppnow-2015 (slides) 2. C++Con 2014: https://youtu.be/L2SktfaJPuU (video) http://ldionne.github.io/hana-cppcon-2014 (slides) We encourage your participation in this review. At a minimum, kindly state: - Whether you believe the library should be accepted into Boost * Conditions for acceptance - Your name - Your knowledge of the problem domain. You are strongly encouraged to also provide additional information: - What is your evaluation of the library's: * Design * Implementation * Documentation * Tests * Usefulness - Did you attempt to use the library? If so: * Which compiler(s) * What was the experience? Any problems? - How much effort did you put into your evaluation of the review? We await your feedback! Best, Glen

7 33

Re: [boost] [Hana] Formal review
by David Sankel 22 Jun '15

22 Jun '15

On Wed, Jun 10, 2015 at 3:19 AM, Glen Fernandes <glen.fernandes(a)gmail.com> wrote: > - Whether you believe the library should be accepted into Boost > * Conditions for acceptance > Yes, I think it should be accepted into Boost. The one condition is that the library works with release versions of at least two different mainstream C++ compilers. More on that later... > - Your name > David J. Sankel > - Your knowledge of the problem domain. > I've written numerous libraries that make use of Boost.MPL and Boost.Fusion. I also have quite a bit of functional programming expertise. > > You are strongly encouraged to also provide additional information: > - What is your evaluation of the library's: > * Design > The core technique of combining value and type expressions is solid and makes metaprogramming easier and, as a bonus, improves compilation speeds. My one question, as I read though the implementation, is "can the core benefits of this library be achived with a simpler 'light' version of this implementation?". While I appreciate the attempt to encode a Haskell-style typeclass hierarchy, I feel like that is not the core competency of hana and should be a separate library and discussion. As it is, this is a 32k header mega library. I'd prefer several small, highly-targeted, highly-composable libraries. > * Implementation > The code itself looks to be well structured and well documented. Unfortunately hana only works with one compiler: clang. While I agree that Boost shouldn't need to support Visual C++ 6.0 anymore, I believe this is going too far in the opposite direction. The home page states that boost libraries "are intended to be widely useful, and usable across a broad spectrum of applications". I've always interpreted that statement to be in a practical rather than theoretical sense and I don't think hana meets that criteria. Many other Boost authors have made heroic efforts to meet that criteria and the reputation of Boost is due, in no small part, to those efforts. I do appreciate the argument that making use of new features encourages compiler implementers to implement then. I maintain, however, that this isn't Boost's job. Boost provides high quality libraries that the every-day Joe C++ developer can benefit from. That being my position on the issue, my acceptance vote is conditional on hana supporting at least two released versions of mainstream compilers. Given that gcc support seems pretty close, that shouldn't be hard to achieve. * Documentation > Looks good. > * Tests > I didn't evaluate these. I tried, but failed, to build the code and filed related issues. I'm assuming the problems are minor and straightforward to fix. * Usefulness > Maybe in a couple years for me. Without VS 2015 support at least, I'm going to be waiting a while. - Did you attempt to use the library? Yes. Started working through the getting started examples. > If so: > * Which compiler(s) > clang 3.6.1 > * What was the experience? Any problems? > Nothing more to add. I filed an issues for all problems encountered and they seemed minor. > - How much effort did you put into your evaluation of the review? > I attended both of Louis's talks, skimmed through the documentation, attempted to build, and read portions of the code. -- David Sankel

17 38

Attn: Volodya.. Re: [config] 'requres' doesn't take differing -std into account
by Rene Rivera 22 Jun '15

22 Jun '15

On Sun, Jun 21, 2015 at 8:11 PM, Edward Diener <eldiener(a)tropicsoft.com> wrote: > On 6/21/2015 10:19 AM, Peter Dimov wrote: > >> I have, in my user-config.jam, >> >> using gcc ; >> >> feature.subfeature toolset gcc : std : cxx0x cxx11 cxx1y cxx14 : >> optional composite propagated ; >> >> feature.compose <toolset-gcc:std>cxx0x : <cxxflags>-std=c++0x ; >> feature.compose <toolset-gcc:std>cxx11 : <cxxflags>-std=c++11 ; >> feature.compose <toolset-gcc:std>cxx1y : <cxxflags>-std=c++1y ; >> feature.compose <toolset-gcc:std>cxx14 : <cxxflags>-std=c++14 ; >> >> using clang : : : <cxxflags>-Wno-variadic-macros >> <cxxflags>-Wno-c99-extensions ; >> >> feature.subfeature toolset clang : std : cxx0x cxx11 cxx1y cxx14 : >> optional composite propagated ; >> >> feature.compose <toolset-clang:std>cxx0x : <cxxflags>-std=c++0x ; >> feature.compose <toolset-clang:std>cxx11 : <cxxflags>-std=c++11 ; >> feature.compose <toolset-clang:std>cxx1y : <cxxflags>-std=c++1y ; >> feature.compose <toolset-clang:std>cxx14 : <cxxflags>-std=c++14 ; >> >> This allows me to use toolset=clang (without -std) and >> toolset=clang-cxx11 (with -std=c++11). >> >> The 'requires' rule however caches the results of the configuration >> check when I run with toolset=clang, and then when I rerun with >> toolset=clang-cxx11, it uses the cached values, which is wrong. >> > > I believe the same problem is causing predef-check problems in the predef > library because I have seen local errors using predef-check which also says > that a previous calculation on another toolset has been cached and is being > reused, even when the toolset changes. Somehow the incorrect cached value > is being retained by Boost Build even when the toolset value changes and a > new calculation needs to be made. But like many other people I don't know > nearly enough about Boost Build to figure out what it is doing. I must confess I don't know the rationale for limiting the feature set for config checks. We have to see what Volodya says about this. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

1 0

[release] policy not to add C++14 libraries
by Oliver Kowalke 21 Jun '15

21 Jun '15

Hi, I'm wondering if C++14 libraries will not be added to the boost release? Oliver

7 20

[Boost] [Hana] Announcing Hana's formal review next week (June 10th)
by Glen Fernandes 21 Jun '15

21 Jun '15

Dear Boost community, The formal review of Louis Dionne's Hana library starts Monday, 10th June and ends on 24th June. Hana is a header-only library for C++ metaprogramming that provides facilities for computations on both types and values. It provides a superset of the functionality provided by Boost.MPL and Boost.Fusion but with more expressiveness, faster compilation times, and faster (or equal) run times. To dive right in to examples, please see the Quick start section of the library's documentation: http://ldionne.com/hana/index.html#tutorial-quickstart Hana makes use of C++14 language features and thus requires a C++14 conforming compiler. It is recommended you evaluate it with clang 3.5 or higher.[1] Hana's source code is available on Github: https://github.com/ldionne/hana Full documentation is also viewable on Github: http://ldionne.github.io/hana To read the documentation offline: git clone http://github.com/ldionne/hana --branch=gh-pages doc/gh-pages For a gentle introduction to Hana, please see: 1. C++Now 2015: http://ldionne.github.io/hana-cppnow-2015 (slides) 2. C++Con 2014: https://youtu.be/L2SktfaJPuU (video) http://ldionne.github.io/hana-cppcon-2014 (slides) We encourage your participation in this review. At a minimum, kindly state: - Whether you believe the library should be accepted into Boost - Your name - Your knowledge of the problem domain. You are strongly encouraged to also provide additional information: - What is your evaluation of the library's: * Design * Implementation * Documentation * Tests * Usefulness - Did you attempt to use the library? If so: * Which compiler(s)? * What was the experience? Any problems? - How much effort did you put into your evaluation of the review? [1] A note for Windows users: As mentioned, Hana requires a C++14 conforming compiler. If you would like to try it, a VM with Linux and clang 3.5 is a fairly painless option. Some users have also reported success with using Clang 3.5 on Windows. If you would like assistance configuring the former option, feel free to reach out to us for this. Best, Glen

12 44

needs coroutine2 a review?
by Oliver Kowalke 21 Jun '15

21 Jun '15

coroutine2 is a C++14-only library, providing cleaner code (maintainability) + it fixes some issues (moveable-only parameters). boost.coroutine will be deprecated. The conclusion of the last discussion ( http://boost.2283326.n4.nabble.com/transforming-ex-boost-lib-into-C-11-only…) was to establish coroutine2 as a separate lib beside of boost.coroutine - similar to boost.signals(2). I'm wondering if coroutine2 needs a review, even if the interface remains the same compared to boost.coroutine. Oliver

4 6

[coroutine2] search for review manager (mini-review)
by Oliver Kowalke 21 Jun '15

21 Jun '15

Hi, is there anyone wishing to help with mini review and become a review manager? coroutine2 is a C++14 implementation of boost.coroutine. github: https://github.com/boostorg/coroutine2 docu: http://olk.github.io/libs/coroutine2/doc/html/ best regardds, Oliver

2 1

[coroutine2] add to testing
by Oliver Kowalke 21 Jun '15

21 Jun '15

Hi, I'm uncertain if boost.coroutine2 (C++11-only) will be part to the 1.58 release - a git-submodule exists but not at the list for the regression tests (I've opened a pull-request to boostorg/boost). Could you tell me the status of boost.coroutine2?! thx, Oliver

2 3

[Hana] Review
by Roland Bock 20 Jun '15

20 Jun '15

Hi, Here are my review results: - Whether you believe the library should be accepted into Boost Yes. - Your name Roland Bock - Your knowledge of the problem domain. On the one hand, I do believe to have some knowledge in TMP, being the author of sqlpp11. I have made some minor contributions to early versions of Hana, discussing implementations of type sets and all/any/none. I experimented with the MPL for quite some time before the advent of C++11... On the other hand, I am almost totally blank when it comes to Haskell or Fusion. - What is your evaluation of the library's: * Design Awesome. Using template variables to turn types into objects and then treating types and values the same way in most places is very cool. * Implementation I haven't spent too much time on the implementation. I read code around hana::string and hana::all. It was nicely structured and quite readable. * Documentation Impressive already. With all the input from the reviews coming in, it will become even better. I found navigation/searching a bit awkward sometimes. Personally, I would like more cross links/tables. E.g. functions working with Set (Louis already created an issue on github for this). * Tests To be honest, I did not look at them. * Usefulness We'll see what comes out of it. Which libraries are actually going to use Hana. I'll give it a try with sqlpp11. As others have stated, it might be a bit too much even. BUT, regardless of how many projects will actually use it, Hana will force some compiler teams to go to great lengths to be able to compile the library. It might also become a benchmark in terms of compile time and the number of generated instructions. Also, Hana contains a wealth of design ideas, tricks and knowledge for anybody who needs to solve a particular compile time problem. I am sure that many library authors and other developers will benefit from this Hana being available, maintained and developed within Boost. And Hana has minimal dependencies (just a handful of headers from the standard library). Thus Hana might help to change the impression that many people have of Boost (coming from many established, older Boost libraries): Awesomely cool stuff, but dependencies from all nine levels of hell (aka, you can look, but you better not touch). To sum it up: Usefulness? Very! - Did you attempt to use the library? If so: * Which compiler(s)? clang-3.5.1 * What was the experience? Any problems? As described in an earlier mail: - I tried to use Hana's string UDL (the gcc/clang hack) but failed. Hana is not to blame here, it is rather because of shortcomings in the C++ core language. - I thought about using Hana's all/any/none, but my own versions were proven (by Louis himself) to be outstandingly fast, so no reason to switch - I thought of switching to Hana's compile time sets, but that seemed like a tough thing to do considering that I am using type sets and Hana is using value sets. Louis showed samples from Zach Laine which would make the transition easier. Actually, something like this should be part of the documentation. Maybe it might make sense to have a collection of migration examples (before/after code)? That might not sound very successful, but I think it was: While researching how I could achieve my goals I learned a lot about the library. - How much effort did you put into your evaluation of the review? Several hours of reading and some tests in combination with sqlpp11. Remark on compilers: There was some argument as to whether Boost could contain a library that can only be compiled by one compiler (actually, maybe two in this case). My personal opinion is: Yes, Boost could and should do that if the library complies with a modern version of the C++ standard. Compiler teams take pride in being able to compile boost. If they cannot compile a Boost library, they will try to accomplish that ASAP. This is going to help everyone. It is good to have libraries in Boost that challenge compilers even to the point of breaking one or the other. Trying to work around compiler bugs does not seem right for new libraries. Thanks to Louis for his library and to Glen for managing the review! Best, Roland

2 1

[Hana] Formal Review
by Krzysztof Jusiak 20 Jun '15

20 Jun '15

Hi, Please find my review below. - Whether you believe the library should be accepted into Boost Definitely YES. IMHO, one of the most complete boost proposals. - Your name Krzysztof Jusiak - Your knowledge of the problem domain. I've been using MPL and Fusion for about 6 years in commercial projects, I also have been using C++11 /C++14 template features in open source projects since they become available. I have some experience with Haskell and other functional programming languages. You are strongly encouraged to also provide additional information: - What is your evaluation of the library's: * Design Library seems to be very well designed. Used patterns are easy to follow. There is a distinction between algorithms, data types and concepts. The approach is really easy to follow for Haskell programmers, but, on the other hand, C++ influence might be noticed as well. Seems to be very straight forward mix of approaches. * Implementation Source Code: First impression, it's a lot of it! But it's easy to follow. Helpful directory structure makes it much easier to handle. Big thanks for changing the naming as well, `snoc`, `cons` and so on, could have been hard to follow for C++ programmers. Implementation consist of a high quality source code. There are few small things, which are not as straight forward. * a lot of fwd (assume forward declaration files) files have implementation inside, which is a bit confusing * a bit annoying `#ifdef BOOST_HANA_DOXYGEN_INVOKED` all over the source code Performance: I have to admit, I really appreciate the library handled this topic. MPL/Fusion, although, very useful are really hard to introduce in commercial projects in the large scale. I do remember using Boost.MSM for a bit, but the company had to give up on it, because having a transition table with more than 200 entries wasn't easy to deal with, to say at least. Having sad that, I think Hana can still improve the compilation times. I didn't even bother to compare it to MPL or Fusion, because there is no comparison there, but with C++ template tricks there is. Compilation time: So I have written simple example to compare `Hana Map` and `C++ Tricks Map`. Please notice, I compared map with 1000 entries! Hehehe, can anyone imagine that with MPL or Fusion? Results are here: tricks_map: https://gist.github.com/krzysztof-jusiak/cb6633d6c11572c33928 0m0.095s hana_map: https://gist.github.com/krzysztof-jusiak/949d3916d84c466b80c5 0m11.105s So, Hana seems to be much slower, but still not really slow. It's not hours, just a few seconds, which IMHO, it's a huge improvement already. run-time: Haven't checked this part as deeply. Diagnostic Messages: Really popular topic recently and Hana made a huge progress with it as well. Concepts helps a lot, but, unfortunately, there is always a call stack following the error message. Sometimes, such approach is desired, but would be great not to see all Hana's internals, especially with recursive algorithms. Tested error message: https://gist.github.com/krzysztof-jusiak/bfc51747d083e140772d I also had some issue, when some include was missing. Compilation was fine, but the computation was run-time only. Would be great to somehow handle this problem. It's really tricky to understand, why it doesn't work as expected. Debugging: Guess, in this matter, there is still no much progress. I tried Hana with MetaShell and TempLight, but, although, it was way better experience, it still was hard to debug the library. What about run-time algorithms? I haven't checked how hard it is to debug them, but I suspect it will be the same story as with STL, unless some magic is happening in HANA under the hood? * Documentation Documentation is really impressive. Honestly, love the search button! Would like to see more copy/paste examples tho. I'm really inpatient sometimes and when have to find part of the example at one place and figure out includes I do get easily annoyed. Related to that, would be great to always see which file has to be included for anything which is not included by `boost/hana.hpp`. As already mentioned, would be better to use hana::... instead of having an assumption for `using namespace boost::hana`. I would also add some tutorial for less experienced users with explanations what the monad is and how functional programming concepts are applied in Hana. * Tests Impressive unit tests collection. Unfortunately, they are not that easy to follow. Approach like: // check a { } // check b { } is not the best and I would encourage to add separate tests for both cases. Would be great to have CI tests for run-time performance. I have seen charts, but the build could break when performance degradation occurred. * Usefulness With C++11/C++14/C++17 template metaprogramming become a lot easier and a a lot of stuff might be written without need of TMP library at all. However, Hana is more than that, and I find it very useful. MPL and Fusions are/were extremely helpful and Hana is a huge step forward. *Frankly speaking, I would replace `std::tuple` with `hana::tuple` straight away.* - Did you attempt to use the library? If so: * Which compiler(s) Clang 3.6/Clang 3.7 + libc++ (on linux/mac/windows) -> worked fine Tried on GCC-5.1 (on linux) without any success -> didn't link, but this issue is well known already Tried on MSVC 2015-RC (just for a sake of trying -> didn't work ;) * What was the experience? Any problems? I haven't experienced any blockers whilst trying the library. The only problem for me, is lack of support for MSVC. A lot of commercial projects requires MSVC as much as Clang/GCC. - How much effort did you put into your evaluation of the review? I have been watching/trying Hana since April last year when I started to implement C++14 version of proposed boost.di library. I tried to re-implement C++03 version using Hana, but back then, Hana was crashing very often. Therefore, I decided to use plain C++14 features instead. I also went through all the source code/documentation/examples as well as played with the library. Thanks Louis for a great library! Kris

4 6

[type_traits] Another big update in develop
by John Maddock 20 Jun '15

20 Jun '15

Just a heads up in case it causes any issues: type_traits has had another big update in develop - added several new traits is_constructible, is_assignable etc which were needed to fix bugs in other traits - and changed most of the has_nothrow and has_trivial traits to make use of these. Also added more test cases to cover the issues where these were defective before. Please do let me know if you spot any unexpected breakages. John.

3 6

[hana] some notes, not a review
by Phil Endecott 20 Jun '15

20 Jun '15

Dear All, I have just a couple of notes about Hana; this does not constitute a review: Firstly, as I understand it Hana believes that it can replace much or all of what Fusion and MPL provide with a superior alternative. If that is the case, I suggest that the docs should not start out by describing Hana with reference to those libraries. At present, it would seem that in order to understand what Hana can do for me, I need to first learn at least a little about those other libraries - and then the Hana docs tell me how it compares to them. This might not be a bad thing in the context of docs for this review, but for "end user" documentation it should stand alone. Secondly, we're moving towards a future where a lot of what previously required TMP can now be done using "regular" C++ code qualified with constexpr. I've just replaced a fair chunk of my crufty old TMP code with constexpr and it is like a breath of fresh air. Against that background, it might be worthwhile to structure your examples by showing what Hana (and TMP in general, perhaps) can do that constexpr cannot do, i.e. start with an example using constexpr and extend it to add features not possible with constexpr. Regards, Phil.

6 6

Help with the wandbox online C++ compiler REST API please
by Niall Douglas 19 Jun '15

19 Jun '15

Dear Boost, I've been trying to get Krzysztof's wandbox script turning into a generic set of reusable tools for the Best Practices Handbook (specifically some Python which will generate a standalone single header include from any library, and generic scripting which can reduce that single header include to the smallest possible representation), but I have a problem which I have failed to surmount, so any advice most gratefully received: ned@jenkins64:~/boost.afio$ ./send_to_wandbox.sh + json_wandbox send_to_wandbox.cpp afio_single_include.hpp + echo -e -n '{ "code" : ' + json_escape send_to_wandbox.cpp + cat send_to_wandbox.cpp + python -c 'import json,sys,codecs; sys.stdout.write(json.dumps(codecs.getreader("ISO-8859-1")(sys.stdin). read()))' + echo -e -n ', "codes": [ { "file": "afio_single_include.hpp", "code": ' + json_escape afio_single_include.hpp + cat afio_single_include.hpp + python -c 'import json,sys,codecs; sys.stdout.write(json.dumps(codecs.getreader("ISO-8859-1")(sys.stdin). read()))' + echo -e '}], "options": "warning,boost-1.58,c++14", "compiler": "clang-head", "save": true }' + curl -v -F json_file=(a)json_input.json http://melpon.org/wandbox/api/compile.json * Hostname was NOT found in DNS cache * Trying 49.212.130.73... * Connected to melpon.org (49.212.130.73) port 80 (#0) > POST /wandbox/api/compile.json HTTP/1.1 > User-Agent: curl/7.35.0 > Host: melpon.org > Accept: */* > Content-Length: 243073 > Expect: 100-continue > Content-Type: multipart/form-data; boundary=------------------------c58a2396982a31f8 > < HTTP/1.1 100 Continue < HTTP/1.1 500 Internal Server Error * Server nginx/1.9.0 is not blacklisted < Server: nginx/1.9.0 < Date: Thu, 18 Jun 2015 23:56:48 GMT < Content-Type: text/html; charset=utf-8 < Transfer-Encoding: chunked < Connection: keep-alive < Status: 500 Internal Server Error < X-Powered-By: CppCMS/1.0.4 * HTTP error before end of send, stop sending < <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> <html> <head> <title>500 — Internal Server Error</title> </head> <body> <h1>500 — Internal Server Error</h1> </body> </html> * Closing connection 0 + [[ '' != '' ]] + echo ned@jenkins64:~/boost.afio$ Whatever I do, I get Internal Server Error from wandbox. Yet copying and pasting the files manually into the web UI works as expected. I am stumped. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

3 3

[Better Enums] Non-integral underlying types
by Anton Bachin 18 Jun '15

18 Jun '15

About a week ago, I generalized Better Enums somewhat to accept non-integral underlying types, with some conditions and restrictions. I’d like to ask for comments/opinions/ideas on this feature. I made a little write-up on it [1], but I will summarize here as well. The write-up is a superset of the content of this message, so don’t read the message if you click the link :) If you have a literal type “foo”, you can do: ENUM(SomeEnum, foo, A, B = 2, C = foo(…)) SomeEnum value = SomeEnum::A; switch(value) { case SomeEnum::A: // … case SomeEnum::B: // … case SomeEnum::C: // ... } The switch above can have its cases checked for exhaustiveness by the compiler. Also, “value” above behaves like a “container” for one value of type foo, whose members can be accessed using operator ->. So, basically, you can have enumerated, reasonably type-safe sets of arbitrary literal types. The catch is that you have to provide an invertible mapping from foo into some underlying integral type, which mapping is declared either by equipping foo with the right constructor and conversion operator, or specializing a traits template. I would love to make a default implementation for this mapping, but it seems like I need to achieve the effect of a reinterpret_cast at compile time, and I haven’t been able to do so. [1]: http://aantron.github.io/better-enums/GeneralUnderlyingTypes.html

1 0

Making lots of compile FAIL tests
by Paul A. Bristow 18 Jun '15

18 Jun '15

I've started to devise some tests to ensure that things that really should not compile, do in fact compile-fail. So far I've produced a few files with a single statement that should fail inside a int main(){}. But it's looking at though it will get pretty tedious pretty soon :-( (I see for example that Boost.Multiprecision has some 50-ish compile_fail items) Is there some slicker way of doing this? Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830

3 3

Re: [boost] [Boost-announce] [Boost] [Hana] Formal review for Hana next week (June 10th)
by Glen Fernandes 17 Jun '15

17 Jun '15

[Correction: 10th June is a Wednesdsay, not Monday.] Dear Boost community, The formal review of Louis Dionne's Hana library starts Wednesday, 10th June and ends on 24th June. Hana is a header-only library for C++ metaprogramming that provides facilities for computations on both types and values. It provides a superset of the functionality provided by Boost.MPL and Boost.Fusion but with more expressiveness, faster compilation times, and faster (or equal) run times. To dive right in to examples, please see the Quick start section of the library's documentation: http://ldionne.com/hana/index.html#tutorial-quickstart Hana makes use of C++14 language features and thus requires a C++14 conforming compiler. It is recommended you evaluate it with clang 3.5 or higher.[1] Hana's source code is available on Github: https://github.com/ldionne/hana Full documentation is also viewable on Github: http://ldionne.github.io/hana To read the documentation offline: git clone http://github.com/ldionne/hana --branch=gh-pages doc/gh-pages For a gentle introduction to Hana, please see: 1. C++Now 2015: http://ldionne.github.io/hana-cppnow-2015 (slides) 2. C++Con 2014: https://youtu.be/L2SktfaJPuU (video) http://ldionne.github.io/hana-cppcon-2014 (slides) We encourage your participation in this review. At a minimum, kindly state: - Whether you believe the library should be accepted into Boost - Your name - Your knowledge of the problem domain. You are strongly encouraged to also provide additional information: - What is your evaluation of the library's: * Design * Implementation * Documentation * Tests * Usefulness - Did you attempt to use the library? If so: * Which compiler(s)? * What was the experience? Any problems? - How much effort did you put into your evaluation of the review? [1] A note for Windows users: As mentioned, Hana requires a C++14 conforming compiler. If you would like to try it, a VM with Linux and clang 3.5 is a fairly painless option. Some users have also reported success with using Clang 3.5 on Windows. If you would like assistance configuring the former option, feel free to reach out to us for this. Best, Glen

4 4

[Hana] Migrating sqlpp11 to Hana (hypothetically)
by Roland Bock 17 Jun '15

17 Jun '15

Hi Louis, First of all: Hats off to you, your library and the documentation! I wanted to play with Hana for quite some time now. The review certainly offers a good reason to do so :-) Here's my test project: In sqlpp11 [1], lets assume I wanted to replace my own implementations of * compile time strings * type sets * functions like any/all/none with something from Hana. _Compile__time strings:_ This one seems easy. There probably won't be a C++14 version of sqlpp11, but there will be a C++17 version, hopefully allowing me to use the string literal without relying on a non-standard compiler extension. This is what I currently have [2]: struct _alias_t { static constexpr const char _literal[] = "delta"; using _name_t = sqlpp::make_char_sequence<sizeof(_literal), _literal>; }; This is what I would like to do: struct _alias_t { using _name_t = decltype("delta"_s); }; But the whole thing is in a header. * I do not want to "using namespace ::boost::hana::literals" at top-level or in one of the namespaces in the header. * Neither one of the following lines is valid: o using _name_t = decltype(::boost::hana::operator"_s"("delta")); o using _name_t = decltype("delta"::boost::hana::literals::operator"_s"); o using _name_t = decltype("delta"::boost::hana::literals::operator""_s); Is there a valid version? Obviously, I would also be happy with something like using _name_t = decltype(ct_string("delta")); * I also cannot use the BOOST_HANA_STRING macro, btw, because that would be a lambda in a decltype... I want to gradually migrate to Hana, so I'd really like to use a type here, not a variable. But I could not even use a variable, because the following does not compile (clang-3.5.1) struct A { static constexpr auto hana_name = BOOST_HANA_STRING("cheesecake"); }; Any hints? _ _ _type sets:_ Currently I store a bunch of types in type sets to do all kinds of tests at compile time. My type set code will need some cleanup or replacement one fine day. Hana to the rescue... Er, wait a second. There is no type set, or is there? There is a set for objects (which might represent types). Replacing all those types with objects would take some time, but I could live with that, I guess. But then I would have to replace all my type_sets (which are types themselves) with static constexpr objects, which use tons of constexpr template variables. And there are other constructs which use the types I now have replaced with objects. So I would have to adjust them, too, probably turning even more types into objects. Can I be sure (given today's compilers) that all these objects stay away from the generated binary? Also, I did not find some of the methods I would expect for sets: * Create a joined set * Create an intersect set * Create a difference set * Test if two sets are disjunct * Test if A is a subset of B, no, strike that, just found it in Searchable I probably could create the methods above with just a few lines of code using the available functions. But it would be convenient to have them available, of course (or did I just miss them?). By the way, I guess it would be easy for you to compile a list of available methods for each type, e.g. Set. Such a mini-index would be quite helpful IMO. _any/all/none: _Quite a bit of code is tuned to stuff like std::is_same: a type that contains a value (true or false). My current versions of any/all/none work like that, too. If I wanted to get rid of my own versions, could I use a drop-in from hana? Or would I have to write something like template<bool... B> struct my_all { static constexpr bool value = ::boost::hana::all(::boost::hana::make_tuple(B...)); }; ? _Intermediate summary:_ * I am not sure if I could replace my current compile-time string yet * I would like to have a few more convenience methods for Set. * It seems to me like if I wanted to use Hana, I should switch to Hana-style completely. Otherwise it will just be a weird mixture. Best, Roland [1]: https://github.com/rbock/sqlpp11 [2]: https://github.com/rbock/sqlpp11/blob/master/tests/Sample.h#L14-L17

4 9

[Boost] [Hana] Announcing Hana's formal review next week (June 10th)
by Fletcher, John P 17 Jun '15

17 Jun '15

Here is my review and some comments. > We encourage your participation in this review. At a minimum, kindly > state: > - Whether you believe the library should be accepted into Boost Yes please > - Your name John Fletcher > - Your knowledge of the problem domain. I have been working for some years on functional programming in C++. This is mainly run time work, but it inevitably has involved a lot of work on compile time issues as well. I am also involved in the maintenance of Boost Phoenix. Currently I mainly work to be C++03 compatible, but have done work on C++11 variadics. I am learning from this review how some of the features of C++14 can be deployed to advantage. > You are strongly encouraged to also provide additional information: > - What is your evaluation of the library's: > * Design I have not dug into the Hana code. Instead I have been attempting to adapt its code to work with some of my current examples. It seems to me to be consistent in its approach. > * Implementation I have not found any problems at all with the implementation. > * Documentation It is not always clear exactly which headers are needed for any given example from the manual. It is necessary to look at the example codes. I would like more information about some topics, e.g. monads and comonads. * Tests I have been adapting some of the tests to run with other codes. In particular I have been working with Boost Phoenix and Boost Bimap without any problems once the namespaces are adjusted. * Usefulness I think it is a very useful code for someone attempting to implement a higher level library. There are several things which can be done very easily with it and I am only scratching the surface at the moment. One example is to be able to detect a member function name() in a struct: auto has_name = hana::is_valid([](auto&& obj) -> decltype(obj.name()) { }); and then to be able to print the name if it is present, or do something sensible. // I want to output the name from name() if it is present. template <typename F> std::string print_name(F const& f) { if (has_name(f)) std::cout << "has_name(f) true : "; else std::cout << "has_name(f) false : "; return hana::if_(has_name(f), [](auto& x) { return x.name(); }, [](auto& x) { return std::string("no_name"); } )(f); } > - Did you attempt to use the library? YES > If so: > * Which compiler(s)? Clang 3.5 and 3.6 with libc++ running on Ubuntu 12.04 > * What was the experience? Any problems? No > - How much effort did you put into your evaluation of the review? I have spent some hours implementing examples and running them. John Fletcher _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

2 1

boost [fusion]: tests failing in develop branch
by Aparna Kumta 17 Jun '15

17 Jun '15

Several regression tests for develop branch fail today. http://www.boost.org/development/tests/develop/developer/output/oracle-spar… "../libs/fusion/test/algorithm/copy.cpp", line 8: Error: Could not open include file<boost/fusion/container/vector/vector.hpp>. "../libs/fusion/test/algorithm/copy.cpp", line 9: Error: Could not open include file<boost/fusion/container/list/list.hpp>. Is this known? Thanks, Aparna

2 1

Boost::Filesystem
by Amit Kumar 16 Jun '15

16 Jun '15

Hi All Is there any functionality in boost::filesystem to identify local drives on Linux box. I want something similar to windows API *GetDriveType*(). Regards Amit

2 1

Preliminary submission of Boost Synapse
by Emil Dotchevski 16 Jun '15

16 Jun '15

I've made changes to Boost Synapse (a signal programming library) in part based on feedback I received on the Boost mailing list, and I've uploaded the updated source code and documentation to github: http://zajo.github.io/boost-synapse/. There is also a new tutorial: http://zajo.github.io/boost-synapse/Tutorial.html. I welcome more feedback. Thanks, Emil Dotchevski <http://www.revergestudios.com/reblog/index.php?n=ReCode>

2 4

[config] Using SD-6 macros
by Edward Diener 16 Jun '15

16 Jun '15

I realize I may be late to the discussion, but what is the reason why Boost.config does not use the SD-6 macro functionality as the first check for all C11 and C14 related configuration options ? Is it because Boost.config feels that the few current SD-6 implementations are buggy ? As I understand SD-6 the implementation of SD-6 itself can always be checked effortlessly by an #if defined(__SOME_SD6_MACRO) before attempting to use the functionality defined by SD-6, so for the majority of compilers which do not implement SD-6 functionality yet Boost.config can always and easily fall back on its current checks. But for those compilers which do implement SD-6 ( latest clang and gcc 5.1.0 ) surely using SD-6 is easier than the many clever ways which Boost.config currently finds out how compilers and standard libraries are configured.

9 33

Re: [boost] boost [fusion]: tests failing in develop branch
by Lee Clagett 16 Jun '15

16 Jun '15

On Tue, Jun 16, 2015 at 3:57 PM, Aparna Kumta <aparna.kumta(a)oracle.com> wrote: > Several regression tests for develop branch fail today. > > > http://www.boost.org/development/tests/develop/developer/output/oracle-spar… > > "../libs/fusion/test/algorithm/copy.cpp", line 8: Error: Could not open > include file<boost/fusion/container/vector/vector.hpp>. > "../libs/fusion/test/algorithm/copy.cpp", line 9: Error: Could not open > include file<boost/fusion/container/list/list.hpp>. > > Is this known? > > > Thanks, > > Aparna > > Yes, a pull request [1] was merged that was marked as a WIP. Another pull request [2] has already been made. The new pull request re-introduces those files - they were moved in [1], and [2] adds them back with new a new header that includes the original (now moved) files. Kohei Takahashi is eventually trying to replace the pre-processor based variadics with true variadics when compilers support it [3]. Joel or Kohei would have to provide more specifics on that effort, but it will be interesting if any compilation time improvements result (hopefully!). Lee [1] https://github.com/boostorg/fusion/pull/80 [2] https://github.com/boostorg/fusion/pull/81 [3] https://github.com/boostorg/fusion/pull/57

1 0

[hana] Review
by edouard＠fausse.info 16 Jun '15

16 Jun '15

Dear all, Please find attached my review of Hana. > - Whether you believe the library should be accepted into Boost > * Conditions for acceptance Definitely yes. I just have a very minor remark considering the documentation. > - Your name Edouard Alligand > - Your knowledge of the problem domain. I have been writing C++ professionally for 15 years and done a lot of TMP for many software project, for things such as compile-time introspection for serialization, enhanced checks at compile-time to improve correctness and compile-time pre-computations. I've done that with Boost.MPL, Boost.Fusion and some custom MPL. > You are strongly encouraged to also provide additional information: > - What is your evaluation of the library's: > * Design I am very much impressed by the design of Hana and the cleverness of the usage of C++ 14 lambdas. > * Implementation As far as I can judge it is very well implemented. > * Documentation I think writing "using namespace boost::hana" for the documentation is confusion. I know it might be nit-picking, but I think the example is easier to understand when you read struct Fish { std::string name; }; struct Cat { std::string name; }; struct Dog { std::string name; }; auto animals = boost::hana::make_tuple(Fish{"Nemo"}, Cat{"Garfield"}, Dog{"Snoopy"}); instead of struct Fish { std::string name; }; struct Cat { std::string name; }; struct Dog { std::string name; }; auto animals = make_tuple(Fish{"Nemo"}, Cat{"Garfield"}, Dog{"Snoopy"}); Because if you read diagonally (and let's be realistic, we all read diagonally documentation) you might miss what is going on. At least some namespace alias would be helpful. I personally think redundancy is good in documentations. > * Tests There is a satisfactory number of tests and the developer does continuous integration. The developer tests on several compiler versions at every change which is a must for a MPL. > * Usefulness Boost.Hana is extremely useful, especially the compile-time introspection it adds. It uses macros but as long as the language doesn't provide features to do compile-time introspection, there is no way around this (that I can think of) It has a lot of algorithms out of the box (at least I couldn't find one I would need that was missing). I like the compile-time arithmetic part of the library and find it very convenient. I'm a big fan of Boost.Fusion and I use Boost.MPL a lot. Hana replaces both libraries and compiles faster at the cost of requiring recent compilers. It is, to me, a very acceptable tradeoff. > - Did you attempt to use the library? If so: > * Which compiler(s) Clang 3.5 on FreeBSD 10.1 and libc++ > * What was the experience? Any problems? The only problem I have with Hana is that it doesn't work with Visual Studio. The lack of VS is the only reason why we didn't adopt Hana on our product. Nevertheless, I don't think it a showstopper. Hana is an advanced MPL and the problem will solve by itself with time. It works, in my opinion, on a sufficient number on platforms at the moment to be accepted into Boost. > - How much effort did you put into your evaluation of the review? I ran by the examples again as I would if I were trying the library for the first time. I have been following Boost.Hana since Louis' presentation at last year cppcon in Bellevue, Wa. Kind regards. --Edouard

2 1

different Problem cross-compiling against boost.context for Raspberry Pi (2)
by Biddiscombe, John A. 16 Jun '15

16 Jun '15

When compiling HPX against the now built boost, I have this error message /home/biddisco/apps/boost-1_58_0/include/boost-1_58/boost/context/execution_context.hpp:202:52: error: âstd::index_sequenceâ has not been declared std::index_sequence< I ... >) { index_sequence appears to be c++14, I'm using -std=c++11, can one tell if this likely a mistake on my part somewhere, or a possible problem with boost.context? (Is there a BOOST_FLAG_SOMETHING, I should add to prevent t being used?) thanks JB

2 3

[Advice] Documenting the "refined by" relation for concepts
by Louis Dionne 15 Jun '15

15 Jun '15

Dear all, When documenting a concept in a generic library, it is common to include what this concept is a "refinement of", i.e. which other concept(s) it specializes. For example, see the ForwardContainer concept from the SGI STL [1], which is a refinement of the Container concept. I find documenting this relation very useful. However, I have never seen the reverse relation of being "refined by" documented. It has been suggested to me [2] that Hana should document this "refined by" relation. Having never seen it done before, I'd like to know what the seasoned generic library writers think about it. The possibilities I personally see are 1. It's just not useful, and that's why it's not done 2. It's actually harmful, because you can't predict who is going to refine a concept 3. There's no "logical" reason behind this, it just happened to work that way in the SGI STL and everybody else followed that lead. Any input is appreciated. Regards, Louis [1]: https://www.sgi.com/tech/stl/ForwardContainer.html [2]: https://github.com/ldionne/hana/issues/104

5 10

Genetics library - advice needed.
by Andy Thomason 15 Jun '15

15 Jun '15

Hi All, I am getting close to rolling out the first draft of our genetics library. https://github.com/andy-thomason/Boost.Genetics This library allows you to search gene sequences - most commonly the human genome - (eg. ENSEMBL .fa files) for inexact matches. At present the library emphasises thoroughness over performance but the latter will improve. The algorithms are all single-threaded at present as the user should provide the thread control. Feedback would be useful. I appreciate that this is still a little way from being a final submission, in particular we need: * documentation * more examples (currently only a python binding example) * more tests I'll be setting these as a task for my students. Don't expect it to build and run out of the box except for the unit tests and they might not wor in 32 bit builds. I'd also apreciate help with the build system as getting a build on 64 bit windows is a challenge for Boost.Python at present and some wisdom would go far. Are there plans for VC2013/15 solution generation from BJAM? That would be useful. Is there a continuous integration system we could use to pre-check the library? Andy. --- This email is free from viruses and malware because avast! Antivirus protection is active. https://www.avast.com/antivirus

5 7

[Graphs] Bug in directed edge-connectivity algorithm
by Michele Borassi 15 Jun '15

15 Jun '15

Dear all, my name is Michele Borassi, and I am a user of Boost Graph library, version 1.58.0. I have found a problem in the edge connectivity algorithm: if the input is a directed path with 3 vertices (0, 1, 2) and 2 edges ((0,1), (1,2)), the output is 1 (while it should be 0, since the graph is not strongly connected). However, if edge (1,0) is added, the output becomes (correctly) 0. A minimal working example that shows this issue is attached; my output is: Path of 3 vertices and 2 edges. The edge connectivity is 1. Added edge (1,0): now there are 3 edges. The edge connectivity becomes 0. Could you also explain me which is the best way to report a bug? I have checked your web page http://www.boost.org/development/bugs.html, but all links seem to be broken. Waiting for your answer, I thank you in advance, Michele Borassi

4 5

[Better Enums] More complete release - feedback requested
by Anton Bachin 15 Jun '15

15 Jun '15

Hello, I posted to the mailing list some weeks ago concerning a reflective enum library. I’ve since done a lot of work and made a new release. I’d like to get feedback from anyone that is interested. The library can be found at: https://github.com/aantron/better-enums At the risk of repeating myself, let me summarize for those who didn’t read the original thread: the library generates reflective enums that support string conversion and iteration, but with a nicer syntax than seen to date. Also, in C++11, the reflective capabilities are accessible at compile time. Since the original thread, I have made the library work with C++98 with the variadic macro extension, tested it thoroughly on clang, gcc, and msvc, rewrote the documentation, and made the interface (potentially) completely constexpr. The reason I say potentially is that there is one slow feature, which is disabled by default, but can be opted into easily. There is a tutorial starting here: http://aantron.github.io/better-enums/tutorial/HelloWorld.html and a few examples of “advanced” usage, the most interesting one of which I think is: http://aantron.github.io/better-enums/demo/SpecialValues.html (Thanks to Gottlob Frege for making a suggestion, which I adapted to improve this example.) I’d like to take this as far as possible towards solving the problems with C++ enum maintainability, and providing improved enum types that are as near to first-class as possible. I would be very happy if you just tried this out and let me know what you think and what problems you ran into. Thank you, Anton

6 27

a thread pool that allows recursive calls
by Frédéric Bron 13 Jun '15

13 Jun '15

Dear boosters, I need to perform some tasks in parallel and want to control the number of CPUs that are used. A threadpool seems to be what I want and http://threadpool.sourceforge.net/ looks good. However, my tasks may also want to launch some parallel sub-tasks and the sub-tasks may also want to launch tome parallel sub-sub-tasks... and this is not possible with this implementation of threadpool. I have programmed something that works and I wonder if anyone had also already done that because my implementation is very rudimental for now and if something already exists I do not want to reinvent the wheel. Having said that, if there is nothing publicly available (I mean open-source), do you think it would be valuable I share what I did and make it available to boost as a library? This would require some advices/reviews from thread experts and a lot of work from me but I would be happy to contribute. Kind regards, Frédéric

4 5

Heterogeneous Container Library (HCL) Feedback and Testing
by James Armstrong 13 Jun '15

13 Jun '15

I send out a little feeler about a month ago for interest in a container library which natively allows users to insert a heterogeneous set of types. After getting some really good feedback, I think I have settled into something that is efficient, has a nice clean interface, and provides some useful capabilities. I am hoping people can take a look at the code, test it out, and provide an additional feedback in terms of interface, implementation, bugs, or additional features/classes that would be useful. I have implemented a set of containers which mimic the capabilities of the STL containers. These are (so far) * heterovector * heterostack * heteroqueue * heterolist * heteroforward_list * heterodeque These containers were implemented using variadic templates and were somewhat inspired from the posts of Joaquín Muñoz. http://bannalia.blogspot.com/2014/05/fast-polymorphic-collections.html http://bannalia.blogspot.com/2014/05/fast-polymorphic-collections-with.html In addition, I have an adaptor class which provides a simple interface for accessing data of a specific type from a container of type_erased objects (boost::any, boost::variant, etc). The code is hosted at https://github.com/armstrhu/HCL and the directory structure there should be simple to navigate. There is an include directory which contains the header files needed, and an examples directory which provides examples for using the containers and the adaptors. As they mimic the STL containers, once you see how to use them (basically just provide an additional template parameter) you should be able to use them smoothly. One note is I focused mainly on developing the heterovector class, and the remainders are primarily copies of that class where std::vector has been replaced with std::deque, std::list, etc, and associated methods added/removed as needed. I have primarily tested with the heterovector, so having people check out the other classes would be nice :) Any and all feedback is much appreciated. Thanks! -- James Armstrong

7 18

[Geometry] Wrong results for dissolve Polygon
by Andreas Wimmer 12 Jun '15

12 Jun '15

Dear Boost Geometry Contributors, I am testing the boost::geometry::dissolve function upon some invalid polygons that are produced by a certain in-house segmentation alg. The fact that the algorithm is producing possibly invalid polygons cannot be changed easily so I thought I will fix them afterwards using dissolve from “geometry/extensions/algorithms/dissolve.hpp” for the latest boost 1.58 version. Unfortunately I stumbled over the following polygons for which dissolve produces wrong results. The following code illustrates the result using namespace boost::geometry; using namespace boost::geometry::model; using namespace boost::geometry::model::d2; int main(int argc, _TCHAR* argv[]) { polygon< point_xy<float> > Poly; read_wkt("POLYGON((10 10, 10 20, 20 20, 15 12, 15 18, 20 10, 10 10))", Poly); multi_polygon< polygon< point_xy< float > > > Dissolved; boost::geometry::dissolve(Poly, Dissolved); } Which results in a polygon including the small intersection part which should be excluded from the polygon And even more problematic the following example (same polygon with and additional self-touching outer ring) results in missing the entire main part of the polygon int main(int argc, _TCHAR* argv[]) { polygon< point_xy<float> > Poly; read_wkt("POLYGON((10 10, 10 20, 20 20, 20 25, 22 25, 20 20, 15 12, 15 18, 20 10, 10 10))", Poly); multi_polygon< polygon< point_xy< float > > > Dissolved; boost::geometry::dissolve(Poly, Dissolved); } I hope somebody can show me what I did wrong or what I can to too work around this problem. Best regards, Andreas Wimmer

2 1

Appveyor
by Mathieu Champlon 12 Jun '15

12 Jun '15

Hello, I've seen it mentioned a few times on the mailing list. Can anyone point me to a boost library (or a library which makes use of boost) which builds on appveyor ? A find for appveyor.xml in the boost/libs directory does not yield anything and I couldn't find a way to search for projects on appveyor itself... Thank you ! MAT.

3 4

[status] How should boost/status master be updated?
by Adam Wulkiewicz 11 Jun '15

11 Jun '15

Hi, Some time ago I prepared a PR for develop version of boost/status. Now I'd like to propagate the changes to master. How should I do that? I saw that there are some changes made only in develop and other only in master. Some commits were cherry-picked. What should be the practice in this case? Shouldn't status be made a separate module? It'd greately simplify the synchronization of branches. Regards, Adam

1 0

[boost.lockfree] spsc_queue read/write_available
by Philip Bennefall 11 Jun '15

11 Jun '15

Hi all, I am debugging a crash that I am getting inside of the pop method in spsc_queue from boost.lockfree. I am not sure exactly what is happening yet, but I do have one question. I call read_available and write_available a few times, and am wondering why read_available can only be called from the producer thread and why write_available can only be called from the consumer thread? Wouldn't it make sense to call read_available from the consumer, and write_available from the producer? Why is it the other way around? Currently I call write_available from the thread that pops, and read_available from the thread that pushes. Did I interpret the documentation correctly? If so, some clarifications would be much appreciated. Thanks! Kind regards, Philip Bennefall

2 2

sourceforge and release hosting
by Adam Walling 11 Jun '15

11 Jun '15

Should releases be hosted somewhere other than sourceforge? I've ran across this regarding boost twice this week, and I'm sure we are all well aware of the history of problems that sourceforge has been accumulating. Personally I think twice now every time I happen upon sourceforge, and despite being a source target than binary release, I can't help but be disturbed by these recent events. And I certainly don't want boost associated. Are there any strong feelings among us here regarding this?

7 10

[BestPracticeHandbook] Try the library online
by Krzysztof Jusiak 10 Jun '15

10 Jun '15

Hi, I've recently added a new badge (try boost.di | online) to proposed boost.di library. It uses Wandbox (awesome) facilities to check the library using online compiler (Wandbox supports newest gcc/clang). IMHO this approach is really useful for reviews and new users, since they don't have to install anything, just click the link and its done. They can experiment and then if they like it, clone the library and explore it more. You can check the badge here: http://krzysztof-jusiak.github.io/di/cpp14/boost/libs/di/doc/html And, for inpatients, direct link to online compiler with the library: http://melpon.org/wandbox/permlink/O3ABWKU3VBV3WG8J Let me know, what do you think. Cheers, Kris

2 2

[Config] Support for switching between std:: and boost:: equivalents.
by John Maddock 10 Jun '15

10 Jun '15

There is a pull-request for Config to provide support for switching between boost:: and std:: library equivalents: https://github.com/boostorg/config/pull/63 My questions are: * Is this the right approach? And, * Is Boost.Config the right place for it? Thanks for your comments, John.

10 53

Interest in B-Tree and B+-Tree Implementation?
by Timo Bingmann 10 Jun '15

10 Jun '15

Hello people, I want to ask if there is an interest in adding an in-memory B+-Tree container implementation that I wrote some time ago: https://github.com/bingmann/stx-btree http://panthema.net/2007/stx-btree/ It emulates the std::set/map/multiset/multimap interfaces as far as possible (there are some unavoidable minor exceptions). And since I keep telling my collegues to stop using std::map for bigger instances, I think adding it to Boost would be a good idea. So ... I could clean up my old implementation, add C++11/Boost move semantics, use of uninitialized objects, boostify various things, etc, etc, and then things should be pretty fine. I also have an idea to modify/fork the implementation to create a B-tree (non-plus) container, which should be a bit slower, but provide an interface even closer to std::map (only remaining unavoidable incompatibility would be with iterator invalidation). My main question before starting this is whether it is a better idea to add it to Ion's existing Container library, or to add it as a separate "library" under Boost like the existing circular_buffer, which is pretty old. Apparently libraries have gotten bigger over Boost's life. So which variant would be better? The "Container" library seems to be more targeted at reimplementing STL containers with new features, and simple new containers, not complexer ones? But it should still be a good match. In the incubator I found the "STL Extensions" submission, which appears to be dead. It aims to provide "augmented array based B+ trees", which is different from the usual trees where nodes are dynamically allocated. Best Regards, Timo Bingmann

4 5

[regression] Displaying test categories in the regression matrix
by Adam Wulkiewicz 09 Jun '15

09 Jun '15

Some time ago I defined the categories for tests in Geometry in the explicit-failures-markup.xml file in develop: https://github.com/boostorg/boost/pull/80/files What I'd like to achieve is a matrix similar to the Chrono's one: http://www.boost.org/development/tests/develop/developer/chrono.html However after merging the PR there are no categories in the Geometry matrix. Am I doing it in the correct way? Which version of the explicit-failures-markup.xml is used by the report program, from the develop or master branch? Or maybe must the file be manually placed somewhere? Regards, Adam

1 0

[hana]Either generalization & missing variant
by Larry Evans 09 Jun '15

09 Jun '15

The page: http://ldionne.com/hana/structboost_1_1hana_1_1Either.html contains: An Either contains either a left value or a right value, both of which may have different data types. An Either containing a left value a is represented as left(a), and an Either containing a right value b is represented as right(b). which makes anyone familiar with boost::variant to think that hana's Either is simply a binary boost::variant, and left(a) ~=~ variant<A,B>(a) right(b) ~=~ variant<A,B>(b) where ~=~ means some sort of similarity. However, since the left and right functions only have 1 argument and no template arguments, they can't produce something like variant<A,B> where the left and right types are known. IOW, it seems that left and right are just wrapper's around the types. Looking at the code, the wrappers, _left and _right are defined here: https://github.com/ldionne/hana/blob/master/include/boost/hana/either.hpp#L… https://github.com/ldionne/hana/blob/master/include/boost/hana/either.hpp#L… But why should Either be limited just to _left and _right wrappers. Why not provide wrapper's tagged by some enumerable? For example, something like this: template < typename X , typename Enumerable=unsigned , Enumerable tag=Tag() > struct _tagged //instead of _left and _right : operators::adl { X value; . . . template <typename... F> constexpr decltype(auto) go(F...&& f) const& { return (hana::arg<unsigned(tag)>(f...))(value); } . . . }; This would be more general than the binary Either. In addition, _tagged could be used elsewhere. For example, it could be used in a multiple inheritance implementation of tuple. _tagged is already present in a more general form, in fusion: http://www.boost.org/doc/libs/1_39_0/libs/fusion/doc/html/fusion/support/pa… where: _tagged<X,0> ~=~ fusion::pair<int_<0>,X> The obvious advantage of Either is that it doesn't require memory use equal to the max of the components when the component with the minimum size is used. IOW, left(a) only requires sizeof(A) and right(b) only requires sizeof(B). OTOH, Either, or the generalization described above, can't be used where a true variant is needed, for example, in spirit's attributes for the alternative parser. And this brings up another question. Although hana has a tuple, it doesn't have a variant. Is there any reason for excluding variant from hana? -regards, Larry

4 8

[metaparse] Review period starts May 25th and ends June 7th - ongoing
by Christophe Henry 09 Jun '15

09 Jun '15

Dear all, The review of the metaparse library started last Monday. Please consider taking the time to review it and post comments or reviews on this list. Thanks, Christophe ------------------------------------------------------------------------------------------ Dear all, The review of the Metaparse library starts next Monday, May 25th and ends June 7th. Metaparse was written by Abel Sinkovics. Metaparse is a parser generator library for template metaprograms. The purpose of this library is to support the creation of parsers that parse at compile time. This library is intended to be used for embedded domain specific language creation for C++ and can help libraries provide a better interface. It is similar to Boost.Spirit, however while parsers built with Spirit parse at run-time, parsers built with Metaparse parse at compile-time. It makes it possible for library authors to provide an interface that follows the common notation of the problem domain of the library. (eg. SQL queries, grammars, etc written in their common notation instead of similar-looking C++ expressions). For example there is a (yet incomplete) interface for Boost.Spirit that makes it possible to write MPLLIBS_REGEX("^[abcd][3-8]\\.foo$") instead of bos >> set[as_xpr('a')|'b'|'c'|'d'] >> range('3','8') >> '.' >> 'f' >> 'o' >> 'o' >> eos and make the parser built with Metaparse generate the latter expression from the former one. (It can be found here: https://github.com/istvans/mpllibs/tree/master/libs/xlxpressive) Since the library is based on template metaprogramming, the DSLs can be used for type validation as well. This is demonstrated by the type-safe printf implementation ( http://abel.web.elte.hu/mpllibs/safe_printf/index.html) It type-checks the arguments of a printf call based on the format string and has zero runtime overhead compared to unchecked printf. Parsers can be constructed in a declarative manner and (even though this is template metaprogramming based) remain readable. The implementation reflects the grammar it parses (with additional elements for semantic actions). Even though the library requires the parser author to write template metaprograms, the development of parsers is well supported by tools like Metashell and MDB. An important aspect of parsers (built with this library or another one) is error reporting for invalid input. The library offers tools for the parser authors to be able to provide useful error messages in case of parsing errors. Here is an example error report by a parser built with Metaparse (the parser can be found in the Getting Started guide of the library): ..... x__________________PARSING_FAILED__________________x<1, 5, unpaired<1, 1, literal_expected<')'>>> .... It is an error report letting the developer know that a closing paren is missing at line 1, column 5 and the unclosed opening paren is in line 1, column 1. Metaparse can be downloaded from Github: https://github.com/sabel83/mpllibs/tree/master/mpllibs/metaparse And a very complete tutorial: http://abel.web.elte.hu/mpllibs/metaparse/getting_started.html The tutorial also offers the nice feature of a link to metashell for quick-starting trying out the library: http://abel.web.elte.hu/shell/metashell.html 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… Everybody on this list is invited to participate in this formal review. I hope to see your review of Metaparse, including your vote on acceptance, and I welcome your participation in the ensuing discussions on the Boost developers' mailing list. Please always include in your review a vote as to whether the library should be accepted into Boost. Additionally please consider giving feedback on the following general topics: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? - With what compiler? - Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? Regards, Christophe Review Manager

9 28

Github and forks
by Edward Diener 08 Jun '15

08 Jun '15

My use case is: I want to create a Github PR request against a Boost submodule repository. I then want to create a separate Github PR request against the same Boost submodule repository. I understand the Github mechanism of forking a repository and creating a PR request. For some reason which I do not understand Github will not allow their online forking mechanism to fork the same repository more than once to different names within a user account. In other words if I fork a Boost submodule repository to my user account, rename the repository, and then fork the same Boost repository to my user account again it will just update the renamed repository rather than create a new forked repository again. Considering that Github allows any repository you can find there to be forked to your user account, can anybody think of why Github will not allow the same repository to be forked twice to different repositories ? Of course I can get around this Github forking limitation by creating a new Github repository in myn user account, cloning an existing Github repository locally, and then pushing that cloned repository to my new Github repository. That will create two different repositories off of the same Github repository in my user account. But in this case I can't use the online PR mechanism on this second repository against the original Github repository.

3 3

Dependency report for develop-8fa72a7
by Peter Dimov 08 Jun '15

08 Jun '15

The latest dependency report, which reflects the new "version 2" type traits, is here: http://pdimov.com/tmp/report-develop-8fa72a7/module-overview.html http://pdimov.com/tmp/report-develop-8fa72a7/module-levels.html http://pdimov.com/tmp/report-develop-8fa72a7/module-weights.html

1 0

[Boost-announce] [metaparse] Review period starts May 25th and ends June 7th
by Christophe Henry 08 Jun '15

08 Jun '15

Dear all, The review of the Metaparse library starts next Monday, May 25th and ends June 7th. Metaparse was written by Abel Sinkovics. Metaparse is a parser generator library for template metaprograms. The purpose of this library is to support the creation of parsers that parse at compile time. This library is intended to be used for embedded domain specific language creation for C++ and can help libraries provide a better interface. It is similar to Boost.Spirit, however while parsers built with Spirit parse at run-time, parsers built with Metaparse parse at compile-time. It makes it possible for library authors to provide an interface that follows the common notation of the problem domain of the library. (eg. SQL queries, grammars, etc written in their common notation instead of similar-looking C++ expressions). For example there is a (yet incomplete) interface for Boost.Spirit that makes it possible to write MPLLIBS_REGEX("^[abcd][3-8]\\.foo$") instead of bos >> set[as_xpr('a')|'b'|'c'|'d'] >> range('3','8') >> '.' >> 'f' >> 'o' >> 'o' >> eos and make the parser built with Metaparse generate the latter expression from the former one. (It can be found here: https://github.com/istvans/mpllibs/tree/master/libs/xlxpressive) Since the library is based on template metaprogramming, the DSLs can be used for type validation as well. This is demonstrated by the type-safe printf implementation ( http://abel.web.elte.hu/mpllibs/safe_printf/index.html) It type-checks the arguments of a printf call based on the format string and has zero runtime overhead compared to unchecked printf. Parsers can be constructed in a declarative manner and (even though this is template metaprogramming based) remain readable. The implementation reflects the grammar it parses (with additional elements for semantic actions). Even though the library requires the parser author to write template metaprograms, the development of parsers is well supported by tools like Metashell and MDB. An important aspect of parsers (built with this library or another one) is error reporting for invalid input. The library offers tools for the parser authors to be able to provide useful error messages in case of parsing errors. Here is an example error report by a parser built with Metaparse (the parser can be found in the Getting Started guide of the library): ..... x__________________PARSING_FAILED__________________x<1, 5, unpaired<1, 1, literal_expected<')'>>> .... It is an error report letting the developer know that a closing paren is missing at line 1, column 5 and the unclosed opening paren is in line 1, column 1. Metaparse can be downloaded from Github: https://github.com/sabel83/mpllibs/tree/master/mpllibs/metaparse And a very complete tutorial: http://abel.web.elte.hu/mpllibs/metaparse/getting_started.html The tutorial also offers the nice feature of a link to metashell for quick-starting trying out the library: http://abel.web.elte.hu/shell/metashell.html 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… Everybody on this list is invited to participate in this formal review. I hope to see your review of Metaparse, including your vote on acceptance, and I welcome your participation in the ensuing discussions on the Boost developers' mailing list. Please always include in your review a vote as to whether the library should be accepted into Boost. Additionally please consider giving feedback on the following general topics: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? - With what compiler? - Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? Regards, Christophe Review Manager

23 76

Correct spelling of "suppress"
by Alex Henrie 08 Jun '15

08 Jun '15

Hi, Could you guys take a look at these two pull requests? https://github.com/boostorg/assign/pull/9/files https://github.com/boostorg/iostreams/pull/12/files I thought they would be uncontroversial, but it has been months and they have still not been merged. -Alex

1 0

Boost.Container and tests: why is Boost.Test bypassed
by Thorsten Ottosen 08 Jun '15

08 Jun '15

Hi Ion, I have a GSOC student writing some containers that fit naturally into Boost.Container. So he tries to do things the way that you have done, which is fine. I do wonder why the tests are written with assertions and not using Boost.Test? Is it a dependency problem or? Thanks -Thorsten

7 12

What would make tool authors happier..
by Rene Rivera 08 Jun '15

08 Jun '15

Warning.. Some of this may sound contentious at times.. But that's life ;-) There are a number of disparate discussions going on at the moment that can be summarized as: * A tool author suggesting a change (to structure, or process, or something else) that would make writing tools easier and less error prone. * Lots of responses about how such a change would be disruptive to current practices. * Some responses about how such a change is beneficial to the future of Boost, its growth and possible real modular future. * Some more responses about how the tool authors should just account for all the special cases of the current practices and still bring about the vaunted modular future. So I want to summarize some key changes, as I understand them, that I think will make movement towards a better tooling and development future less painful for the minuscule minority of the people who write the tools that aim to bring that future into existence. First the key aspects of the changes are: 1. Normalized and regular directory structure of libraries, tools, and root. 2. Minimal non-library content and structure. 3. Stricter rules and guidelines for library authors to follow regarding the needs of the infrastructure tools. Some of the specific changes some of us have mentioned that touch on the above aspects are.. * Making the combined library headers go into boost-root/include. See separate post from Peter Dimov about this. This touches on #1 as it makes for a user and tool expected location. That is, users are accustomed to looking for a top level include. And having such a location would reduce the documentation and instruction needed to point them away from their intuitive behavior. External tools also expect to find such a directory for a library, which is what a monolithic Boost looks like to tools. Hence it would make it easier to use, incorporate, author, etc tools. * What I've mentioned as "flattening" of libraries. Which touches on #1 and #3 above. This has multiple parts/meanings so let me explain each one separately. First, it means is banning of git sub-modules outside of directly under boost-root/libs and boost-root/tools. Dealing with git sub-modules is difficult enough even when it's just a handful of sub-modules. But dealing with the 130 sub-modules we have now is an insanity inducing experience when there needs to be handling for special locations. Currently the only culprit of this is "libs/numeric". And I understand that it was done this way because that was the old structure converted to the modular git form. But I think it's time to truly abandon the old structures as they are standing in the way of better tools and user experience. As an example of user experience, I once tried to set up my own subset of Boost as a git repo that had all the libraries and tools needed for the documentation toolchain. It was excruciating to manually discover what all those libraries where particularly because of no initially knowing about this aspect of our current sub-modules. Second, it means formalizing and regulating the top level structure of libraries. For the longest time we've had an accepted top level structure. Unfortunately library authors have added to that top level structure. For example to manage "sub-libraries" or "sub-parts" of their library... Which is understandable. But it makes life more difficult for the tools that rely on the structure assertions. For example currently the testing scripts rely on people updating a single listing file at "boost-root/status/Jamfile.v2". When in an ideal world the test tools would be able to automatically discover that information. Practically it means that currently that Jamfile lists 127 test dirs. But a cursory discovery of test dirs goes up to a possible 197. As far as following the top-level library structure.. There are currently 279 files and directories at the library top level that are not in the accepted set (and I'm already excluding things like readmes and changelogs, even though changelogs should be in docs). But do note.. That I'm not suggesting that we immediately ban the old structure. But that we start discussing what are the needs of library authors and that we come up with a consistent and enforced structure that can relied upon by users and tools. Some changes that may be the first time I bring them up.. * Remove as much as possible from boost-root. This is mostly #2 above. First, I would like to remove the "boost-root/more" directory. Stuff in it are docs of various kinds and should be placed in "boost-root/doc", in the website, in tool docs, or in library docs. While doing that I'm sure we will likely also rewrite/clean-up those documents to better reflect the present. Second, I would like to move as many of the root build files to a "boost-root/build" directory. Ideally they would all be moved but it may not be possible, and practical, to do so. This would mirror the general top-level structure and hence make it a bit more intuitive for new authors and users to find. Third, I would like to clean up the various CSS and HTML sources at the root to either a smaller number (do we really need index.htm *and* index.html?), or to the doc directory. I know.. This isn't exactly in the vein of what makes it easier for tool developers. But it does make it easier for users to initially navigate (because there's less noise for them to look at). Last, I would like to re/move the "boost-root/status" directory. Two options I'm considering are moving to be "boost-root/test" to match the usual name for testing scripts. Or removing it and replacing it logic in the regression tools that is equivalent (i.e. move the functionality to the separate regression git repo). I believe that all those changes will help in moving us toward what I'm starting to call a "comprehensive" Boost release. Such a release would not follow the monolithic structure we currently have of needing the big include directory. But instead would be a plain collection of the individual libraries and tools that users can enable/install from the comprehensive package they download. Or possibly use directly if they add the individual libraries to their project search (and obviously build for the ones that need it). Such a "comprehensive" release would make the release process, and the tools driving it, a much simpler process and almost certainly increase the frequency of comprehensive release (possibly even to an almost weekly or daily occurrence). Last note.. It's never too late to fix problems even if there's work needed to adjust to the fixes. After all, programmers are accustomed to change. We deal with it and move on. So if we can make changes that reduce our future pain, we should do those changes. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

9 38

[testing][regression] Heads up: compilation warnings are available for passing tests.
by Adam Wulkiewicz 08 Jun '15

08 Jun '15

Hi, For passing tests which are expected to pass, if warnings are generated during the compilation they can be seen after clicking on the "pass" link. If the link isn't there it means that there were no warnings. I hope it will allow us to improve the quality of the libraries even more. Regards, Adam

4 10

[winapi] Problem with the latest clang on Windows
by Edward Diener 08 Jun '15

08 Jun '15

Updates to clang on Windows have broken the use of clang with the [winapi] library. I do not know if this has occurred in the past but it seems to have occurred recently when I build the latest clang from source and use it on Windows to compile build Boost libraries which use the internal winapi library. Preprocessing clang and gcc output for a given call in the Boost winapi library and in the corresponding mingw windows.h shows that both compilers view the same source but treat them differently. As an example let's look at the GetSystemTimeAsFileTime call. The preprocessed source for both clang and gcc shows: In the Boost winapi it is: __attribute__((dllimport)) void __attribute__((__stdcall__)) GetSystemTimeAsFileTime(FILETIME_* lpFileTime); In the mingw/gcc windows.h it is: void __attribute__((__stdcall__)) GetSystemTimeAsFileTime(LPFILETIME); where the FILETIME_ and LPFILETIME are the same. When gcc sees these two declarations in the two different headers it says everything is OK. When clang sees these two declarations in the two different headers it gives an error: In file included from test_winapi.cpp:9: In file included from /mingw/include\windows.h:62: /mingw/include\winbase.h:1397:24: error: conflicting types for 'GetSystemTimeAsFileTime' WINBASEAPI void WINAPI GetSystemTimeAsFileTime(LPFILETIME); ^ ..\..\..\boost/detail/winapi/time.hpp:70:9: note: previous declaration is here GetSystemTimeAsFileTime(FILETIME_* lpFileTime); ^ For this line in boost/detail/winapi/time.hpp __declspec(dllimport) void WINAPI GetSystemTimeAsFileTime(FILETIME_* lpFileTime); It seems like the fix for clang is to leave out the __declspec(dllimport) portion of all these Boost winapi calls while leaving it in for everybody else. I am discussing this on the clang developers mailing list but it seems like they are pretty adamant that if they see __attribute__((dllimport)) in from of a function declaration and do not see it in front of another function declaration, despite the rest of the signatire being the same, the two declarations are not the same function being declared and therefore an error because of ODR.

7 28

[hana]missing link on http://ldionne.com/hana/index.html#tutorial-integral
by Larry Evans 07 Jun '15

07 Jun '15

The link with name: boost::hana::literals takes my browser to: http://ldionne.com/hana/namespaceboost_1_1hana_1_1literals.html which my browser (firefox) displays with: Louis Dionne Programming and Categories, Oh My! 404: Page not found

2 3

[metaparse] performance comparisons?
by Peter Dimov 07 Jun '15

07 Jun '15

Abel, After looking at Metaparse, I inquired on the c++std-ext list as to whether user-defined operators can create char packs from integer or floating point literals, but not from string literals, as this would have made the MPLLIBS_STRING macro unnecessary. As it turns out, there has been such a proposal, N3599: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3599.html later referenced by two competing proposals for compile-time string literals, N4121 and N4236: https://isocpp.org/files/papers/n4121.pdf http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4236.html N3599 has been however rejected, as the committee apparently feels that representing compile-time strings as char packs is inefficient and impractical, and prefers constexpr char arrays. I cited Metaparse as an argument that char packs are quite obviously practical if they work in practice, and was asked whether measurement data has been presented as part of the formal review, perhaps compared to alternatives. I'm not aware of any alternatives to Metaparse though, so this question may be hard to answer. :-) Either way, the only performance data I see is http://abel.web.elte.hu/mpllibs/metaparse/performance.html which seems rather slim. Is there any other? (On an unrelated note, the cpp-next.com link is dead, but archive.org still has it at http://web.archive.org/web/20140217173026/http://cpp-next.com/archive/2012/…)

5 19

Boost documentation with ability for users to post comments
by Krzysztof Jusiak 06 Jun '15

06 Jun '15

Hi, Recently I come across presentation from CppCon 2015 (Boost 2.0 by Robert Ramey). One of the points mentioned was related to adding possibility to allow users to post comments on the documentation pages. I have recently added such functionality to Boost.DI documentation using https://disqus.com service. It allows you to have comments on each page. It's also really easy to do add it to qbk based documentation: 1. Create an account on disqus service and add your website (consider allowing anonymous posts in settings) 2. Generate html doc using boost quickbook as usual 3. Add comments with simple script: find html -iname "*.html" | xargs sed -i -e '/<\/body>/{r comments.html' -e 'd}' -e 's/<\/html>/<\/body><\/html>/' where comments.html content is taken from disqus service -> https://github.com/krzysztof-jusiak/di/blob/cpp14/doc/comments.html 4. Deploy and enjoy users being able to add/read comments.... (on the bottom of each page) That's all, you can try it out and post, preferably useful feedback, on Boost.DI documentation website: http://krzysztof-jusiak.github.io/di/cpp14/boost/libs/di/doc/html/ Cheers, Kris

8 13

Help with adding BOOST_INCLUDE to Jamroot?
by Peter Dimov 06 Jun '15

06 Jun '15

I'm trying to add a BOOST_INCLUDE variable to Jamroot, with an initial value $(BOOST_ROOT): path-constant BOOST_ROOT : . ; +path-constant BOOST_INCLUDE : . ; I then replaced the places where . is used directly as the include path (see diff at end of mail.) Now "b2 headers" works as expected, but when I remove boost/ and go into, for instance, libs/smart_ptr/test and run b2, it doesn't recreate the header links, whereas it did so before. I've no idea why. Can anyone help? diff --git a/Jamroot b/Jamroot index eda4fb4..a999a57 100644 --- a/Jamroot +++ b/Jamroot @@ -131,6 +131,7 @@ import path ; import link ; path-constant BOOST_ROOT : . ; +path-constant BOOST_INCLUDE : . ; constant BOOST_VERSION : 1.59.0 ; constant BOOST_JAMROOT_MODULE : $(__name__) ; @@ -143,7 +144,7 @@ local all-headers = for dir in $(all-headers) { - link-directory $(dir)-headers : libs/$(dir)/include/boost : <location>. ; + link-directory $(dir)-headers : libs/$(dir)/include/boost : <location>$(BOOST_INCLUDE) ; explicit $(dir)-headers ; } @@ -153,7 +154,7 @@ if $(all-headers) } project boost - : requirements <include>. + : requirements <include>$(BOOST_INCLUDE) [ boostcpp.architecture ] [ boostcpp.address-model ] @@ -169,7 +170,7 @@ project boost <toolset>como-linux:<define>_GNU_SOURCE=1 # When building docs within Boost, we want the standard Boost style <xsl:param>boost.defaults=Boost - : usage-requirements <include>. + : usage-requirements <include>$(BOOST_INCLUDE) : build-dir bin.v2 ; @@ -234,7 +235,7 @@ for local l in $(all-libraries) # Log has an additional target explicit-alias log_setup : libs/log/build//boost_log_setup ; -alias headers : $(all-headers)-headers : : : <include>. ; +alias headers : $(all-headers)-headers : : : <include>$(BOOST_INCLUDE) ; explicit headers ; # Make project ids of all libraries known. @@ -281,9 +282,9 @@ rule boost-install ( libraries * ) headers = # The .SUNWCCh files are present in tr1 include directory and have to be # installed (see http://lists.boost.org/Archives/boost/2007/05/121430.php) - [ path.glob-tree $(BOOST_ROOT)/boost : *.hpp *.ipp *.h *.inc *.SUNWCCh : CVS .svn ] - [ path.glob-tree $(BOOST_ROOT)/boost/compatibility/cpp_c_headers : c* : CVS .svn ] - [ path.glob boost/tr1/tr1 : * : bcc32 sun CVS .svn ] + [ path.glob-tree $(BOOST_INCLUDE)/boost : *.hpp *.ipp *.h *.inc *.SUNWCCh : CVS .svn ] + [ path.glob-tree $(BOOST_INCLUDE)/boost/compatibility/cpp_c_headers : c* : CVS .svn ] + [ path.glob $(BOOST_INCLUDE)/boost/tr1/tr1 : * : bcc32 sun CVS .svn ] ; # Declare special top-level targets that build and install the desired variants

1 0

[context] Fwd: [Boost-testing] Master regression shunts not finding asm/make_i386_ms_pe_gas.asm
by Rene Rivera 06 Jun '15

06 Jun '15

---------- Forwarded message ---------- From: Jim Bell <Jim(a)jc-bell.com> Date: Sat, Jun 6, 2015 at 8:04 AM Subject: [Boost-testing] Master regression shunts not finding asm/make_i386_ms_pe_gas.asm To: Running Boost regression tests <boost-testing(a)lists.boost.org> error: Unable to find file or target named error: 'asm/make_i386_ms_pe_gas.asm' error: referred to from project at error: '../libs/context/build' _______________________________________________ Boost-Testing mailing list Boost-Testing(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-testing -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

2 1

IOStreams zlib_decompressor does not check crc for empty string
by John Wallace 05 Jun '15

05 Jun '15

When decompressing an empty file, the zlib_decompressor does not check the crc, which can cause an exception to be raised on a correctly-formatted gzip file, especially when the gzip file is created by concatenating compressed blocks. This comes up especially when working with bgzip files (see specification at: http://bioinformatics.oxfordjournals.org/content/27/5/718.full; all bgzip files end in a special empty block) I have attached a demonstration file (zlib_test.cpp) that illustrates the problem. This program simply reads a compressed input line by line from stdin and outputs to stdout (nearly equivalent to zcat). Assuming we compile to a.out, the following BASH commands illustrate the issue: $ cat <(echo "foo" | gzip -c) <(echo -n "" | gzip) <(echo "bar" | gzip) | ./a.out foo Whereas, we expect the following: $ cat <(echo "foo" | gzip -c) <(echo -n "" | gzip) <(echo "bar" | gzip) | zcat foo bar I have attached a patch to zlib.cpp (base version 1.51, but I confirmed that it persists in 1.58) which I believe should resolve the issue by simply setting the crc to 0 when an empty string is decompressed. Thanks for your time, John Wallace

1 0

[metaparse] review
by Andrzej Krzemienski 05 Jun '15

05 Jun '15

Hi, I wish I had more time to thoroughly review and test the implementation, but as this is not possible I will have to take risk and vote without the in-depth investigation. I vote YES, this library is needed in Boost. Although it will be used only by a fraction of community, it is an essential complimentary part to the Standard C++ user-defined literals (in raw form). The Standard offers a way to decompose a a user-defined literal into a sequence of characters each passed as a separate template argument. This enables to build at compile time constants of user defined numeric types, but doing it is hard, and the Standard offers little help. This is where Abel's library comes into rescue. Although it was designed to do much more, it also fills this sort of hole in the Standard. I have read Abel's posts, and know he has been working on the subject for a couple of years now, so I am confident in his competence. In a way, I see two components inside: (1) A tool for converting a string literal into instantiation of string<> template. (2) tools for parsing those string<>s. I see use cases for each of these components separately. Parsing templates with characters, is painstaking but fairly easy, so I may want to do it myself, provided I have a way to convert a string literal to a template. I was trying to hack it for a long while, without success. There is quite a bit of trickery put into it. It is really ingenious. On the other hand, when processing my raw user-defined literals, I may need your parsers, but I care not about BOOST_MS_STRING() (or how you want to call it). The standard questions: - What is your evaluation of the design? > Adequate: this is string parsing what the library does, so the parser interface seems the right choice. > - What is your evaluation of the implementation? > I haven't looked at the parsers. Regarding, BOOST_MS_STRING(), it is a nice trick to implement the impossible. > - What is your evaluation of the documentation? > Well, after having read it, I understood what to expect of it, so in that sense, it is adequate. But there is something about it that makes it "heavy". Maybe it is just the problem domain, I do not know. > - What is your evaluation of the potential usefulness of the library? > It is useful, although to a fraction of community: libraries with user-defined literals, printf, other EDSLs. > - Did you try to use the library? > I tested BOOST_MP_STRING() (couldn't believe it works). - With what compiler? MinGW on Windows, GCC 4.8.2 - Did you have any problems? > Nope > - How much effort did you put into your evaluation? A glance? A quick > reading? In-depth study? > I read the docs (not all of them); downloaded and played with BOOST_MP_STRING(). -- two hours. - Are you knowledgeable about the problem domain? I never had to do parse at compile time for my commercial programs, but as a hobby I studied the subject, and have even written some posts about it. Thanks Abel, the library is cool. --&rzej

2 5

[metaparse] Update review
by Edward Diener 04 Jun '15

04 Jun '15

This is an updated review of the metaparse library. In my initial review I reacted to the fact that library presentation had changed during the review period. Although I feel I made a point I was too harsh in doing so. So now I would like to review the library as it has been presented in its form suitable for review as a modular boost library. - What is your evaluation of the design? The design of the library appears well thought out to me, providing both low-level and higher-level metafunctions for use. The higher level metafunctions take other metafunctions as input in a classic design of metafunction programming as explained in MPL. The design of the library makes it easy for anybody with knowledge of MPL to understand how to use the metafunctions in the library and to create one's own higher level metafunctions for particular parsing tasks if necessary. A couple of quibbles about the design based merely on my own sense of 'naming'. Since I have roundly criticized "naming wars" <g> in the past I no doubt leave myself open for criticism, but these are just personal suggestions, which I can live without: * BOOST_STRING is very generic and can easily lead to a macro clash. Something like BOOST_METAPARSE_STRING or maybe BOOST_MPS_STRING would be more distinct and safer. I favor shortened names for libraries in macros to be 3 characters rather than 2 characters so as to decrease macro clashes. * The various 'foldxxx' names, even with the Cheat-Sheet explanation of their name formation in the docs, seems needlessly confusing. Would it not be better to make longer, less confusing names, which actually spell out what the metafunctions are about. Is it really so hard to write "fold_left', 'fold_right', 'fold_left_fail' etc. etc. Sometimes clarity trumps how many keys one types. - What is your evaluation of the implementation? I didn't look at the code of the implementation. I generally trust that if the code works as documented an experienced programmer's implementation is his own affair. - What is your evaluation of the documentation? The documentation is fairly profuse approaching the subject of compile-time parsing in many different ways. I found that the work needed to produce a solid set of documentation had been done. I have some quibbles and a few suggestions so let me give it as a general list of items: * A general discussion about the purpose of the functionality of the library would be welcome. Such as the possible metaprogramming scenarios in which a programmer would want to accept and analyze ( parse ) an MPL string in creating his metafunctions. * A general comparison of when it might be better/worse to use Metaparse as oppose to Boost.Spirit. Pluses and minuses of both approaches might be discussed. * On the first page of documentation it mentions the various types of output which Metaparse can generate. Both 'types' and 'metafunctions' are very understandable, but whatever is meant by "Objects" and "Callable C++ functions" doesn't follow the definition of these terms in C++ which I know. Some discussion, or link, of what these two types of output mean in the context of Metaparse should be given. * The Versioning section appears to be wrong in quite a number of places. Please proofread what was written there and correct/update it. * In the Reference section, among the items enumerated at the end are 'Metafunctions and metafunction classes' and "Utilities' but when you click on the links to go the actual headings it looks like the metafunctions are split before and after the utilities. - What is your evaluation of the potential usefulness of the library? I think it give the template programmer another important tool for designing templates for end-users. As such it has intrinsic value for programmers writing templates for end-users to use. - Did you try to use the library? Yes. - With what compiler? I used the Metashell tool to test things out. I then tried manually compiling some examples in the documentation with Mingw/gcc-4.9.2 with '-std=c++11'. I also ran the tests successfully with Mingw/gcc-4.9.2 with '-std=c++11'. - Did you have any problems? No. Everything worked as expected. - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? My main effort was in trying to understand how the parts of the library worked with each other. It is not easy to understand everything, and I do not claim that I do, but I could understand from the documentation how the major areas of parsing worked and what metafunctions are used for what tasks. I could also see that if would be easy to incorporate one's own metafunctions into generalized parsing tasks using what Metaparse provides. I did need the full documentation set, which is profuse, to understand the parts of the library. Part of my initial reaction when the library was first presented was that I could only find the documentation for the 'Getting Started' link, and I am one of those people who is just mentally incapable of understanding code from the point of view of "here's how to use" documentation only. Once I discovered the full documentation in the updated presentation of the library in modular Boost form I could see and understand the library much better. - Are you knowledgeable about the problem domain? Generally knowledgable about parsers and how they work, but not an expert. Finally I vote YES to accept the library into Boost, reversing my previous initial vote. The library will prove useful for template programming in some contexts, has obviously been designed thoughtfully, and the full documentation presents everything one would need to use the library, explaining things in various effective ways, one or more of which ways should satisfy all programmers who do template programming.

5 4

Link to Bind library doc broken.
by Alex Mohr 04 Jun '15

04 Jun '15

This link for the Bind library is broken on this page: http://www.boost.org/doc/libs/ The link goes here, which gives a 404 not found: http://www.boost.org/doc/libs/1_58_0/libs/bind/doc/html/bind.html Alex

2 1

Moving the include directory to $BOOST_ROOT/include? (again)
by Peter Dimov 04 Jun '15

04 Jun '15

I want to reiterate my suggestion that we move Boost's include directory from $BOOST_ROOT to $BOOST_ROOT/include. This has the following benefits: - it follows the established naming practice, - it does not make the whole Boost reachable from the include path as it does now, - when building Boost, the message given at the end would be The Boost C++ Libraries were successfully built! The following directory should be added to compiler include paths: C:\Projects\boost-git\boost\include The following directory should be added to linker library paths: C:\Projects\boost-git\boost\stage\lib instead of the current The Boost C++ Libraries were successfully built! The following directory should be added to compiler include paths: C:\Projects\boost-git\boost The following directory should be added to linker library paths: C:\Projects\boost-git\boost\stage\lib which is more in line with a user's expectations. - it's more consistent because it builds the virtual include/ subdirectory from the contents of the multiple libs/*/include/ subdirectories. For backward compatibility, "b2 headers" could create a boost/ symlink to include/boost/. Also for backward compatibility, monolithic releases can continue to ship the headers in boost/ if moving the directory would be seen as too disruptive. Failing acceptance of the above proposal, can we at least use a path constant (BOOST_INCLUDE?) somewhere in Jamroot or boostcpp.jam that identifies where the header links are to be placed? Its current contents would be "." but I would be able to change that to "include" instead of locating and patching all the places that refer to the include path.

8 19

[metaparse] review
by Gordon Woodhull 04 Jun '15

04 Jun '15

Hi all, I believe that Metaparse should be accepted into Boost. > - What is your evaluation of the potential usefulness of the library? As mentioned by others, Metaparse is a library for library developers. In terms of functionality, it is closest to Boost.Proto, although it allows defining arbitrary EDSLs as strings, instead of using the built-in C++ operators. In order to test the effectiveness of Metaparse, I built a parser for the Graphviz "dot" language [1]. This is of practical importance to me, because I have an interest in graph metaprogramming [2], specifically generating types and networks of types from graph metadata. Having a nice language for defining graphs in metadata, to support a syntax beyond angle brackets, would be very helpful. One limitation of this class of EDSL is that it can produce arbitrarily complex types, but it can't refer to any existing types. E.g. you might have the string "int" in your EDSL, but in order for it to refer to the C++ int type, you are going to need an mpl::map from type-strings to types. I didn't get this far in my evaluation, but it's really beyond the scope of the library. > - Are you knowledgeable about the problem domain? Fairly knowledgeable. I have built an experimental parser for compile-time EDSLs over type expressions called "Angly" [4] (presented at C++Now 2012). I have learned from the considerably simpler design of Metaparse, and hope to apply it to my own library (in particular using recursive descent rather than trying to wrangle a deterministic finite automaton). > - How much effort did you put into your evaluation? A glance? A quick > reading? In-depth study? I spent about 5 hours getting set up and working through the tutorial, and about 7 hours getting up and running with my own parser. Once I "got it", it only took an hour or two to implement the rest of the grammar (and about 4 hours to write this review). My results (grammar and a few basic tests) are in a Gist available here: [3]. My grammar is able to parse "dot" graph descriptions that look like this "graph g { A [x=y]; \ B->C [y=z, w=a]; \ D->E; \ F; \ G->H [a=b, b=c, c=d, d=e, e=f, f=g]; \ I->J; \ }" Because I ran out of time, my parser only produces an AST; it does not yet produce MPL.Graph or Fusion.Graph types. > - Did you try to use the library? > - With what compiler? > - Did you have any problems? I mostly used metashell for my evaluation, but I also tested compilation times with clang 3.5 once I had something running. Any problems I had were the usual difficulties of TMP. I was not expecting the compile times to be tolerable, but even in metashell, the turnaround was usually around 15-20s. Compiling my longest test with clang, just shy of 256 characters, took only about 4-5 seconds. > - What is your evaluation of the documentation? Excellent. Working through the tutorial was enough for me to absorb the particular constructs needed for building grammars and semantic actions. I also used the reference documentation when building my own parser. This documentation is more terse, very much in the style of the MPL documentation. But it functions. I only skimmed the user manual, since the content looks a little bit stale (doesn't mention build_parser) and somewhat redundant with the tutorial. As Andrzej mentions, there may need to be an introduction concerning the scope of the library and what you can and can't do with this kind of EDSL, where you would use Proto instead of Metaparse, etc. I think that as the library evolves, the documentation will probably need more general parsing background, of the sort you will find in Spirit documentation. For example, the tutorial covers the unary `-` operator, but it doesn't mention why there is no ambiguity with the binary `-` operator. Also, it seems (as mentioned in the design discussion below) that the grammar must be unambiguous, and this is mentioned nowhere. Overall, the documentation is stronger on the meta- than the -parse. > - What is your evaluation of the implementation? I did not peer into the code very much, beyond finding some examples I needed. My impression from Abel's walk-through at C++Now 2012 is that the implementation is quite simple and straightforward, based on established techniques from parsers in Haskell. > - What is your evaluation of the design? Very good. However, I think the API might be fleshed out a little bit once the library gets more usage. In particular, I found myself writing a few helper metafunctions that looked like this: template<typename EdgeDecl> struct declare_edge { typedef edge_decl<typename mpl::at_c<EdgeDecl, 0>::type, typename mpl::at_c<EdgeDecl, 2>::type, typename mpl::at_c<EdgeDecl, 3>::type> type; }; invoked from a transform like this: using edge_stmt = transform< sequence<ID, arrow_token, ID, opt<attr_list, mpl::vector<>>>, mpl::quote1<declare_edge> >; It may be my inexperience, but it struck me that it would be helpful to have a "spread" or "apply" transform so that the items in the mpl::vector produced by sequence would be supplied as parameters to declare_edge, instead of having to pull them out using mpl::at_c. There may be some trick I don't know here. I will mention two other points of confusion. These are probably not design flaws in the library, but I thought I would bring them up in case they are. First, I started out defining my AST nodes like this: template<typename Tail, typename Head, typename Attrs> struct edge_decl {}; Seems like a reasonable basic type-holder to me. As shown above, this is instantiated and returned by a helper metafunction invoked by the transform which pulls stuff out of an mpl::vector. But then somewhere in metaparse, it tries to again "invoke" this result with ::type when appending it to another mpl::vector. Really? So my transform needs to return not the value, but a metafunction which returns a value? I couldn't figure this out, so I gave each of my AST nodes a self-referential ::type in the way that mpl::vector has: template<typename Tail, typename Head, typename Attrs> struct edge_decl { typedef edge_decl type; //why? }; Something is not right here! The second problem I encountered is about ambiguous grammars. For the "dot" language it seems natural to define a statement this way: using stmt = one_of<node_stmt, edge_stmt>; where a node statement looks like ID [attr=value, attr=value]; and an edge statement looks like ID -> ID [attr=value]; But there's an ambiguity here, and once the parser successfully reads a node, it is going to get upset if it sees a `->`. So the rule has to be written the other way: using stmt = one_of<edge_stmt, node_stmt>; Similarly, the `;` separator for declarations is optional in the "dot" language, but I couldn't figure out how to implement this, because if you try to have an optional element at the beginning of a rule: template<typename Parser, typename Default = void> using opt = one_of<Parser, return_<Default>>; using stmt_list = foldlp< sequence<opt<semi_token>, stmt>, transform<stmt, mpl::quote1<mpl::vector1>>, // ... then the parser will greedily eat the epsilon and have nowhere to go (at least according to my amateur understanding of parsers). I gave up here and made the separator mandatory. Again, this is probably not a flaw in the design, but the documentation should describe what kinds of grammars will work, and perhaps give pointers to other resources about disambiguating grammars. Probably there is a different construct which would help here. Cheers, Gordon [1] http://www.graphviz.org/doc/info/lang.html [2] http://metagraph.info/wp-content/uploads/2011/05/mpl.graph_.pdf [3] https://gist.github.com/gordonwoodhull/dcbb332eea06dd3279b9 [4] https://github.com/gordonwoodhull/metagraph

2 5

[build] Error building bjam on cygwin
by Emil Dotchevski 03 Jun '15

03 Jun '15

I'm trying to build bjam from Boost 1.56.0 under cygwin. Running ./build.bat mingw errs with: gcc -DNT -o bootstrap\jam0.exe command.c compile.c constants.c debug.c execcmd.c execnt.c filent.c frames.c function.c glob.c hash.c hdrmacro.c headers.c jam.c jambase.c jamgram.c lists.c make.c make1.c object.c option.c output.c parse.c pathnt.c pathsys.c regexp.c rules.c scan.c search.c subst.c timestamp.c variable.c modules.c strings.c filesys.c builtins.c md5.c class.c cwd.c w32_getreg.c native.c modules/set.c modules/path.c modules/regex.c modules/property-set.c modules/sequence.c modules/order.c filent.c:46:20: fatal error: direct.h: No such file or directory #include <direct.h> ^ compilation terminated More errors follow. What am I doing wrong? -- Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode

2 1

[thread] Problem with thread test 'failed to write output file'
by Edward Diener 03 Jun '15

03 Jun '15

Attempting to run the 'thread' tests locally I get: failed to write output file '..\..\..\bin.v2\libs\thread\test\upg_lock_cons_move_ctor_sh_lock_untl_p_lib.test\msvc-12.0\debug\threading-multi\sync\mutual_exclusion\locks\upgrade_lock\cons\move_ctor_shared_lock_until_pass.obj.rsp'! This is with the --abbreviated-path option. If I try using --hash or not using either on the b2 command line I still get the same result of 'failed to write output file ... etc,' probably because the output file spec is still too long. This happens on Windows thread tests with msvc-12.0 but not with gcc-4.9.2. Any ideas how I can get this to run successfully ?

1 1

[admin] General Boost email?
by Rene Rivera 02 Jun '15

02 Jun '15

I've been experimenting with the various cloud based CI systems out there in an effort to make it easy to have all Boost libraries CI tested. As part of that I'm trying to set up an organization account in Appveyor and I'm stuck.. As I need a global org email to register. Hence I would like to request that we set up an "owners(a)boost.org" email that we can use for such circumstances (that just forwards to the git boostorg owners). Does that sound OK? Whom would set up such an email? -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

1 0

[test] possible bug in 1.47.0
by Damian Vicino 02 Jun '15

02 Jun '15

Hi, I’m working in the safe_float library and while working on it I defined a partial specialisation of numeric_limits for safe_float. I wanted the safe_float<T> to mimic the T numeric_limits in most of the values and just change a few, but nothing complex, one liners only. Then, I created a test for validating those methods/attributes mimicking the internal T are equal to those on T, as follows: //types to be tested using test_types=boost::mpl::list< float, double, long double >; using namespace boost::safe_float; BOOST_AUTO_TEST_CASE_TEMPLATE( safe_float_numeric_limits_basic_fp_types, FPT, test_types){ BOOST_CHECK_EQUAL(std::numeric_limits<safe_float<FPT>>::is_specialized, std::numeric_limits<FPT>::is_specialized); } The test does not even compile: Undefined symbols for architecture x86_64: "std::__1::numeric_limits<boost::safe_float::safe_float<double, boost::safe_float::policy::check_addition_overflow, boost::safe_float::policy::on_fail_throw, boost::safe_float::policy::cast_none> >::is_specialized", referenced from: safe_float_numeric_limits_suite::safe_float_numeric_limits_basic_fp_types<double>::test_method() in numeric_limits_test.o After looking at the numeric_limits specialisation for a while, I tried changing the test as follows: if (std::numeric_limits<safe_float<FPT>>::is_specialized == std::numeric_limits<FPT>::is_specialized){ BOOST_CHECK(true); } else { BOOST_CHECK(false); } And as follows: BOOST_CHECK(std::numeric_limits<safe_float<FPT>>::is_specialized == std::numeric_limits<FPT>::is_specialized); Both alternatives work. Is there something wrong with BOOST_CHECK_EQUAL? I’m using version 1.47.0 Best regards, Damian

2 1

Boost.Test v3 is here
by Gennadiy Rozental 02 Jun '15

02 Jun '15

Boost.Test team is proud to present new version of Boost.Test library. This milestone release among many other thing includes: * Completely updated (and hopefully improved) documentation * New universal testing tool BOOST_TEST * Support for decorators * Support for data driven test cases * and much more (you can see changelog here: http://raffienficiaud.github.io/test/boost_test/change_log.html This release would not be possible without Raffi Enficiaud, who joined the team and jump started documentation rework and Andrzej Krzemieński's major contribution to the new documentation. We invite everyone to review and comment on new documentation (http://raffienficiaud.github.io/test/index.html) We will be happy to accept your pull requests with improvements and notes in the mailing list. Unless we find any major showstopper we plan to merge to the master branch in 2-3 weeks time. We do not anticipate backward compatibility issues, but please report any you observe and we'll try to address them in a timely manner. Once again, please review the new documentation and feel free to comment here or by sending us pull requests. Regards, Gennadiy Rozental

8 12

Running regression tests locally
by Andrzej Krzemienski 01 Jun '15

01 Jun '15

Hi Everyone, I need an advice here. When I look at the test matrix online, I can easily see how many tests failed. In contrast, when I run the tests locally (call b2 in folder 'test') I get a bunch of output, but I cannot easily figure out if and how many tests have failed. Is there a way to do it? Or to build a summary of some sort? Regards, &rzej

2 1

[b2] Need help with b2
by Andrzej Krzemienski 01 Jun '15

01 Jun '15

Hi everyone, Today after doing a `git pull --rebase` on modular Boost, b2 stopped working for me. I keep getting the following error. Can someone help me figure out what this is? Regards, &rzej C:/source/modular-boost/tools/build/src/build\feature.jam:139: in feature.feature from module feature error: unknown attributes: hidden error: in feature declaration: error: feature "deduced-address-model" : "32" "64" : "propagated" "optional" "composite" "hidden" C:/source/modular-boost\boostcpp.jam:570: in load from module boostcpp C:/source/modular-boost/tools/build/src/kernel\modules.jam:289: in modules.import from module modules C:/source/modular-boost/tools/build/src/build\project.jam:1024: in import from module Jamfile<C:\source\modular-boost> ..\..\..\Jamroot:124: in modules.load from module Jamfile<C:\source\modular-boost> C:/source/modular-boost/tools/build/src/build\project.jam:311: in load-jamfile from module project C:/source/modular-boost/tools/build/src/build\project.jam:64: in load from module project C:/source/modular-boost/tools/build/src/build\project.jam:113: in load-parent from module project C:/source/modular-boost/tools/build/src/build\project.jam:449: in initialize from module project C:/source/modular-boost/tools/build/src/build\project.jam:301: in load-jamfile from module project C:/source/modular-boost/tools/build/src/build\project.jam:64: in load from module project C:/source/modular-boost/tools/build/src/build\project.jam:113: in load-parent from module project C:/source/modular-boost/tools/build/src/build\project.jam:449: in initialize from module project C:/source/modular-boost/tools/build/src/build\project.jam:301: in load-jamfile from module project C:/source/modular-boost/tools/build/src/build\project.jam:64: in load from module project C:/source/modular-boost/tools/build/src/build\project.jam:145: in project.find from module project C:/source/modular-boost/tools/build/src\build-system.jam:535: in load from module build-system C:\source\modular-boost\tools\build\src/kernel\modules.jam:289: in import from module modules C:\source\modular-boost\tools\build\src/kernel/bootstrap.jam:139: in boost-build from module C:\source\modular-boost\boost-build.jam:17: in module scope from module

2 2

Correct Mutext Destroy Behaviour, Pthreads and Boost
by Robert Bell 01 Jun '15

01 Jun '15

If an object is implemented to support reference counting, and has an internal raw pthread mutex, the open group is pretty clear in the pthread_mutex_destroy doc on what different implementations must ensure (http://pubs.opengroup.org/onlinepubs/009695399/functions/pthread_mutex_dest…) Note the following statement at the bottom: "A mutex can be destroyed immediately after it is unlocked. For example, consider the following code:" obj_done(struct obj *op) { pthread_mutex_lock(&op->om); if (--op->refcnt == 0) { pthread_mutex_unlock(&op->om); (A) pthread_mutex_destroy(&op->om); (B) free(op); } else (C) pthread_mutex_unlock(&op->om); } In this case obj is reference counted and obj_done() is called whenever a reference to the object is dropped. Implementations are required to allow an object to be destroyed and freed and potentially unmapped (for example, lines A and B) immediately after the object is unlocked (line C)." On moving some of my underlying libraries to Boost, I took a look at Boost's Mutex object. The implementation of the Mutex object's destructor call does: ~mutex() { int const res = posix::pthread_mutex_destroy(&m); boost::ignore_unused(res); BOOST_ASSERT(!res); } My question centres on whether Boost's implementation violates the open group's requirement. The calls to posix::pthread_mutex_destroy (Boost's wrapper), usually perform a straight-through call to ::pthread_mutex_destroy, but it occurs inside the destructor, and so does this call occur "immediately after" an unlock by the group's definition? In straight pthreads, if I want to make sure I can rely on various implementations of the standard, I can simply do exactly what the open group says, unlock, and the next line destroy. But in the case of Boost, is it safe to do something like: mutex->unlock(); delete mutex_; One thing I did note of interest is that Apple's implementation seems to lock the mutex from within the destroy call, which is curious: int pthread_mutex_destroy(pthread_mutex_t *mutex) { int res; LOCK(mutex->lock); if (mutex->sig == _PTHREAD_MUTEX_SIG) { if (mutex->owner == (pthread_t)NULL && mutex->busy == (pthread_cond_t *)NULL) { mutex->sig = _PTHREAD_NO_SIG; res = ESUCCESS; } else res = EBUSY; } else res = EINVAL; UNLOCK(mutex->lock); return (res); } There seems, generally, to be a good deal of confusion surrounding when it is safe to destroy the resources associated with a mutex, and most people offer widely inaccurate comments based largely on opinion. My question points to whether code adjacency is a requirement of correct behaviour in some implementations, and if not, why not? If I have missed an obvious explanation somewhere, my apologies. I read through the different patterns of Boost threading listed in the documentation, but was not convinced the question was addressed. Thanks in advance…

4 5

Resources available for testing on 64-bit MSVC
by pfultz2 01 Jun '15

01 Jun '15

Hello, Recently, I have been working on adding MSVC support for the Fit library, and I have been fairly successful. Using the VMs at modern.ie, I was to able to get all the tests to pass on 32-bit Visual Studio 2015 RC. Unfortunately, a few tests fail on the 64-bit MSVC, and I have been unable to find a VM I can use to debug the problem. All the VMs at modern.ie are 32-bit, it seems. Does anyone know of resources available to test and debug libraries with 64-bit MSVC? Thanks, Paul -- View this message in context: http://boost.2283326.n4.nabble.com/Resources-available-for-testing-on-64-bi… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 2

[next gen future-promise] What to call the monadic return type?
by Niall Douglas 01 Jun '15

01 Jun '15

Dear list, As AFIO looks likely to be finally getting a community review soon, I've made a start on a final non-allocating constexpr-collapsing next generation future-promise such that the AFIO you review is "API final". You may remember my experimentations on those from: http://boost.2283326.n4.nabble.com/Non-allocating-future-promise-td466 8339.html. Essentially the win is that future-promise generates no code at all on recent C++ 11 compilers unless it has to [1], and when it does it generates an optimally minimal set with no memory allocation unless T does so. This should make these future-promises several orders of magnitude faster than the current ones in the C++ standard and solve their scalability problems for use with things like ASIO. They also have major wins for resumable functions which currently always construct a promise every resumable function entry - these next gen future-promises should completely vanish if the resumable function never suspends, saving a few hundred cycles each call. Anyway, my earlier experiments were all very promising, but they all had one big problem: the effect on compile time. My final design is therefore ridiculously simple: a future<T> can return only these options: * A T. * An error_code (i.e. non-type erased error, optimally lightweight) * An exception_ptr (i.e. type erased exception type, allocates memory, you should avoid this if you want performance) In other words, it's a fixed function monad where the expected return is T, and the unexpected return can be either exception_ptr or error_code. The next gen future provides Haskell type monadic operations similar to Boost.Thread + Boost.Expected, and thanks to the constexpr collapse this: future<int> test() { future<int> f(5); return f; } test().get(); ... turns into a "mov $5, %eax", so future<T> is now also a lightweight monadic return transport capable of being directly constructed. In case you might want to know why a monadic return transport might be so useful as to be a whole new design idiom for C++ 11, try reading https://svn.boost.org/trac/boost/wiki/BestPracticeHandbook#a8.DESIGN:S tronglyconsiderusingconstexprsemanticwrappertransporttypestoreturnstat esfromfunctions. However, future<T> doesn't seem named very "monadic", so I am inclined to turn future<T> into a subclass of a type better named. Options are: * result<T> * maybe<T> Or anything else you guys can think of? future<T> is then a very simple subclass of the monadic implementation type, and is simply some type sugar for promise<T> to use to construct a future<T>. Let the bike shedding begin! And my thanks in advance. Niall [1]: Compiler optimiser bugs notwithstanding. Currently only very recent GCCs get this pattern right. clang isn't bad and spills a dozen or so completely unnecessary opcodes, and I'll follow up with Chandler with some bug reports to get clang fixed. Poor old MSVC spits out about 3000 lines of assembler, it can't do constexpr folding at all yet. -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

16 122

RFC: Separating Boost.Python from Boost
by Stefan Seefeld 31 May '15

31 May '15

Hello, as I have mentioned here before, I would very much like to continue the modularization effort, by fully separating the Boost.Python project from the rest of Boost. For avoidance of doubt: my intent is not to remove Boost.Python out of the Boost organization. Rather, I would like to separate the build and release processes. For the sake of keeping the discussion focused, I would like to avoid getting into too many (technical) details (there already is a related discussion on the Boost.Build list). Rather, I would like to know whether people here (and Boost.Python users in particular) have any particular thoughts about this proposal. Any strong reasons not to move forward with this ? Things to consider while doing it ? Etc. (My hope is that if the operation succeeds, other Boost libraries may want to do the same, which would help Boost in the long term to become more manageable.) Thanks, Stefan -- ...ich hab' noch einen Koffer in Berlin...

18 62

Thoughts on Trac wiki page commenting facility
by Niall Douglas 31 May '15

31 May '15

Something Robert raised during the meetings at C++ Now was why can't people comment on Boost's Trac wiki pages? The simple answer is because Trac doesn't allow it and hasn't got to implementing it in many years (http://trac.edgewall.org/ticket/11676) despite it being technically as simple as appending a ticket's comments to a wiki page, so I spent some time researching what options are available: 1. https://trac-hacks.org/wiki/WikiCommentsPlugin This works by inserting the comments directly into the article text. Pros: The comments are the document. This lets the page author fix the problem and delete the comment where that is appropriate. Cons: You need a trac login and editing privs to comment, which until a Trac 1.0 upgrade remains manually awarded by a Boost admin. No preview, so you need to know Trac wiki markup. 2. Disqus https://disqus.com/ This is the grand daddy of free commenting services. This works by you inserting some Javascript into the page where you want the comments to appear. AJAX does the rest. This could very easily patched into Trac for every wiki page by tweaking its template as per the instructions at http://trac.edgewall.org/wiki/TracInterfaceCustomization. Pros: Very well understood by users, in fact by everyone. Built in excellent spam protection. Nice UI. Just works. I also have a ton of ready to go infrastructure from nedprod.com for Disqus, so it's really very little effort for me to integrate this. Cons: They own all your data. They serve adverts in the comment stream, though apparently you can now opt out. They track user visits and sell the information, so AdBlock and Ghostery default block Disqus. Comment load times can be very slow. Comments aren't indexed by Google, and this may decrease the value of the system. 3. Keep looking Niall! Like none of the above? There are open source clones of Disqus you can host on your own infrastructure, but I have no experience with any of the those. If the community really doesn't like either of the two above, I guess I can keep looking. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

4 5

[locale] Build failure on develop
by Marcel Raad 30 May '15

30 May '15

Hi, since Tuesday, all Boost.Locale tests have been failing on all compilers: http://www.boost.org/development/tests/dev elop/developer/locale.html The MSVC results only mention an expected has_iconv.cpp build failure and it seems all other results only say "Error extracting file: No matching files were found." I tested on my local machine with MSVC 14 RC and the library wouldn't compile because of a missing "#include <map>": https://github.com/boostorg/locale/pull/8

1 0

[bind] Placeholders suggestion, std and boost
by Edward Diener 30 May '15

30 May '15

I realize that changing boost::bind so by default that placeholders of the form _n needing some sort of namespace in front of it will break plenty of code, so I am not suggesting doing that. What I would like to suggest is a Boost.bind macro, which when used before including <boost/bind>, would put the boost::bind placeholders of the form _n in a boost::placeholders namespace. The reason for this suggestion is so that boost::bind and std::bind can be similar syntactically enough so that one could choose one or the other depending on compiler support. Since in the C++ std the placeholders are in the std::placeholders namespace, having a means to have the boost::bind placeholders in the boost::placeholders namespace would be a means to that end.

5 16

[type_traits] Big changes in develop
by John Maddock 30 May '15

30 May '15

A heads up that the "Version2" rewrite of type traits is now in develop. There's still lots to do - more PR's will happen over the coming weeks to remove obsoleted code from other libraries (and quash the warnings that they'd otherwise generate). The docs also need a major update. In the mean time please do shout loudly if there are any regressions caused by this change. Thanks, John.

8 26

[test] Fwd: [Boost-testing] All test runners (windows and linux) crashing
by Rene Rivera 29 May '15

29 May '15

Boost Test developers please fix ASAP. ---------- Forwarded message ---------- From: Tom Kent <lists(a)teeks99.com> Date: Thu, May 28, 2015 at 8:26 PM Subject: Re: [Boost-testing] All test runners (windows and linux) crashing To: Running Boost regression tests <boost-testing(a)lists.boost.org>, Boost Developers List <boost(a)lists.boost.org> On Thu, May 28, 2015 at 6:24 PM, Tom Kent <lists(a)teeks99.com> wrote: > All my test runners are quickly crashing during each run...here's the end > of the output in my results/bjam.log file: > > boost-test(RUN) "test/doc_boost_test_macro1" : > "libs/test/doc/examples/boost_test_macro1.cpp" > boost-test(RUN_FAIL) "test/doc_boost_test_macro2" : > "libs/test/doc/examples/boost_test_macro2.cpp" > boost-test(RUN_FAIL) "test/doc_boost_test_macro3" : > "libs/test/doc/examples/boost_test_macro3.cpp" > error: at D:/t08/c/boost_bb/src/kernel\modules.jam:107 > error: Unable to find file or target named > error: '../doc/examples/test_float_01.cpp' > error: referred to from project at > error: '../libs/test/test' > > Any thoughts? > Tom > I should have specified, that is on the develop branch. Master seems fine. _______________________________________________ Boost-Testing mailing list Boost-Testing(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-testing -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

2 2

All test runners (windows and linux) crashing
by Tom Kent 29 May '15

29 May '15

All my test runners are quickly crashing during each run...here's the end of the output in my results/bjam.log file: boost-test(RUN) "test/doc_boost_test_macro1" : "libs/test/doc/examples/boost_test_macro1.cpp" boost-test(RUN_FAIL) "test/doc_boost_test_macro2" : "libs/test/doc/examples/boost_test_macro2.cpp" boost-test(RUN_FAIL) "test/doc_boost_test_macro3" : "libs/test/doc/examples/boost_test_macro3.cpp" error: at D:/t08/c/boost_bb/src/kernel\modules.jam:107 error: Unable to find file or target named error: '../doc/examples/test_float_01.cpp' error: referred to from project at error: '../libs/test/test' Any thoughts? Tom

1 1

[type_traits][units] migrating from ice_and
by Jürgen Hunold 28 May '15

28 May '15

Hi! I've noticed that boost/type_traits/detail/ice_or.hpp and boost/type_traits/detail/ice_and.hpp have been deprecated. Both headers are used as an implementation detail in boost/units/scaled_base_unit.hpp, now resulting in lots of warnings: In file included from .../boost/units/scaled_base_unit.hpp:20: .../boost/type_traits/detail/ice_or.hpp:17:10: warning: NOTE: Use of this header (ice_or.hpp) is deprecated [-W#pragma-messages] # pragma message("NOTE: Use of this header (ice_or.hpp) is deprecated") Question: Is there a known migration path from type_traits to what? MPL? Or am I better off copying both files to Boost.Units and be done? Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! * voice: ++49 4257 300 ! Fährstraße 1 * fax : ++49 4257 300 ! 31609 Balge/Sebbenhausen * jhunold(a)gmx.eu ! Germany

3 4

[testing][teeks] MSVC-14 errors about MSPDB140.DLL
by Andrey Semashev 27 May '15

27 May '15

Hi, All tests for Boost.Log (and I suspect any other built libraries) on MSVC-14 are failing because of this error: LINK : fatal error LNK1101: incorrect MSPDB140.DLL version; recheck installation of this product See here for example: http://www.boost.org/development/tests/develop/developer/output/teeks99-08f… Could this be fixed?

4 7

[typeof] Weird VC++ compiler bug
by Edward Diener 27 May '15

27 May '15

I discovered a strange VC++ bug using Boost.typeof. I am not posting this to rag VC++ but wondering if there is some known workaround in Boost or in Boost.config. #include <boost/typeof/typeof.hpp> template <class T> struct dereference { typedef BOOST_TYPEOF_TPL(*T()) type; }; int main() { } Compiling this with VC++12 gives: test_vc_type_of_indirection.cpp(6) : error C2100: illegal indirection test_vc_type_of_indirection.cpp(7) : see reference to class template instantiation 'dereference<T>' being compiled Notice that I am not even instantiating 'dereference'. But if I write: #include <boost/typeof/typeof.hpp> template <class T> struct dereference { void afunction() { typedef BOOST_TYPEOF_TPL(*T()) type; } }; int main() { } all is well, for all the good it does me. BOOST_TYPEOF_TPL(*T()) expands to: typename boost::type_of::msvc_typeid_wrapper<sizeof(*boost::type_of::encode_start(*T()))>::type and if I substitute this directly the same results occur. I can report this to the VC++ bug tracker but wanted to see if this is a known problem with VC++ in Boost, some weird error for which maybe Boost has some workaround syntax.

6 13

Fwd: Binary Region Differentials
by Kenneth Adam Miller 27 May '15

27 May '15

Suppose I have a rather huge binary region. Transferring it by any means is an expensive operation. But changes to it will only be some fraction at worst case as large as the binary region itself, but in practice will typically be regional byte blobs, mostly not more than a single kilobyte long.. Is there any data structure that already handles this, where I could say, have every instance start off from the original binary region, and calculate what any other instance of that data structure has by "applicating the deltas"?

3 4

svn.boost.org SSL cert errro
by Olaf van der Spek 26 May '15

26 May '15

Hi, The certificatie of svn.boost.org has expired (two weeks ago).. -- Olaf

10 19

[branch master] add library to regression tests
by Oliver Kowalke 26 May '15

26 May '15

Hello, could you please add boost.coroutine2 to the regression tests of branch master?! best regards, Oliver

1 0

Aho - Corasick String Search (for searching multiple patterns) Interface
by meghana madhyastha 26 May '15

26 May '15

Hi, In some of my previous mails I had suggested that the Rabin Karp and Aho - Corasick string search algorithms be implemented as a part of the Boost algorithm library. This is primarily because these algorithms perform well for searching for multiple patterns. The Aho - Corasick algorithm works by building a trie (a tree with each node corresponding to an ASCII character) of the patterns strings and traversing the trie to search for the pattern in a given text. Additionally, the Aho - Corasick introduced the concept of "failure pointer/failure node" which is the node to be traversed when there is a mismatch. For more information: http://en.wikipedia.org/wiki/Aho%E2%80%93Corasick_string_matching_algorithm The interface I propose is as follows. 1. The input of the patterns should be strings within a *container*. This is because these algorithms are primarily used for multiple pattern searching. The user can input pointers/iterators to the first and last pattern . The final output which is returned is a container with each pattern and a iterator/pointer to their occurrences (There are multiple patterns so just returning an iterator/pointer to where the patterns first occurs in the pattern will not suffice). 2. Just like the previous string searching algorithms that have been implemented in Boost, there can be an object based interface as well as a procedure based interface. In the object based interface, the trie is constructed and the failure nodes are computed in the constructor (while creating the object). The user can then search the text using the operator(). template <typename patIter> class aho_corasick { public: aho_corasick(patIter first, patIter last): pat_first(first), pat_last(last), head(std::shared_ptr<trie_node>(new trie_node)) { //first and last are pointers/iterators to the first and last patterns in the container gotoFn(head); failureFn(head); } ~aho_corasick () {}; template <typename corpusIter> corpusIter operator ()(corpusIter corpus_first, corpusIter corpus_last) //Note: using the same notation as used in the other search algorithms. Corpus- refers to the text to be searched. I've implemented this and would like to get feedback/suggestions on the code as well as the interface. Where should I put up the code for it to be reviewed ? Thanks, Meghana

1 0

boost [vmd]: configuration issue in Jamfile.v2 for Oracle Solaris Studio compiler
by Aparna Kumta 26 May '15

26 May '15

I am looking at my test run for vmd in develop branch. http://www.boost.org/development/tests/develop/developer/vmd.html under SunOS. My tests are run with cxxflags="-compat=5 -library=stlport4" as configured in user-config.jam An example of a test, http://www.boost.org/development/tests/develop/developer/output/oracle-spar… The test fails as follows: "CC" -std=c++0x -std=c++11 -compat=5 -library=stlport4 -xO4 -mt -erroff=%none -m32 -KPIC -DBOOST_ALL_NO_LIB=1 -DNDEBUG -I".." -c -o "/export/home/sstrunk-tester/boost_regression/boost_sparc-S2_stlport4/results/boost/bin.v2/libs/vmd/test/test_after_identifier_elem.test/sun-stlport4/release/threading-multi/test_after_identifier_elem.o" "../libs/vmd/test/test_after_identifier_elem.cpp" CC: -compat=5 can not be used with -std CC: -library=stlport4 cannot be used with -std=c++11 If I compile the test manually without '-std=c++0x -std=c++11', the test compiles OK. %CC -compat=5 -library=stlport4 -xO4 -mt -erroff=%none -m64 -KPIC -DBOOST_AL0%L_NO_LIB=1 -DNDEBUG -I.. -c -o ./test_after_identifier_elem.o ../libs/vmd/test/test_after_identifier_elem.cpp % It looks like boost_root/libs/vmd/test/Jamfile.v2 needs to be modified for this compiler. Any ideas on how this can be done? Thanks, Aparna

2 3

boost::bind C2664 error with two non-const references
by Nicolas FRANCOIS 25 May '15

25 May '15

Hi, Relatively to this thread http://lists.boost.org/Archives/boost/2015/03/220930.php and this correcting commit 42b5cef177603328ead66bc6a98a3067aebc433d, I still have errors using boost::bind. #include <boost/bind.hpp> #include <boost/function.hpp> struct A { void f(int&, std::vector<int*>&); }; int main(){ A a; auto f = boost::bind(&A:f, &a, _1, _2); } results in error C2664: cannot convert from 'const std::vector<int*> &' to 'std::vector<int*> &' Defining BOOST_NO_CXX11_RVALUE_REFERENCES solves the issue for now. Nicolas FRANCOIS Software Department L-ACOUSTICS Tel : +33 (0) 1 69 63 23 90 Fax : +33 (0) 1 69 63 69 64 www.l-acoustics.com<http://www.l-acoustics.com/> Please consider the environment before printing this email.

2 7

Environment Variables Library?
by Michael Ainsworth 24 May '15

24 May '15

StackOverflow regarding the (non) standardisation of the "setenv" function, does Boost provide a library to interact with environment variables? http://stackoverflow.com/questions/30292642/c-standard-library-stdsetenv-vs… Michael

10 34

[testing][CrystaX.NET] Missing header
by Andrey Semashev 23 May '15

23 May '15

Hi, Many of the CrystaX.NET testers fail to compile tests because of this error: fatal error: crystax/google/sys/select.h: No such file or directory See here for example: http://www.boost.org/development/tests/develop/developer/CrystaX-NET-apilev… Could this be fixed?

2 1

boostdep documentation?
by Robert Ramey 22 May '15

22 May '15

I am interesting in taking a look at boostdep. I see the code in tools/... but I don't see any documentation. Is there any? will there be in the future? Robert Ramey

2 3

Re: [boost] [Better Enums] Interest in/feedback on C++11 enums library
by Anton Bachin 22 May '15

22 May '15

I've been keeping away because I am doing a ton of work on the library, and I don't want to attract too much attention until the work is ready, since there are lots of changes. But, I think I should reply, and I will also give a brief update of the progress at the end of the message. > I suspect this code: > > Depth depth = default_<Depth>(); > > could be made to look like this: > > Depth depth = _default; > > > ie all enums have a constructor that takes a default_t type. The > constructor then calls default_<T>(). > Or something like that. And then change the names to get > > Depth depth = default_; // calls default_impl<T>(); That’s a good idea. I hadn't thought of such a constructor. I will try it out, but I am not sure that it would belong directly in the library, if that's what you mean. It's not clear where one should stop. Should there also be an "invalid" constructor for projects that have such a notion? Are there other special values we can't predict? Perhaps this could be achieved with some kind of extension facility. I will eventually be adding either support for subclassing, or extra macros, or some kind of template-based extensibility. To the other commenters: thanks :) As for progress: there are substantial improvements. - The entire interface is now constexpr, including string functions and iterators. - I ported the interface to C++98, though it still requires __VA_ARGS__. This makes the topic of this message inaccurate. Should I start a new thread for the new version when it's up? - The C++98 conversion means that, in theory, the library should work on MSVC down to VS2005. I will be testing that when I get my new notebook in a few days. If successful, Better Enums will be compatible with the 3 major compiler families. - Eliminated all weak symbols, leaving only standard C++. Some may be brought back later for optimization, but they are no longer required. - When compiling for C++11, there are no more implicit conversions to integers. - The library is now a single header file, containing both the C++11 version and the C++98 port, and all helper macros. - The documentation is getting a major improvement, so please don't look now. The all-constexpr version is unfortunately noticeably slower to compile. The performance test that was previously two times faster than including iostream is now twice as slow, but I can mitigate this with some combination of opt-in and optimization. Anton

1 0

[build][test][gsoc] question about compiling tests with multiple compile params using b2
by Damian Vicino 22 May '15

22 May '15

Hi, I’m working in the safe_float library for the GSOC. For testing I’m using the boost.test library and for building I’m using b2. The implementation have several pieces that are implemented in two flavours, one for compilers supporting FLOAT_ENV and one for those not supporting it. (this is a C++11 feature missed in at least clang and gcc compilers) Right now, the implementation is selected with an #ifdef and I #define them with a -D parameter. My config file for test is: using testing ; lib boost_unit_test_framework ; unit-test test : main-test.cpp [ glob *_test.cpp ] boost_unit_test_framework ; I guess I can generate 2 different executables using 2 targets, duplicating last line and adding something to tell it to pass -DFENV_AVAILABLE, but I couldn’t find how to do that. Having 2 executables for the tests and running them both will provide testing for both compilation paths (when using a compiler supporting FENV). Also, I’m wondering if B2 has the inteligence detect and pass a parameter when using a compiler supporting FENV. Is there any common approach for these situations where conditionally compiling based on a c++ feature support? In the case a Boost.Build needs to define a test for detecting if the compiler supports the feature (autoconf-like) it can be tested compiling a one-liner file: test.fenv.cpp #pragma STDC FENV_ACCESS ON When compiled: clang++ -c test.fenv.cpp test.clang.cpp:1:14: warning: pragma STDC FENV_ACCESS ON is not supported, ignoring pragma [-Wunknown-pragmas] #pragma STDC FENV_ACCESS ON The warning means the feature is not supported. Thanks for any guidance in this area, I’m pretty newbie with the b2 system. Best regards, Damian

2 1

[Better Enums] Interest in/feedback on C++11 enums library
by Anton Bachin 21 May '15

21 May '15

Hello, I’ve just released an enum library that takes advantage of constexpr functions and literal types to provide a nice declaration syntax and decent feature set: https://github.com/aantron/better-enums <https://github.com/aantron/better-enums> I’d like to get feedback on it from the experienced developers here at Boost. Is this approach useful? Are any major features missing? Would this be an interesting candidate for enums in Boost? I am very willing to do further development on this project. The library's basic features are string conversions, value and name listing, some type safety, and a declaration syntax that is based on built-in enums and is easy to learn and use. A much more "advanced” feature is that the generated class is a literal type, and almost everything is constexpr. Here is a simple example, that takes advantage of this, of a compile-time encoding of project policy: https://github.com/aantron/better-enums/blob/master/example/6-traits.cc <https://github.com/aantron/better-enums/blob/master/example/6-traits.cc> . Once I make the iterators constexpr as well, by providing a way to increment them other than mutation (++), it will be easy to write rather involved compile-time algorithms that process Better Enums declarations. Here is an example of a whole bunch of simple compile-time processing already possible: https://github.com/aantron/better-enums/blob/master/example/4-constexpr.cc <https://github.com/aantron/better-enums/blob/master/example/4-constexpr.cc> . Some of that could be useful when C++ declarations are generated by script. The library is all standard C++11 (to the best of my knowledge), except for the usage of weak symbols for some generated constexpr static arrays. I have tested it successfully on clang and g++, but I would need help getting access to more compilers. I believe weak symbols are not a problem for MSVC, but I still don’t believe the library will compile on MSVC since I don’t think MSVC supports enough of C++11 yet. Performance is what I would call excellent. I compared compilation times of these two files to each other: https://github.com/aantron/better-enums/blob/master/test/performance/4-decl… <https://github.com/aantron/better-enums/blob/master/test/performance/4-decl…> https://github.com/aantron/better-enums/blob/master/test/performance/5-iost… <https://github.com/aantron/better-enums/blob/master/test/performance/5-iost…> The first file includes enum.h and declares a bunch of enums, and the second merely includes iostream. On my machine, clang compiled all those enums in about half the time it took to process iostream. g++ was faster on iostream, but only slightly. Using a lot of compile-time expressions would have additional cost, but it has been too small to measure for “realistic” examples from my own usage. I haven’t yet made an example that repeatedly deals with a very large enum at compile time to properly measure that impact. I’ve also explored an alternative interface where the constexpr properties provided by the library are in a traits class parametrized by a normal C++11 enum class, but the interface seemed too verbose. There is also a bitset type that has a very slightly nicer interface than std::bitset for usage with enums, but I didn’t think the improvement was worth the user’s learning effort. I can put these in branches if there is interest, however. Please let me know what you think. Best, Anton

5 4

[BOOST_FOREACH] Problem to iterate on a non-copyable container...
by nico 21 May '15

21 May '15

I'm not sure of the title, because I'm not sure the issue comes from the "copyablility" of my container. I tryied quite everything but I can't get rid of this error. Here is a simplified version of my code (please do not challenge the class design, I really would like to keep the end-used syntax in the BOOST_FOREACH): template <typename T> class MyContainer { public: typedef typename std::vector<T>::iterator iterator; typedef typename std::vector<T>::const_iterator const_iterator; MyContainer(std::vector<T>& vec, boost::mutex& mutex) : m_vector(vec), m_lock(mutex) { } iterator begin() { return m_vector.begin(); } const_iterator begin() const { return m_vector.begin(); } iterator end() { return m_vector.end(); } const_iterator end() const { return m_vector.end(); } private: std::vector<T>& m_vector; boost::lock_guard<boost::mutex> m_lock; }; template <typename T> struct GetContainer { GetContainer(std::vector<T>& vec, boost::mutex& mutex) : m_vector(vec), m_mutex(mutex) { } MyContainer<T> Get() { return MyContainer<T>(m_vector, m_mutex); } std::vector<T>& m_vector; boost::mutex& m_mutex; }; int main() { std::vector<int> v; v.push_back(1); v.push_back(2); boost::mutex m; GetContainer<int> getter(v, m); BOOST_FOREACH(int i, getter.Get()) { std::cout << i << std::endl; } return 0; } The compiler complains about not having a copy constructor for MyContainer<int>::MyContainer(const MyContainer<int>&) I also have : error: no matching function for call to ‘MyContainer<int>::MyContainer(boost::foreach_detail_::rvalue_probe<const MyContainer<int> >::value_type)’ I follow the extensibility tips: http://www.boost.org/doc/libs/1_58_0/doc/html/foreach/extensibility.html#fo… But, making MyContainer<T> : private boost::noncopyable doesn't solve the issue. Nor defining the function boost_foreach_is_noncopyable or specializing the template struct is_noncopyable for MyContainer<int> (in fact, how would I specialize this template for a template type ?) Last "tip": If I remove the mutex and the lock from everywhere (I just pass the vector to GetContainer and to MyContainer<T>, it works. But it doesn't work if I make MyContainer<T> : private boost::noncopyable (I expected it should, so I'm not sure my problem is with BOOST_FOREACH, but maybe because I return a copy of MyContainer with my getter ?) I thank you if you read me until here, and thanks in advance for help.

3 4

What does "xml this : this.qbk" do?
by Peter Dimov 21 May '15

21 May '15

Documentation Jamfiles often contain a line like xml core : core.qbk ; What does this line do? Is "xml" a rule? I haven't been able to find it anywhere.

2 1

Questions about upcoming review of Boost.AFIO
by Niall Douglas 21 May '15

21 May '15

Dear list, Ahmed has volunteered to review manage AFIO (thanks Ahmed!), however I wanted to get the list's feedback on some things first. 1. After collecting feedback at C++ Now from members of WG21 on the shape and preferred future of a race free Filesystem TS, the next iteration of AFIO will have a radically different API consisting of the form: std::vector<afio::future<T>> afio::batch(...) afio::future<T> afio::async_io_handle::operation(inputs) noexcept(is_nothrow_move_constructible<T>) T afio::io_handle::operation(inputs) T afio::io_handle::operation(error_code &ec, inputs) The internal engine is the same very well tested code, just the API is very different from before. The current API was forced by VS2010's limitations and the lack of constexpr in MSVC - now VS2015 RTM has C++ 11 constexpr, I can adopt the custom future based API I always originally wanted. This new API will require C++ 14 in the compiler. Question: Given the API will so radically change, is now the time for a community review? Do note that APIBind allows me to support the existing API and the new API concurrently without issue. 2. AFIO requires APIBind which is a separate library. APIBind is not yet in the review queue and it is pending me writing up its documentation and a more useful unit test suite. Is this a problem? Do note that you the user of AFIO will never need to know about APIBind, it is entirely an internal implementation detail. Comments appreciated. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

8 10

More cool free github tooling: https://reviewable.io/
by Niall Douglas 21 May '15

21 May '15

Dear list, I'm not sure about other libraries, but in Boost.Thread Vicente the primary maintainer does the lion's share of dealing with pull requests but he occasionally needs someone else to review a patchset or a pull request before it can be merged. Github's facilities for this are okay - you can comment per line of a pull request, and overall. It works, though one wishes for something more gerrit like. So enter a new free tool with github integration: https://reviewable.io/. One click install into your github project. You now gain an alternative UI for pull requests, one which is much better than the default Github UI, specifically: * Per file review gating like gerrit * Can publish a group of per-line comments as a single thing (and just one email notification) * Doesn't hide deleted change history * Diffs are much better calculated and presented I've turned it on for AFIO. We'll see how it goes. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

1 0

Some statistics about the C++ 11/14 mandatory Boost libraries
by Niall Douglas 21 May '15

21 May '15

Tomorrow at 11am after Eric's talk I'll be presenting at C++ Now a review of the upcoming C++ 11/14 mandatory Boost libraries. I looked at fifteen libraries and decided ten were worth further investigation. I'm sure you all remember my colour coded ranking of those ten libraries by "nearness" to entering Boost: https://goo.gl/6l1KiH I sadly only have time to review four of those libraries during my talk, but one (APIBind) enables an alternative Boost 2.0 approach and I will spend 45 mins on that library alone. And here is my alternative Boost 2.0 vision: Boost 2.0 is a alternative distro of modular standalone Boost libraries which can be each downloaded separately. Each has contemporary per commit CI testing and is nightly dashboarded by quality score by a web service under the 19 quality score headings listed at https://svn.boost.org/trac/boost/wiki/BestPracticeHandbook (still unfinished, but nearly there). APIBind allows the library end user to dependency inject what dependencies that library uses. This allows a Boost library, in a single codebase, to be part of both the monolithic Boost 1.x distro and to be modular and standalone and part of the Boost 2.x distro. Motivated library maintainers port their Boost 1.x library to the APIBind platform, and therefore can be part of both 1.x and 2.x distros if they want. Those libraries not ported to APIBind remain in the 1.x distro, which I would assume will gradually fade into obsolescence over time. This makes sense, as if a maintainer is not motivated to do the port then it seems proper that library should gracefully deprecate. There is some empirical data supporting the inevitability of this alternative vision of Boost 2.0. Of the ten libraries I examined in any detail: * Just 1.5 libraries have any dependencies on Boost headers at all (the 0.5 is because that library is currently removing its Boost dependencies). * Just 3 libraries can use Boost.Test. * Just 3 libraries use Boost Docs. * Just 2 libraries require using Boost.Build. The rest are header only, or use cmake. * Just 6 libraries use Travis/Appveyor for free CI testing on Linux, OS X and Windows. * Just 3 libraries use valgrind as part of their unit testing (two are mine!). * Just 3 libraries use coveralls for coverage reporting (two are mine!). Personally speaking, I think the new library authors are overwhelmingly voting for a complete break with Boost 1.x. It makes no sense to bundle these new libraries into a 1.x monolithic distro when they have no dependencies on Boost. I believe now is the time we start establishing the infrastructure to shape the new Boost 2.0 distro instead of wasting resources on trying to refactor the 1.x distro. APIBind is there for maintainers wanting to be part of both distros. Let's make a clean break. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

28 133

Deprecation Policy
by Rob Stewart 21 May '15

21 May '15

Some Boost libraries are unmaintained, some are under-maintained, and others have been replaced by newer libraries or by the Standard Library. Boost needs to decide whether to deprecate such libraries, and if so, how and when to do it. Please consider my initial thoughts below and provide ideas on such a policy. I will try to capture your ideas and create a policy statement for later review. It would seem obvious that unmaintained libraries should be deprecated, but a library that works, even if it has some known bugs, doesn't grow worse over time. Thus, if an unmaintained library was included in one Boost release, continuing to include it is no worse than before. That implies that deprecating Unmaintained libraries is not a given. Another issue is deciding when a library is unmaintained. Boost prefers that library authors and maintainers seek a replacement when no longer able to provide maintenance. Unfortunately, that doesn't always happen. Thus, establishing criteria by which to judge a library as unmaintained is warranted. Many continue to use C++03 and benefit from the presence of libraries that only support that language. I think it a non-starter to suggest that a library is unmaintained, or under-maintained, because it hasn't been updated to use C++11/14. Indeed, a replacement library may be the better way forward, while the old library might remain in Boost releases. Some have suggested that libraries with Standard Library equivalents be considered deprecated. Note that such libraries provide equivalent or similar functionality for older compilers, so I think that they should be treated the same as C++03-only libraries. Libraries that have superior replacements in Boost releases seem like obvious candidates for deprecation. There is precedent for that: Boost.Signals was deprecated in favor of Boost.Signals2. There are some likely libraries in this category, such as Boost.Lambda. Once we reach consensus on how to identify libraries to deprecate, we then must decide on the process. How long should a deprecated library be released before it is removed from Boost releases? How do we mark deprecated libraries? What do we do with deprecated libraries that have been removed from Boost releases? ___ Rob (Sent from my portable computation engine)

12 33

[preprocessor] Link to Boostpro site for introduction to preprocessor metaprogramming
by Edward Diener 20 May '15

20 May '15

The preprocessor documentation has a link to the Boostpro site which had an html version of the Appendix A of "C++ Template Metaprogramming" by Abrahams and Gurtovoy. Appendix A is "An Introduction to Preprocessor Metaprogramming", which is all about Boost PP. Alas Boostpro is no more and the link in the preprocessor documentation goes nowhere. I can remove the link and any notice of the introduction. But If either David Abrahams or Aleksey Gurtovoy are still around it would be nice to get the html pages which existed before and incorporate them into the Boost PP docs. Does anyone know how to contact either of them ? I can try their addresses in maintainers.txt but I do not want to directly encroach on their privacy if there is a better way.

2 4

Interest in non-intrusive signal/slot lib?
by Emil Dotchevski 20 May '15

20 May '15

Hello, I realize that Boost has Signals library already, but I've implemented a non-intrusive one which approaches the problem differently, and I'm pretty sure that there is no overlap between the two. It turned out more generic than I originally anticipated, so I thought I'd ask if others would find it useful as well. Specifically I was motivated by wanting to use Qt without MOCing. I asked the Qt community if that was possible which generated several rather annoyed negative responses. :) The issue is that while in Qt it's possible to use any function as a Slot, to define a new Qt signal for an existing Qt type one needs to derive from the Qt type, define the signal (as a member function) and do the MOC dance -- which I wanted to avoid. The result is a small, non-intrusive signals/slots library that allows objects of any type to be used as signal emitters, e.g. one of the included examples shows how signals can be emitted by a Windows HWND object. Documentation and source code released under the Boost license can be found here: http://www.revergestudios.com/boost-synapse/. Thanks, Emil P.S. Thanks to Peter Dimov for his feedback and for coming up with the name Synapse. :)

9 48

Version mismatch on develop
by Peter Dimov 20 May '15

20 May '15

On the current develop, autolink wants to link to (for instance) libboost_filesystem-vc80-mt-s-1_59.lib, but b2 builds libboost_filesystem-vc80-mt-s-1_58.lib. That's because BOOST_VERSION has been updated to 1.59 in boost/version.hpp, but is still 1.58 in Jamroot.

2 1

[type_traits] A bug in has_nothrow_default_constructor
by Andrzej Krzemienski 20 May '15

20 May '15

Hi All, I have submitted a new ticket: https://svn.boost.org/trac/boost/ticket/11324 Given the information floating around that Boost.TypeTraits are unmaintained and that they are to be replaced with the rewrite, is there any chance that this is fixed, or at least the test case added to regression matrix? BTW, does type_traits v2 handle this case correctly? Regards, &rzej

2 2

[Testing] Android clang tests
by John Maddock 20 May '15

20 May '15

Since all the Android/clang tests which use PCH are failing, can we either: * Change the build options to disable PCH, or better, * Fix the clang toolset? Someone who understands clang on Android would have to do the latter. See http://www.boost.org/development/tests/develop/developer/output/CrystaX-NET… for an example fail. Many thanks, John.

3 4

crash in boost/date_time/microsec_time_clock.hpp:70 v1.55
by George Georgiev 20 May '15

20 May '15

Hi, I am having crash in in local_time () at boost155_lin32_gcc480//include/boost/date_time/microsec_time_clock.hpp:70 I can call this in isolation and there is no issues, but in the production calls it crashes 100% reproducible with Program terminated with signal SIGABRT, Aborted. The only difference I could think about it is that the call is made from a dynamically loaded library. Is there any known issue about this? Thanks, George

4 3

Getting a trac id
by Steven Ross 19 May '15

19 May '15

I have a bug filed against my library, but with no trac ID I can't modify the bug. How do I get a trac ID?

2 1

RemoteCall framework for RPC
by Alex Marmer 19 May '15

19 May '15

Hello, I created a C++ framework RemoteCall which allows to use RPC the same way as local C++ calls are used. For declaration, implementation and call used macros: DECLARE_REMOTE, IMPLEMENT_REMOTE, CALL_REMOTE.Return and parameters (In and In/Out) can be any type except pointers. For instance: std::tuple<in, bool> DECLARE_REMOTE(Test)(std::vector<std::string>& vInOut, const std::wstring& sIn). Implementation is on https://github.com/amarmer/RemoteCall Would it be useful to add this framework in Boost? Sincerely,Alex

4 8

[all][testing] Regression summary upgrades
by Adam Wulkiewicz 18 May '15

18 May '15

Hi, Recently the regression summary was upgraded. The cells corresponding to the failing tests can have names comp, link, run or fail. This way we can see what's the nature of the failure without going into details. See, e.g. the tests for Math: http://www.boost.org/development/tests/develop/developer/math.html The last category of failures (generic "fail") is for the others or unknown. Currently the "Lib" errors are falling into this category. There are some in Math, e.g.: http://www.boost.org/development/tests/develop/developer/output/CrystaX-NET… So we could mark them explicitly as "lib" failures and then the other/unknown failures could be marked as "unkn" or left as it is now - "fail". This has sense if there can be other "types" of failures, e.g. caused by some error in the testing scripts, Build or Regression, for which the reason is somehow unknown. Though I haven't seen them. I propose to go further with this and to mark the compilation failures for which we know the reason of the failure in a special way: - "file" - file too big (reported on Windows, e.g. http://www.boost.org/development/tests/develop/developer/output/MinGW-w64-4…) - "time" - time limit exceeded (e.g. http://www.boost.org/development/tests/develop/developer/output/teeks99-03b…) I saw them in many libraries and I think it would be very useful for libraries having many tests like Math or Geometry. The other types of failures I could think of aren't that important for me personally but maybe someone could appreciate them, e.g. the compilers developers: - "ierr" or "cerr" - internal compiler error or segmentation fault during compilation (e.g. http://www.boost.org/development/tests/develop/developer/output/PNNL-RHEL6_… or http://www.boost.org/development/tests/develop/developer/output/teeks99-03h…) - "segf" - segmentation fault during run (http://www.boost.org/development/tests/develop/developer/output/BenPope%20x…) Furthermore I propose to use various colors for different failure reasons. You can see the examples here: https://github.com/awulkiew/summary-enhancer https://github.com/awulkiew/summary-enhancer/tree/master/example/pages Of course the colors could be changed. We should be able to modify them in the master.css file. In the examples above they are varying much to make a clear distinction between them. But if you like the yelow collor then all of the new failures could be yelowish with a slight accent of another color, e.g. compilation errors could be yellow with orange accent and "time"/"file" errors with green accent. Regards, Adam

11 27

Spirit 3.0.0
by Joel de Guzman 18 May '15

18 May '15

Hello! C++ Now 2015. Today is the official release of Spirit X3, aka Spirit 3.0.0. X3 will be in beta, coexisting side by side with Qi, Karma, Lex and Classic. If you are a Qi user. The best place to start are the examples, especially rexpr and x3 fun. Remember to use a compiler with c++14 capabilities: clang 3.4 or greater gcc 4.9 or greater Follow this link for more: http://boost-spirit.com/home/2015/05/16/spirit-3-0-0/ Cheers! -- Joel de Guzman http://www.ciere.com http://boost-spirit.com http://www.cycfi.com/

4 5

[type_traits] Time to upgrade to "version 2" ?
by John Maddock 17 May '15

17 May '15

Now that the release is out it's decision time: I'd like to merge the "Version2" branch of type_traits to develop, it passes all the tests, and I've been using it exclusively for testing and development locally for a few months now without issues. But.... it's a big change with the potential to break a lot of folks stuff if things go wrong given that this is such a core component. To recap the main advantages are: * Removed all the redundant cruft that's no longer required for old/broken compilers we don't support anymore anyway. * Very nearly dependency free (other than Config), there's just comon_type which still has dependencies elsewhere - and even that disappears for a C++11 compiler. * Much cleaner, easier to understand code, now that the horrid obfuscating macros introduced by MPL have gone. * Fewer template instantiations than before as much of the indirection / forwarding templates have been removed. * As a result code using these headers should be somewhat faster to compile - both with fewer template instantiations, and a much lighter #include load. Note that as a result of this change, a number of undocumented headers which were none the less being used in Boost have been deprecated. The headers still exist, but warn loud and clear about their deprecated status, so folks will get a lot of warnings to begin with. I know Edward Diener has submitted some PR's to fix these, but I plan to make a concerted attack on any remaining once the new version is in develop. So here's the question, how do we proceed? My thoughts are to basically go ahead and merge, but not merge to master until after the next release at the earliest to give everything a chance to bed down, and the required changes in other libraries to filter through. Or we could have some sort of mini-review either formally or informally to check things out before the merge - of course folks are most welcome to do this anyway! Let me know what you think, best, John.

9 14

[type_traits] difference in decay semantic between boost and standard library
by Anton Bikineev 17 May '15

17 May '15

Hi Boost, Is it expected semantic of boost::decay not to strip top-level constness? Thanks.

1 0

[testing] Regression unresolved issues page
by Adam Wulkiewicz 15 May '15

15 May '15

Hi, The unresolved issues page seems to be outdated (only msvc-8.0 failures can be found there): http://www.boost.org/development/tests/develop/developer/issues.html It's because from all required toolsets mentioned here: https://github.com/boostorg/boost/blob/develop/status/explicit-failures-mar… only the msvc-8.0 is currently tested. The required compilers are quite old ones. I'm not sure how we should addres this issue. I get an impression that in the past this page was used differently than it is now. I'm not sure how though. The ToC/menu is also missing. Anyway, we could: - add only some specific, more modern required toolsets to the explicit-failures-markup.xml - ignore the required toolsets entries and display the issues detected in a library for all non-disabled toolsets - remove the issues page I'd probably go with the second option and treat this page as a complement of the regression matrix. What do you think? Regards, Adam

1 0

[ELFIO] - New library proposal
by Serge Lamikhov-Center 15 May '15

15 May '15

Hello Boost community! I'd like to determine interest in possible new library submission. ELFIO is header-only C++ library that provides a simple interface for reading and generating files in ELF binary format. It is a mature library and is in use by a number of open source and commercial projects. It is a part of some Linux distributions as well as Cygwin project. Would you please have a look at the library's home page located at: http://elfio.sourceforge.net Documentation: http://elfio.sourceforge.net/elfio.pdf Library download: http://sourceforge.net/projects/elfio/files/ELFIO-sources/ELFIO-3.1/ and its source code available through: http://github.com/serge1/ELFIO Please share your opinion on making this library be a part of the Boost. Thank you and Best regards, Serge

5 6

[test] Problem with BOOST_TEST_MESSAGE
by Edward Diener 15 May '15

15 May '15

In testing out a library with Boost.Test I want to inject informational messages that will appear in the output of the test results. When I use BOOST_TEST_MESSAGE with the correct logging level my message appears in the output if there is some sort of Boost.Test error during my tests. However if my unit test does not have a Boost.Test error my BOOST_TEST_MESSAGE does not appear. Needless to say I always want my BOOST_TEST_MESSAGE messages to always appear in the output. Is there a solution to this ?

4 12