- Boost - lists.preview.boost.org

Hello World
by Naivedya Bansal 14 Aug '17

14 Aug '17

I am a new comer and would like to become a contributor at Boost. Could you please provide me with relevant links from where to start ad I am feeling entirely lost right now. Thank you, Naivedya Bansal

2 1

CUDA V9 (release candidate) breaks compilation
by Hartmut Kaiser 12 Aug '17

12 Aug '17

All, Apparently CUDA V9 has deprecated/removed the __CUDACC_VER__ macro which is used by Boost, see https://github.com/STEllAR-GROUP/hpx/issues/2815 for details. Should this be fixed before the release? Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu

1 0

Switch to CMake -- Analysis
by Thomas Heller 12 Aug '17

12 Aug '17

Hi list, After there has been a heated debated over the last three days over the switch to CMake, I'd like to share my observations... First of all, a general observation: In this discussion, there generally seems to two camps: Those who know Boost.Build and those who know CMake. Unfortunately, there doesn't seem to be any overlap between those groups, which generally made the discussions about a potential switch to CMake unfruitful, often leading to misunderstandings due to a lack of knowledge about the other tool. There is no doubt, that the group of people knowing CMake is larger and that projects using CMake far outnumber the ones using Boost.Build. A thousand flies can't be wrong, right? Is the popularity of CMake really the only benefit? Here is the thing, from my point of view: Apart from the different philosophy (Build System vs. Build System generator), in the end, you get a executable/library out of the system. From a pragmatic point of view, the only thing that changes to develop/build/test/use a library is the work flow. Leaving aside the disruptive and its effects of such. Now, on to the motivation for switching, as presented in the announcement: On 7/18/2017 9:12 AM, Jon Kalb via Boost wrote: > [...] our build system has become an impediment for many developers > and users, existing and prospective. Let's look at users first. Yes, FindBoost.cmake has its problems, but it works in 90% of the cases (from my own experience). This can, and should certainly be improved. Providing the necessary XXX-config.cmake files is what fixes this. There has been movement in that direction, with code, which could be just improved upon. This will fix those cases. The other group of library consumers, expressed the urge to build boost directly as part of their build process. That hasn't been done yet, but I am pretty certain, there are no road blocks to actually write such a CMake Module, which invokes b2 instead of the compiler directly inside of the superproject. Together with the generated XXX-config.cmake files, this use case is covered. From my recollection of the various discussions, this approach was not contentious at all, it wouldn't even require interaction with all library maintainers, and all CMake users (existing or prospective) would immediately benefit. Now on to developers. There is obviously a lot of resistance from existing developers (for various reasons, which are not really relevant for the discussion at hand). In my opinion, maintaining two build systems is a no-go. Either make a clear cut, or don't. Please don't waste resources on maintaining and supporting both. With this line of thought as the background, this will create massive disruption. Switching the whole of boost (including infrastructure, documentation etc.) to be built and tested with CMake is not easy and take a lot of time, leaving a void for both maintainers and prospective boost library authors. Now, the argument that has been brought up very often in favor for the switch is that it will attract more contributors, but will it really? I am reluctant to the idea that people don't contribute new libraries to boost just because of the build system. Despite a switch to cmake, you'd still have to conform to Boost.CMake guidelines and somehow make your library buildable and testable within and outside of the Boost Tree (there might be a straight forward solution to this). Furthermore, I often hear something like "in the presence of GitHub and CMake people don't think about submitting to boost anymore". This is exactly the point. But it has nothing to do with the "and CMake" suffix. It's is just far more easier and convenient to drop you library to GitHub, advertise it on various channels and call it a day. I hear you say: "Sure, but libraries will only be adopted if they come with CMake." That might very well be true, but what has this to do with Boost? Compare the lengthy and exhausting review process you have to go through with the click of a few buttons and hammering something onto a keyboard. And no, Robert, while the incubator was a nice idea, it doesn't compensate that either ;) All in all, I am pretty confident that a disruptive switch will hurt Boost more than it brings benefit. This already happened. To come to an end and summarize: Provide proper CMake integration, such that Boost is consumable by those (while you are at it, don't forget meson, bazel and pkg-config). While your add it, improve Boost.Build, maybe it can rise again from its ashes (why did it "fail" in the first place?). Regards, Thomas

27 78

Best Practices for Surviving the Boost Test Gauntlet?
by Vinnie Falco 11 Aug '17

11 Aug '17

Beast won the first battle, but it looks like it is losing the war: <http://www.boost.org/development/tests/develop/developer/beast.html> I've never heard of many of these platforms let alone know how to go about fixing the compile, link, and runtime errors. It seems like deallocate() is not part of some standard library's allocator_traits? Link error on operator delete from Boost.System? A lot of little thing. Is there a document or resource which explains the various peculiarities and idiosyncrasies of these platforms and toolchains that I might have a means of fixing them without actually installing them locally (which is unlikely)? Thanks

6 14

boost_check_library.py: correct handling of header-only libs?
by Vinnie Falco 10 Aug '17

10 Aug '17

This script fails for me: <https://github.com/boostorg/boost/blob/master/status/boost_check_library.py…> Because there is no libs/beast/build. But Beast is header-only and has no src/ directory, is this correct? Apologies for posting to the list, but there is no Issues tab on the boostorg/boost repo. Thanks

3 2

Boost 1.65.0 Release Candidate 1
by Marshall Clow 09 Aug '17

09 Aug '17

The release candidates for the 1.65.0 release are now available at: https://dl.bintray.com/boostorg/release/1.65.0/source/ The SHA256 checksums are as follows: 0f1352a7738f24b39b564263b66a8c38bc7d984b57406396400474602e961ad3 boost_1_65_0_rc1.7z c2a022d4d6706668ea94b8e799a76e38929e0e34db884ef451fa9d5db6103238 boost_1_65_0_rc1.tar.bz2 7e84a27276792209d48357a0671348768dbf4dd1d4eadbf01b855274208f148d boost_1_65_0_rc1.tar.gz 537c42771b2351b4ea3eb8e9a13a3423edcd155323d2c14c4606cd23fc22d09f boost_1_65_0_rc1.zip As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. Thanks! -- The release managers

7 12

[filesystem] Pull request needs attention
by Robert Dailey 09 Aug '17

09 Aug '17

I have fixed a crash I found due to static initialization ordering in boost filesystem. I have a proposed fix here: https://github.com/boostorg/filesystem/pull/47 It hasn't gotten any attention yet, so I'm hoping someone can offer some advice and/or merge the PR for me. Thanks in advance.

3 3

Boost UUID Maintainer
by James E. King, III 08 Aug '17

08 Aug '17

Greetings! I'm a long-time boost user and over the years I have posted defects into boost trac for the components I have used. I was reviewing the backlog on boost::uuid and in trac and it needs a bit of grooming. I started submitting some PRs to resolve some of these. Edward D. in the CMT group was reviewing some of them and mentioned that there is no active maintainer for the library, and invited me to introduce myself here. I am currently a committer on the Apache Thrift project and I have 20+ years development experience with C++. I have good experience at backlog grooming, and I am very focused on quality. I believe firmly in testing all code branches, and using coverage tools to prove it. I also assisted the glibc team in getting started with Coverity Scan which helped lead to resolution of 138 defects at last count. My current position is a Software Architect at HPE SimpliVity where I have been for the last ~7 years (I'm easy to find on LinkedIn, hopefully). I live in Westford, MA, USA. Given there is no maintainer for boost::uuid currently, I would like to petition for that responsibility. It is a relatively small library in the portfolio and seems like a good introduction to being a maintainer in such a widely used project. Thanks for your consideration, Jim King

