February 2017 - Boost - lists.preview.boost.org

[MPL][vector] Is there interest in mpl::vector using variadic templates?
by Михаил Максимов 03 Mar '17

03 Mar '17

Dear community, I've recently started contributing to boost::variant. To speed up variant's compilation I'm implementing mpl::vector on variadic templates. For now status of new vector implementation is: 1) it passes all mpl/test tests on gcc 4.9 and 6.3 2) it is decoupled from mpl::vectorN, simultaneously making mpl::vectorN visible, so libs like Boost.Geometry, which rely on mpl::vectorN compile nicely 3) There are several compilation errors during full build on gcc 4.9 and 6.3 4) I fix problems on mpl/tests stage for clang 3.4 and latest MSVS2017 compiler Bruno's introduction of new shiny Metal library and Sergey's comment in the same thread: > The biggest and most useful feature of "new" TMP libraries is variadic > templates that increase performance by a really huge factor. The problem > with MPL is that vector type sequence must derive from vectorN-s, which are > documented and can be used in template specialization. So it is impossible > or pointless to remplement mpl::vector in terms of variadic parameters > because of that. The other problem that I can quickly recall is recursive > iterator-based approach, which also kills performance. made me wonder, is there interest in variadic templates implementation? Are there limitations for it's usefulness, which I did not see? Regards, Mike Maximov

7 14

[thread]Forever sleeping
by Niklas Angare 01 Mar '17

01 Mar '17

Recent runs of my regression test runner NA-QNX660-x86 leave a lot of Boost.Thread test executables stuck in nanosleep, waiting for a condition variable, or both. Commit 544eda [1] which switched from CLOCK_REALTIME to CLOCK_MONOTONIC seems suspicious to me. If the returned timespec is ever compared to values based on the CLOCK_REALTIME epoch, such as system_clock, the results will be quite undesirable. Are you sure the return values of timespec_now() are only ever compared to each other and values based on the CLOCK_MONOTONIC epoch? [1] https://github.com/boostorg/thread/commit/544eda51bdf0c62b2f29dea6fe1cf935a… Regards, Niklas Angare

3 9

boost exception to_string()
by Olaf van der Spek 28 Feb '17

28 Feb '17

Hi, Is to_string() here supposed to match to_string() in boost\exception\to_string.hpp? class shared_array2 : public boost::iterator_range<T*> {}; typedef shared_array2<unsigned char> shared_data; to_string(shared_data()); I really didn't expect this to_string() to be found here.. is it a feature or is it a bug? -- Olaf

1 0

[config] [atomic] Problem with placement of BOOST_ALIGNMENT - requesting opinions/suggestions
by Groke, Paul 28 Feb '17

28 Feb '17

