- Boost - lists.preview.boost.org

'Fibre safe optimisations' with gcc/clang (non Windows target) and Boost.Context
by james 15 Oct '17

15 Oct '17

I was considering whether I could/should build an actor system on Rust rather than C++, since it would be an interesting exercise for me. And then I found this article: https://www.reddit.com/r/rust/comments/56wgzq/status_of_coroutines/ In particular: > we noticed that the Rust stdlib is actually using TLS (!) to implement exceptions It seems to me that in practice other compilers might use some sort of thread-local hook for exceptions, whether it is TLS or something lower-level that supports TLS. And that the issue is whether the compiler will assume that the address of the TLS (or thread information block etc) is volatile, or can be cached in a stack frame or register across calls. It seems to me that any such caching of an address might cause difficulty, not just in Rust but also other languages. Microsoft's compiler explicitly has a switch for 'fibre safe optimisations' that disables such caching. The worry I have is code like this: void foo() { try { A() } catch (...) {} B(); // Can switch the context to another underlying OS thread try { C() } catch (...) {} } I am concerned that information about exception handling that was acquired for the first try block, might be retained in the frame and reused in the second try block. and the information might be captured in the frame and/or registers that get saved in the context, but in an arbitrary way. I suspect that access to explicit ABI TLS or C++ thread local is also impacted, although it might be easier to avoid. I guess its not a complete show-stopper if we ensure that fibres never migrate between OS threads, but that is somewhat inconvenient. So - is this actually a Rustc specific issue?

1 0

printf official specs or docs, ISO C99, and C++
by James E. King, III 14 Oct '17

14 Oct '17

I found https://svn.boost.org/trac10/ticket/10541 today and my guess is Boost.Format hasn't been updated to support the ISO C99 extensions, or the Microsoft type formats. Before any work is done on this, I'm looking for any official C++ documentation related to printf support requirements. For example the compatibility section in http://www.cplusplus.com/reference/cstdio/printf/ indicates certain language levels have requirements. Thanks, Jim

3 3

[build] Building library with vc++ 64-bit does not find vcvarsall.bat
by Edward Diener 13 Oct '17

13 Oct '17

If I build any library with any version vc++ 64-bit compiler, by using address-model=64, the vcvarsall.bat is looked for at, for example with msvc-14.0, C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/bin/vcvarsall.bat and is not found. Naturally this leads to basic compilation failures. The path for vcvarsall.bat for msvc-14.0 is C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/vcvarsall.bat instead. All versions of vc++ follow this path structure for vcvarsall.bat Building with any version of vc++ 32-bit, by not specifying the address-model, works correctly.

3 4

1.65.1 as modular packages on Conan.io
by Rene Rivera 13 Oct '17

13 Oct '17

Following on with the announcement before CppCon of the 1.64.0 modular packages here we are with more. I'm pleased to announce that the 1.65.1 Boost C++ Libraries are now available individually using the Conan package manager. There's even some improvements for the 1.64.0 package also :-) Find out more from the Bincrafters post here <http://bit.ly/2g6VEpp>[1]. For help using the packages you can bug the Bincrafters team in the #Conan CppLan Slack channel <http://bit.ly/2ykeqC0>[2]. Conan is a C/C++ (and more) package manager that supports an open ended set of build system and tool integrations including: VisualStudio, Xcode, CLion, Ninja, QMake, Premake, and yes even CMake <http://bit.ly/2xzhpbg>[3]. [1] <https://bincrafters.github.io/2017/10/13/Conan-Packages-Boost-1-65-1/> [2] <https://cpplang.now.sh/> [3] <http://docs.conan.io/en/latest/integrations.html> -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net

1 0

Maintainers: Adding Coverity Scan to your library
by James E. King, III 12 Oct '17

12 Oct '17

I have completed the work necessary to add Coverity Scan to Boost.Uuid and wanted to share the steps involved. This work can be carried into other libraries fairly easily. 1. Go to Coverity Scan: https://scan.coverity.com/ 2. Sign up/in with your Github account. 3. Create a project for your boostorg/library. It will take about 24 hours for them to activate your account so that you can use the results browser. To run a coverity scan manually: 1. Check out your project master (or whatever branch you want to scan). 2. cd into BOOST_ROOT (where "libs/" is located) 3. Run the libs/uuid/covscan.sh script with the following environment variables set: A. COVERITY_SCAN_TOKEN: the project token in coverity scan B. COVERITY_SCAN_NOTIFICATION_EMAIL: your email C. SELF: your library name, for example SELF=uuid for Boost.Uuid 4. You will need to clean up some cruft it leaves behind as the script is designed for Travis CI - just a couple directories starting with "cov" and a tar.xz file. To integrate coverity scans for every pull request or push into master with Travis CI: 1. Make sure you have Travis CI set up properly to build your project. 2. Copy the Coverity Scan stanza from libs/uuid/.travis.yml into your .travis.yml file. Note that the Boost.Uuid travis configuration now uses jobs instead of matrix, as jobs allow for conditions. I would encourage you to convert your .travis.yml to use jobs as well. 3. The next pull request into master, or the next push into master, will trigger a build, and any build for master will run covscan.sh and upload the data. You can add component regular expressions to ignore/omit other boost library errors if you wish. Here are the results for Boost.Uuid. I have not excluded other components yet: https://scan.coverity.com/projects/boostorg-uuid Initially I saw a flurry of "unhandled exception" items which I dismissed as intentional (i.e. I want the test to segfault if an unexpected exception is thrown so that I can debug it), and that will likely be a common practice for test files, but should not be for implementations. I also caution folks against marking something as a false positive. Approach it with the mindset of, "it must be a fault of the library" before jumping to, "it must be a fault in Coverity" and really convince yourself it is not a code issue. Even if you do not have travis integration in your library, running a manual scan will help you improve the quality of your library, so I recommend everyone at least do that much. - Jim

