June 2015 - Boost - lists.boost.org

A GUI Library
by jinhao 09 Nov '17

09 Nov '17

Hi, all I am developing a GUI library, it takes aim at easy-to-use and portable library for modern C++ methods. The project at http://stdex.sourceforge.net A git repository at http://nanapro.codeplex.com A brief at http://nanaproject.wordpress.com/2011/12/16/preliminary-study-of-nana-c-lib… Is there any interest in this library? Regards Jinhao

8 8

Re: [boost] Boost CRC maintainer (Daryle Walker) missing in action?
by Olaf van der Spek 19 Jun '17

19 Jun '17

Hi Daryle, Any luck on your new setup? Gr, Olaf On Mon, Nov 28, 2011 at 1:11 AM, Daryle Walker <darylew(a)gmail.com> wrote: > I can look at it once I've finished my new setup. > > I had to reset my computer after a partial crash years ago. I never > got around to recreating my programming setup. My computer had been > at its maximum Operating System level back then, which is now 3 > versions behind. For the past few months, I've had my sister's old > laptop, with Windows Vista, and am trying to add a programming setup > to it now. > > > On Tue, Nov 22, 2011 at 7:18 AM, Beman Dawes <bdawes(a)acm.org> wrote: >> Hi Daryle, >> >> This guy has volunteered to take over maintenance of Boost CRC. Should >> we take him up on his offer? > >> ---------- Forwarded message ---------- >> From: >> Date: Wed, Nov 2, 2011 at 7:51 AM >> Subject: [boost] Boost CRC maintainer (Daryle Walker) missing in action? >> To: boost(a)lists.boost.org >> >> >> Hi, >> >> It looks like the Boost CRC maintainer (Daryle Walker) is missing in action? >> >> No response to tickets from the past 3 years. What's the procedure in this case? >> >> https://svn.boost.org/trac/boost/ticket/2492 >> https://svn.boost.org/trac/boost/query?component=crc&col=id&col=summary&col… > > -- > Daryle Walker > Mac, Internet, and Video Game Junkie > darylew AT gmail DOT com -- Olaf

2 2

bad include guards
by Steven Watanabe 26 Jan '17

26 Jan '17

AMDG The following pairs of files have identical include guards ./boost/concept_check/general.hpp ./boost/concept/detail/msvc.hpp ./boost/concept_check/msvc.hpp ./boost/concept/detail/msvc.hpp ./boost/filesystem/cerrno.hpp ./boost/cerrno.hpp ./boost/interprocess/containers/tree.hpp ./boost/interprocess/containers/detail/tree.hpp ./boost/mpl/min_max.hpp ./boost/mpl/max.hpp ./boost/mpl/vector/aux_/front.hpp ./boost/mpl/list/aux_/front.hpp ./boost/multi_index/identity_fwd.hpp ./boost/multi_index/identity.hpp ./boost/python/pointee.hpp ./boost/python/detail/pointee.hpp ./boost/spirit/phoenix/closures.hpp ./boost/lambda/closures.hpp ./boost/xpressive/proto/v1_/proto_typeof.hpp ./boost/xpressive/proto/proto_typeof.hpp ./libs/config/test/boost_no_dep_nested_class.ipp ./libs/config/test/boost_has_vc6_mem_templ.ipp ./libs/config/test/boost_no_mem_templates.ipp ./libs/config/test/boost_has_vc6_mem_templ.ipp ./libs/config/test/boost_no_std_allocator.ipp ./libs/config/test/boost_has_vc6_mem_templ.ipp ./libs/conversion/test.hpp ./libs/any/test.hpp ./libs/interprocess/example/print_container.hpp ./libs/interprocess/example/printcontainer.hpp ./libs/interprocess/test/expand_bwd_test_template.hpp ./libs/interprocess/test/allocation_test_template.hpp ./libs/interprocess/test/printcontainer.hpp ./libs/interprocess/example/printcontainer.hpp ./libs/interprocess/test/print_container.hpp ./libs/interprocess/example/printcontainer.hpp ./libs/iostreams/test/detail/utf8_codecvt_facet.hpp ./boost/detail/utf8_codecvt_facet.hpp ./libs/regex/test/regress/test_regex_search.hpp ./libs/regex/test/regress/test_partial_match.hpp ./libs/serialization/test/C.hpp ./libs/serialization/test/A.hpp ./libs/xpressive/perf/regex_comparison.hpp ./libs/regex/performance/regex_comparison.hpp ./tools/inspect/time_string.hpp ./tools/common/time_string.hpp In Christ, Steven Watanabe

5 8

[multiprecision] uses boost::math::gcd without including the header
by Peter Dimov 04 Jan '16

04 Jan '16

include/boost/multiprecision/cpp_int/misc.hpp uses boost::math::gcd (and lcm), but does not include common_factor_rt.hpp.

2 2

[variant] Opinion on boost::safe_get<> and default boost::get<> behavior
by Antony Polukhin 18 Dec '15

18 Dec '15

