June 2015 - Boost - lists.boost.org

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