5 7

[stacktrace] 1.65.0 RC1 fails to build for MSYS2/mingw-w64
by Stephan Lavavej 07 Aug '17

07 Aug '17

Hi, I just attempted to build Boost 1.65.0 RC1 with MSYS2/mingw-w64. (My build script for 1.64.0 is available at https://github.com/StephanTLavavej/mingw-distro/blob/6e5976af8c63de93bec761… ; I just had to change the filenames for 1.65.0 RC1.) The stacktrace build failed with: gcc.compile.c++ bin.v2\libs\stacktrace\build\gcc-mingw-7.1.0\release\link-static\runtime-link-static\threading-multi\windbg_cached.o In file included from libs\stacktrace\build\..\src\windbg_cached.cpp:10:0: ./boost/stacktrace/detail/frame_msvc.ipp:167:72: warning: missing terminating ' character # error Your compiler does not support C++11 thread_local storage. It's impossible to build with BOOST_STACKTRACE_USE_WINDBG_CACHED. ^ ./boost/stacktrace/detail/frame_msvc.ipp:167:5: error: #error Your compiler does not support C++11 thread_local storage. It's impossible to build with BOOST_STACKTRACE_USE_WINDBG_CACHED. # error Your compiler does not support C++11 thread_local storage. It's impossible to build with BOOST_STACKTRACE_USE_WINDBG_CACHED. ^~~~~ In file included from ./boost/detail/winapi/file_management.hpp:17:0, from ./boost/stacktrace/detail/safe_dump_win.ipp:20, from ./boost/stacktrace/safe_dump_to.hpp:206, from ./boost/stacktrace/frame.hpp:20, from ./boost/stacktrace/detail/frame_msvc.ipp:15, from libs\stacktrace\build\..\src\windbg_cached.cpp:10: ./boost/detail/winapi/overlapped.hpp:39:9: warning: ISO C++ prohibits anonymous structs [-Wpedantic] }; ^ "g++" -O3 -finline-functions -Wno-inline -Wall -pedantic -mthreads -m64 -DBOOST_ALL_NO_LIB=1 -DNDEBUG -I"." -c -o "bin.v2\libs\stacktrace\build\gcc-mingw-7.1.0\release\link-static\runtime-link-static\threading-multi\windbg_cached.o" "libs\stacktrace\build\..\src\windbg_cached.cpp" ...failed gcc.compile.c++ bin.v2\libs\stacktrace\build\gcc-mingw-7.1.0\release\link-static\runtime-link-static\threading-multi\windbg_cached.o... It appears that frame_msvc.ipp is intended to work with both MSVC and MinGW, but it's not correctly recognizing mingw-w64 GCC 7.1.0's behavior. This compiler supports thread_local, although it doesn't support C++11's multithreading headers (without the pthreads wrapper, which I don't build). Either this library should correctly detect mingw-w64, or it should be disabled for mingw-w64. Thanks, STL

2 2

[config] detect std::unique_ptr
by Artyom Beilis 07 Aug '17

07 Aug '17

Hello, I'm searching for a macro to detect reliably existence of std::unique_ptr I didn't found one in boost.config Artyom

2 2

[C++ committee] auto_ptr removal in C++17 - request to comittie
by Artyom Beilis 07 Aug '17

07 Aug '17

Hello, If somebody on committee is on this list. I really want to do something to prevent auto_ptr removal. It is exceptionally useful smart pointer in C++2003 and it is needed by the code that needs to be compatible for both 2003 and 2017. It is needed by libraries that aim to be compatible with C++2003. In the real world there is a huge codebase that uses C++2003 why to break something that works - especially since it works quite well. It isn't "gets" that can't be used securely. C++ committee please stop breaking existing code even if std::unique_ptr much better it does not exist in C++2003. Artyom

3 2

Microsoft vs The Boost License
by Phil Bouchard 06 Aug '17

06 Aug '17

Hi, Just to put everybody in context: 1) Microsoft had invested into Corel so that they get rid of Corel Linux back in 2000 when I was working there: https://www.forbes.com/2000/10/03/1003corel.html 2) Microsoft once again copied my Fornux PowerCalc after I had presented it to them using some web interface: http://www.fornux.com/ With their Microsoft PowerToys: https://en.wikipedia.org/wiki/Microsoft_PowerToys#Included_applications 3) And now here I am with Microsoft trying to copy the idea behind root_ptr's node_proxy: https://github.com/philippeb8/root_ptr With their "deferred_ptr heap": https://github.com/hsutter/gcpp So for some reason I do not trust Microsoft. And I was wondering if the Boost license protects us from an idea behind a library we wrote. Otherwise this makes the Boost license not very useful. Thanks a lot for your help! -Phil