Hi all, I'm in doubt and would like to hear opinions on the following issue. boost::get for boost::variant was not making any compile time checks, resulting in runtime errors where a compile time error must be: boost::variant<int, string> v(100); boost::get<bool>(&v); // returns NULL instead of compile time error boost::get<bool>(v); // throws exception on runtime instead of compile time error Now we have an implementation of compile time checked get in a separate branch at git: boost::variant<int, string> v(100); boost::safe_get<bool>(&v); // compile time error boost::safe_get<bool>(v); // compile time error boost::unsafe_get<bool>(&v); // returns NULL instead of compile time error boost::unsafe_get<bool>(v); // throws exception on runtime instead of compile time error I'm in doubt, what the default behavior of boost::get must be: * safe_get behavior is much closer to Standard Library behavior (just like std::get for tuples) and allows to avoid errors in user code * unsafe_get behavior is same as behavior of old boost::get and won't break user's code if boost::get is used in some generic contexs What's your opinion? -- Best regards, Antony Polukhin

10 13

[thread] Do we can a non backward compatible version with non-blocking futures?
by Vicente J. Botet Escriba 18 Oct '15

18 Oct '15

Hi, in Boost 1.58 I fixed some issues as the result of the async and future<T>:then() was not a blocking future as the documentation described. However the implementation is horrible and I suspect that it is subject to deadlocks. BTW, I added already some fixes on the develop branch. Sometime ago I started in a branch an implementation that don't use blocking futures [1]. Well the implementation is also horrible after making futures non-blocking, but less ;-) The problem is that now I have some issues with the executors :( Anyway, Gor has told me that with the blocking implementation he is unable to define await_suspend (using resumable functions) >It is just if .then returns a blocking future, I cannot subscribe a callback to .then in await_suspend. >await_suspend(f, cb) { > f.then(cb); >} &will block here preventing coroutine from suspending I don't know yet if he will reach to configure boost::future<T> on the non-blocking branch. My question is if the Boost community will accept (or even wants) a breaking change on a near release (when I would reach to fix the executors issues) including non-blocking futures instead of the current blocking futures. Best, Vicente [1] https://github.com/boostorg/thread/tree/feature/non_blocking_futures

3 13

[WG21 mailing] N4453 Resumable expressions
by Niall Douglas 15 Oct '15

15 Oct '15

I'm finding Chris' paper on resumable expressions instead of compiler magic created resumable functions awfully compelling: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4453.pdf I essentially proposed the same with my functionally composed constexpr basic_future design some months ago. Would anyone else like to comment on this library based instead of compiler based resumable execution? I'm not against some compiler support for resumable execution, but I am finding the await based proposal highly problematic, and Chris does an excellent job in summarising my own thoughts on what's wrong with it. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

10 17

"Simple C++11 metaprogramming"
by Peter Dimov 22 Aug '15

22 Aug '15

I've recently made the mistake to reread Eric Niebler's excellent "Tiny Metaprogramming Library" article http://ericniebler.com/2014/11/13/tiny-metaprogramming-library/ which of course prompted me to try to experiment with my own tiny metaprogramming library and to see how I'd go about implementing tuple_cat (a challenge Eric gives.) Ordinarily, any such experiments of mine leave no trace once I abandon them and move on, but this time I decided to at least write an article about the result, so here it is, with the hope someone might find it useful. :-) http://pdimov.com/cpp2/simple_cxx11_metaprogramming.html

17 55

[context] msvc /SAFESEH
by Jeff Flinn 12 Aug '15

12 Aug '15

I need to build my application with /SAFESEH which uses boost coroutine which uses context. I'm getting the following link errors: 1>libboost_context-vc100-mt-gd-1_53.lib(jump_i386_ms_pe_masm.obj) : error LNK2026: module unsafe for SAFESEH image. 1>libboost_context-vc100-mt-gd-1_53.lib(make_i386_ms_pe_masm.obj) : error LNK2026: module unsafe for SAFESEH image. I've built boost static libs with the same MSVC vesion and options (sans /SAFESEH as it's not a compile/lib option) Compiler/linker versions: Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 16.00.40219.01 for 80x86 Microsoft (R) Incremental Linker Version 10.00.40219.01 Has anyone run into this and resolved the error? Any insight is appreciated. Thanks, Jeff

3 9

Review Request: QVM (generic Quaternion, Vector and Matrix operations library)
by Emil Dotchevski 04 Aug '15

04 Aug '15

Boost QVM defines a set of generic functions and operator overloads for working with quaternions, vectors and matrices of static size. The library also defines vector and matrix data types, however it allows users to introduce their own types by specializing the q_traits, v_traits and m_traits templates. Online documentation and a link to download the source code under the Boost license is available at http://www.revergestudios.com/boost-qvm/. I would like to thank Adam Wulkiewicz for volunteering to be the review manager for QVM and for his valuable initial feedback. Thanks, Emil Dotchevski

13 30

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

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

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

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

[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

[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

[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

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