- Boost - lists.boost.org

[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