9 20

[BB++] Documentary - Take 3
by Phil Bouchard 06 Aug '17

06 Aug '17

In the following video, I am explaining how objects of a lower scope are being promoted to a higher scope (please fast forward to 10:15): https://youtu.be/OBnpFUVEVe4 I added 5 slides explaining how objects are being promoted and I've renarrated everything after 6:21. I'm keeping the beginning because I am targeting newbies on the subject as well. I hope that's a good explanation because sharing this information publicly is a point of no return for me. Sincerely, -Phil

1 0

Submodule name mismatches between master and develop
by Peter Dimov 05 Aug '17

05 Aug '17

Several submodules have different names on master and develop: - compute (libs/compute on develop) - couroutine2 (libs/coroutine2 on develop) - dll (libs/dll on develop) - qvm (libs/qvm on develop) - vmd (libs/vmd on develop) Should we normalize the names on develop? I think that after fixing .gitmodules, these submodules will appear as-if deinitialized, and would need a `git submodule update --init` to reappear under the new names. There are also libs/hana and libs/metaparse, which have consistent (although "wrong") names on both master and develop. Not sure if we need to bother with them.

6 8

LIB CSV
by Greger 05 Aug '17

05 Aug '17

During some time I have created this CSV library: <a href="http://www.multi.fi/~ghaga/libcsv/html/index.html">http://www.multi.fi/~ghaga/libcsv/html/index.html</a> (For processing of CSV tables) any use?good?bad? ty G

