June 2015 - Boost - lists.boost.org

[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 28 Jun '15

28 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