- Boost - lists.preview.boost.org

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

08 Jun '15

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

23 76

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

08 Jun '15

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

1 0

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

08 Jun '15

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

7 12

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

08 Jun '15

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

9 38

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

08 Jun '15

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

4 10

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

08 Jun '15

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

7 28

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

07 Jun '15

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

2 3

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

07 Jun '15

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

5 19

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

06 Jun '15

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

8 13

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

06 Jun '15

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

1 0

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

06 Jun '15

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

2 1

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

05 Jun '15

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

1 0

[metaparse] review
by Andrzej Krzemienski 05 Jun '15

05 Jun '15

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

2 5

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

04 Jun '15

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

5 4

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

04 Jun '15

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

2 1

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

04 Jun '15

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

8 19

[metaparse] review
by Gordon Woodhull 04 Jun '15

04 Jun '15

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

2 5

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

03 Jun '15

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

2 1

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

03 Jun '15

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

1 1

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

02 Jun '15

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

1 0

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

02 Jun '15

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

2 1

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

02 Jun '15

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

8 12

Running regression tests locally
by Andrzej Krzemienski 01 Jun '15

01 Jun '15

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

2 1

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

01 Jun '15

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

2 2

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

01 Jun '15

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

4 5