3 3

[locale] reporting MSVC issue
by Artyom Beilis 04 Aug '17

04 Aug '17

I noticed some failures in Boost.Locale using std backend and narrowed it down to broken Japanese_Japan.932 support of codecvt facet. I tried to report it on https://connect.microsoft.com/VisualStudio but it shown me " You are not authorized to submit the feedback for this connection. " How can I report the bug to Mircrosoft? Thank You, Artyom Below is the sample to reporoduce the issue: Works ok on MSVC 10 and below Fails on MSVC2017 - and it should work ---------------------- #include <iostream> #include <locale> #include <fstream> int main() { { // Japan in Shift JIS/cp932 char const *japan_932 = "\x93\xfa\x96\x7b"; std::ofstream f("testi.txt"); f<<japan_932; f.close(); } try { std::wfstream test; test.imbue(std::locale("Japanese_Japan.932")); test.open("testi.txt"); // Japan in Unicode std::wstring cmp = L"\u65e5\u672c"; std::wstring ref; test >> ref; if(ref != cmp) { std::cout << "FAIL" << std::endl; std::cout << "REF" << std::endl; for(size_t i=0;i<ref.size();i++) std::cout <<std::hex<< unsigned(ref[i]) << std::endl; std::cout << "EXP" << std::endl; for(size_t i=0;i<cmp.size();i++) std::cout <<std::hex<< unsigned(cmp[i]) << std::endl; } else { std::cout << "OK" << std::endl; } } catch(std::exception const &e) { std::cout << "No Locale: " << e.what() << std::endl; } }

2 1

libs/sync?
by Peter Dimov 04 Aug '17

04 Aug '17

We have a submodule libs/sync on the develop branch that isn't on master. What's its fate? Is it going to become a released library at some point, or should we remove it?

2 3

Bjarne's talk on C++20
by Phil Bouchard 04 Aug '17

04 Aug '17

I won't be able to go myself unfortunately but I'm just passing the word: http://www.technomontreal.com/en/news-center/events/bjarne-s-talk-upcoming-… Regards, -Phil

1 0

[release-tools] Doxygen 1.8.6 is rather old
by Vinnie Falco 03 Aug '17

03 Aug '17

Would it be possible to use the newest doxygen instead of the default 1.8.6 for Trusty? The latest version is 1.8.13, and Beast needs a newer version in order to generate correct output. <https://github.com/boostorg/release-tools/issues/4> Thanks

1 0

[BB++] Consensus
by Phil Bouchard 03 Aug '17

03 Aug '17

After the feedback I got back from the community, people agree they would rather improve C++ than seeing a new language taking off. I definitely agree but I would like professional opinions on how the following could be achieved: - to add instances of an object implicitly as each scope; - to add implicit references to these objects in top-level classes - to overload 'operator .' - to use 'auto' for member variables instead of 'decltype' Thanks for your help I really appreciate. Sincerely, -Phil

2 4

[review][mp11] Review report
by Bjorn Reese 03 Aug '17

03 Aug '17