5 5

Asciidoc, an alternative for documentation
by Peter Dimov 12 Oct '17

12 Oct '17

I've been experimenting with Asciidoc-based documentation, using Boost.Assert as my guinea pig. The good thing about Asciidoc is that Github shows a preview and you can edit it directly on github.com. This is how the source looks there: https://github.com/boostorg/assert/blob/feature/asciidoc/doc/index.adoc https://github.com/boostorg/assert/blob/feature/asciidoc/doc/assert.adoc https://github.com/boostorg/assert/blob/feature/asciidoc/doc/current_functi… This is how the generated HTML documentation looks, using the default stylesheet, without any customizations on my part: https://rawgit.com/boostorg/assert/feature/asciidoc/doc/html/assert.html And this is how the generated PDF looks: http://pdimov.com/tmp/assert.pdf The tool that produces these is Asciidoctor, http://asciidoctor.org/ .

13 34

Boost.Format Library Maintenance
by James E. King, III 12 Oct '17

12 Oct '17

Currently the Boost.Format library is being maintained by the CMT. I would like to petition for that responsibility and lighten their case load further. I recently assumed maintenance for Boost.Uuid, and I have added Universal Windows Platform support to Boost.WinAPI and Boost.Predef so that folks will have an easier time making Windows Store compatible apps. I have also been working on a change that will add UWP support to Boost.Random and turn it into a header-only library, and expect to submit that in the next few days. I would like to shore up the CI environment for Boost.Format and groom the backlog in trac and on github, and get all the open issues resolved. Thanks for your consideration, Jim King

3 3

[Build] How to build libboost_lzma?
by degski 12 Oct '17

12 Oct '17

Up till now I have built libboost_zlib and libboost_bzip2 by setting ZLIB_SOURCE and BZIP2_SOURCE variables to their respective source directories on the bjam command-line and the libraries get built without fail. I gather (from the bjam output) their is now support for lzma, which I would like to use. I've tried a similar (did not find a doc) approach with LZMA by feeding "-sLZMA_SOURCE=c:\xz-5.2.3" (from https://tukaani.org/xz/xz-5.2.3.tar.gz) to bjam. This does not work. How do I make bjam build libboost_lzma? Thanks in advance. degski -- "*Ihre sogenannte Religion wirkt bloß wie ein Opiat reizend, betäubend, Schmerzen aus Schwäche stillend.*" - Novalis 1798

1 1

Boost Serialization: Serializing large objects
by Adlai Shawareb 12 Oct '17

12 Oct '17

We are trying to text serialize a 700 MB object. We are getting an archive_exception: input stream error. This is on a 32-bit QNX system. * Is there a limit to the size of the object that can be serialized? * Is there anything we can do to fix or work around this? Here is the code we are using: std::stringstream ss_; boost::archive::text_oarchive oa(ss_, boost::archive::no_header); oa << &object; Adlai

4 11

interest in a stateful pointer library?
by Hans Dembinski 11 Oct '17

11 Oct '17

Hi everyone, I wrote a variant of std::unique_ptr, called tagged_ptr, which allows safe read/write access to a customisable number of bits in the pointer variable. You can find the library on github: https://github.com/HDembinski/stateful_pointer You can use those bits to store extra state in the pointer variable at no extra space cost. I did some benchmarks to show that the computational overhead required for the bit manipulation is also negligible. One needs little imagination to find good use for those bits. As a proof of principle, I wrote an STL compatible string class which has the size of const char*, but can store up to 7 ASCII characters (on a 64 bit system) without allocating any memory on the heap (aka small string optimisation). The string class is also included in the library. To make this work, I use one of the bits in the pointer variable to recognise whether the variable should be interpreted as a pointer or as a char array. The Stateful Pointer library is C++11, header-only, and AFAIK platform-independent (in theory, this has not been tested so far). To create pointers which allow one to use a certain number of bits for other purposes, I rely on Boost.Align to allocate aligned memory. How does it work? Aligned memory, as the name implies, does not point to any address in memory, only certain addresses are allowed. For example, a two-byte aligned memory block can only have an even address. Therefore the lowest bit in the address is always zero. Since the bit is guaranteed to be zero, we can use it to store something else and mask it to zero whenever we need to dereference the pointer. I think this is a generally useful class to have in Boost, so is there some interest in polishing it up in a review process? Best regards, Hans

7 18