While preparing a pull request for my Boost.Atomic extensions for the z/OS compiler, I noticed that I have a slight problem there. To get the code to work on z/OS, I changed the placement of the BOOST_ALIGNMENT macro in atomic/detail/storage_type.hpp from... BOOST_ALIGNMENT(16) unsigned char data[Size]; to unsigned char data[Size] BOOST_ALIGNMENT(16); ...because unfortunately the z compiler doesn't understand the __attribute__ ((__aligned__(x))) when it's at the beginning of a variable/data member definition. (For the GNU __attribute__ ((__aligned__(x))) the new location is also the only documented location, although GCC doesn't seem to mind.) While reviewing my changes I now realized that this won't do, because BOOST_ALIGNMENT can also be defined as __declspec(align(x)) or alignas(x), both of which are legal at the beginning but not at the end of a variable/data member definition. (I'm not 100% sure about valid positions of alignas (x) - the examples I can find use alignas (x) at the beginning, but the compilers we currently use - which include MSVC, GCC and Clang, also seem to accept it at the end. __declspec(align(x)) definitely is a problem though.) And now I'm wondering what to do about this. One way to fix this would obviously be to introduce two additional macros, e.g. BOOST_ALIGNMENT_DECLSPEC and BOOST_ALIGNMENT_ATTRIBUTE. Only one of those would then expand to something non-empty, and both would have to be used in variable definitions. The BOOST_ALIGNMENT macro would remain as is for type declarations and for compatibility. The code in storage_type.hpp would then have to be re-written as BOOST_ALIGNMENT_DECLSPEC(16) unsigned char data[Size] BOOST_ALIGNMENT_ATTRIBUTE(16); Which of course is very very ugly. Another option would be a BOOST_ALIGNED_VARIABLE(alignment, variable_definition) macro. This would be nice in definitions like BOOST_ALIGNED_VARIABLE(16, unsigned char data[Size]); but much less nice in definitions like BOOST_ALIGNED_VARIABLE(16, some_template<foo BOOST_PP_COMMA bar BOOST_PP_COMMA baz>); And since not all compilers support variadic macros, this is probably the best one could do. The third option I can think of would be to leave things as they are, which of course would mean that I can't submit my Boost.Atomic implementation for z/OS... hm. I realize that making things uglier for a single compiler that almost nobody uses isn't something many people will cheer for. But then again I'd really like to have my Boost.Atomic implementation for z/OS in the official Boost releases :) So I'm calling out to you for suggestions/opinions/comments. Is there another way to combine the above mentioned square peg + round hole? And which option would you deem favorable/acceptable? Thank you for taking the time to read this wall of text, Cheers, Paul Groke The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it. Dynatrace Austria GmbH (registration number FN 91482h) is a company registered in Linz whose registered office is at 4040 Linz, Austria, Freistaedterstrasse 313

3 8

[gsoc17] Boost will be participating in Google Summer of Code in 2017
by Niall Douglas 27 Feb '17

27 Feb '17

I am very pleased to inform the Boost community that Google accepted us into their Summer of Code programme this year. This was especially welcome after we were given "a year off" last year which could have caused substantial disruption to the multi year student projects had it not been due to the timely action of the steering committee and generous sponsorship of a stop gap Boost Summer of Code in 2016 by IMC Financial Markets. Last year Google completely rebuilt the Summer of Code website so it no longer is anything like it was before. Now we must individually invite those who vote on student projects, so *anyone willing to rank student project proposals* can you please email us with your details: 1. Your email address matching your Google Account so we can invite you onto the GSoC programme. 2. (Optional) your email address matching your Github Account so we can invite you onto the Boost GSoC github org for 2017 as a potential mentor. Our thanks to those who have already added project ideas to https://svn.boost.org/trac/boost/wiki/SoC2017, but we need MORE ideas and MORE potential project mentors. Follow the project idea template at https://svn.boost.org/trac/boost/wiki/GSoCIdeaTemplate and either add it straight to the wiki page or email it to us so we can add it for you. Our thanks to all in advance.

1 0

ABI navigator for Boost libraries
by Andrey Ponomarenko 26 Feb '17

26 Feb '17

Hello, I'd like to present a new project called "ABI Navigator" to search for binary symbols (functions, methods, global data, etc.) in the Boost and other open-source libraries: https://abi-laboratory.pro/index.php?view=navigator The project allows to find out in which versions of the library and in which particular objects of the library some symbol is defined, added or removed. The project is based on the ABI report for Boost: https://abi-laboratory.pro/tracker/timeline/boost/ Examples: 1. symbol "boost::system::system_category()" from libboost_system.so: https://abi-laboratory.pro/index.php?view=navigator&selected=_ZN5boost6syst… 2. symbol _ZnwmPv21boost_container_new_t from libboost_container.so: https://abi-laboratory.pro/index.php?view=navigator&selected=_ZnwmPv21boost… The project aims to help library users and maintainers to resolve issues with missed symbols and navigate through the ABI reports. Have you ever encountered the "undefined reference" error or want to know whether the symbol is _stable_ enough to use in your code? Try to find it in the ABI Navigator! Enjoy!

1 0

[release] 1.64.0 closed for major changes
by Rene Rivera 23 Feb '17

23 Feb '17

The master branch is now closed for new libraries and breaking changes, and will be closing for major changes in a week and closed for the beta in two weeks. Also, if you're ready, you can also add your libraries' changes to the release notes at: < https://github.com/boostorg/website/blob/master/feed/history/boost_1_64_0.q… > Thanks, -- The Boost Release Team -- -- 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

[mpi] Merging a PR fixing auto_ptr usage
by Andrey Semashev 22 Feb '17

22 Feb '17

Hi, Could someone take a look at this PR and hopefully merge it? https://github.com/boostorg/mpi/pull/38 It should be safe to merge, and I would really like to see it in 1.64. I'm surprised noone fixed it earlier, actually. Thanks.

2 1

Status of Visual Studio 2017 support
by Mateusz Loskot 22 Feb '17

22 Feb '17

Hi, In the mid of 2016, PR "Add support for Visual Studio 15" [1] was merged into develop and eventually into master branch. Although the patch was released in Boost 1.63.0, the release notes [2] are silent about that update. That is about Boost.Build, which I assume is the first to be updated to support a new toolkit. I haven't checked current commits history of individual libraries. Status of VS2017 support in individual libraries may be at different stages. Could anyone clarify any of these points: - Does Boost.Build in Boost 1.63.0 officially support VS2017? - Is there any schedule to fully support VS2017 in Boost 1.64.0? - Or, is that left at discretion of maintainers of individual libraries and VS2017 support might be reached gradually over several releases instead of in a single shot? [1] https://github.com/boostorg/build/pull/132 [2] http://www.boost.org/users/history/version_1_63_0.html Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

16 46

[config] [atomics] Support for z/OS XL C/C++
by Groke, Paul 21 Feb '17

21 Feb '17

Hi, we're using several Boost libraries in a large cross-platform project. One of the platforms we need to support is z/OS, using the IBM z/OS XL C/C++ compiler (which BTW is a completely different beast from the XL C/C++ compilers for other IBM platforms, which Boost.Config already seems to support). To be able to use Boost we had to write some patches and we'd very much like to contribute them. In more detail: * A minor patch to make the configure script work * Patches to some of the configure tests to fix incorrect feature detections * Compiler-, library- and platform-config header files * A Boost.Atomic implementation * An implementation of Boost.SmartPtr atomic operations This won't result in full support for all Boost libraries, not even close, but it's enough to make an appreciable subset usable on z/OS. I've never contributed code to any open source project so far, so I'd appreciate your help. Where should I start? Do I have to talk to the maintainers of Config/Atomic/SmartPtr? Is there even a maintainer for every specific project? Or should I just fork the Git repos and create pull requests? I'm pretty much lost here, sorry :) Regards, Paul Groke The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it. Dynatrace Austria GmbH (registration number FN 91482h) is a company registered in Linz whose registered office is at 4040 Linz, Austria, Freistaedterstrasse 313

4 6