I. VERDICT Mp11 is accepted unconditionally into Boost. There were 14 accept votes and 1 conditional accept vote. See list at end of this report. II. DESIGN Reviewers evaluated the design as very good. Many agreed with the design principle of using template aliases on type lists, which means that Mp11 can be used on std, boost, and custom type lists. Integration with MPL was discussed. This resulted in a new header file <boost/mp11/mpl.hpp> that enables the conversion between mp_list (and std::tuple) and MPL sequences. A version of mp_eval_if that can apply a metafunction to type lists in both the true and false branch was requested. This is not possible due to C++ limitations (template parameter pack must be at the end.) Instead two alternatives were suggested: (1) use a nested mp_eval_if in the true branch, or (2) use mp_if<>::type with mp_defer in both branches. Extra metafunctions were added for working with map and sets: mp_is_set, mp_is_map, and mp_map_keys which returns a list of all keys. No review without a discussion about names. The mp_ prefix received most comments. The prefix is used to avoid collision between mp11 names and C++ keywords. The argument against the mp_ prefix was that MPL and other Boost libraries already have established trailing underscore as the naming convention. The argument in favor is that the mp_ prefix is better suited for later C++ standardization. Other names that deviate from MPL, such as apply versus fn, were also pointed out, and the names of tuple operations were also discussed. III. IMPLEMENTATION The reviewers who looked at the implementation were generally pleased with its quality and simplicity. A faster version of mp_find was proposed during review. On reviewer pointed out that const lists causes obscure compilation errors. IV. DOCUMENTATION The evaluation of the documentation was more mixed. Some found it good, while others found it too terse. A recurring comment was that the documentation is missing beginner-level explanations and examples. For instance, the tuple_cat example was mentioned as being too advanced for an introduction. More examples with higher-order metafunctions (e.g. mp_bind) was requested. The reference documentation does not state the pre-conditions of the metafunctions. For example, what happens when indices are out of bounds? The description of map (list of lists) lead to confusion. Mp11 map entries have one unique key-type, and zero or more value-types. The ability to have multiple value-types per key-type makes it possible to emulate multi-maps. Some where unsure whether C++11 or C++14 was required for the library. There were plenty of other useful comments that I will omit from the review report for the sake of brevity. V. USEFULNESS The library was generally deemed useful. It was discussed if C++11 (and later) makes it too easy to write our own metaprogramming utilities, and thus not needing a metaprogramming library. This was not directed at Mp11 in particular. Some of the arguments in favor of a metaprogramming library were better performance and portability. I would like to add another advantage of a metaprogramming library, namely that it gives us a common vocabulary. VI. CONCLUSION The library fulfills the quality and usefulness criteria without major outstanding issues. The library is therefore cleared to be included into Boost. My main recommendation as review manager is to make the documentation more beginner-friendly before the library is added to Boost. This is a recommendation, not a requirement. VII. PARTICIPANTS The following formal reviews were posted: * Barrett Adair : Accept * Brook Milligan : Accept * Edward Diener : Accept * Glen Fernandes : Accept * Jason Rice : Accept * Joaquin M López Muñoz : Conditional accept * John P Fletcher : Accept * Lee Clagett : Accept * Paul Fultz : Accept * Peter Koch Larsen : Accept * Robert Ramey : Accept * Roberto Hinz : Accept * Vijayan : Accept * Vinnie Falco : Accept * Zach Laine : Accept I would like to thank all participants for their efforts. I would also like to thank Peter Dimov for bringing such a high-quality library to Boost.

3 2

Warning generated by boost::process code
by Wilfred Smith 02 Aug '17

02 Aug '17

Dear Sir or Madam, In Boost 1.64.0, include/boost/process/detail/posix/wait_group.hpp:131:10: warning: unused variable 'start' [-Wunused-variable] auto start = std::chrono::system_clock::now(); ^ /usr/local/include/boost/process/detail/posix/wait_group.hpp:165:10: warning: unused variable 'start' [-Wunused-variable] auto start = std::chrono::system_clock::now(); ^ I believe these two lines should be removed. This appears to be a “copy and paste” issue. The two routines above these lines use the “start” variable to calculate a relative time. However, the later two routines use an absolute time, and the compiler complains as shown above. Removing these two lines should fix the compiler warning and have no adverse effect. Please let me know if this is the wrong place to complain about issues. \W/

2 1

Boost::Process is broken
by Wilfred Smith 02 Aug '17

02 Aug '17

All, Has anyone tried to build with <boost/process.hpp> included using XCode 9.0? I don’t think this went through code review. include/boost/process/exception.hpp:22:30: error: using declaration cannot refer to a constructor using std::system_error::system_error; ~~~~~~~~~~~~~~~~~~~^ I’m not sure that does what was intended, and the compiler thinks it’s silly talk… Any and all assistance appreciated in advance… \W/

2 1

Reminder: Boost Master branch will close for the 1.65.0 release on Wednesday
by Marshall Clow 02 Aug '17

02 Aug '17

Get your bug fixes and documentation updates in now! -- Mashall Upcoming release schedule: 2-Aug: Release closed for all changes, except by permission of a release manager. 5-Aug: Boost 1.65.0 closed for all changes 9-Aug: Boost 1.65.0 release

7 20

[numeric_conversion] Compilation errors with msvc-14.1 and std:c++latest in master branch
by Adam Wulkiewicz 02 Aug '17

02 Aug '17

Hi, I noticed there are compilation errors in master branch and not in develop branch. Only runs with cxxflags= std:c++latest are failing. See e.g.: http://www.boost.org/development/tests/master/developer/output/teeks99-09-q… Affecting Geometry: http://www.boost.org/development/tests/master/developer/output/teeks99-09-q… Regards, Adam

1 0