- Boost - lists.boost.org

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