March 2019 - Boost - lists.preview.boost.org

CMake Announcement from Boost Steering Committee
by Jon Kalb 13 Aug '24

13 Aug '24

The libraries produced by the Boost community have had a greater impact on the way that the C++ community writes code than any other library implementation. The focus of the Boost community will always be on the libraries, but it is undeniable that we are dependent on and often limited by the infrastructure of our trade. Years ago, the move to Git was contentious; yet, it was required to improve development. In a similar vein our build system has become an impediment for many developers and users, existing and prospective. Therefore, we, the Steering Committee, announce to the Boost community our desire and intent to move Boost’s build system to CMake for users and developers alike. We are soliciting comments and proposals from the community to guide the process and the goals. Our desire is that the community can come to consensus by the end of the calendar year with a vision of supporting users and developers. We understand that the actual process of achieving the end goal will be long, time consuming, and not without its share of conflict. We also recognize that the Boost community is comprised of bright and passionate individuals that are eager to get involved and help get work done. The members of the Steering Committee have been encouraged by the discussions and activity surrounding CMake on the mailing lists over the years and know that many people have voiced visions. We hope that each of you rejoins the discussion to support this initiative and contributes to the common goal of improving Boost’s integration into the broader C++ ecosystem. For the Boost Steering Committee, Jon Kalb, Chair jonkalb(a)boost.org

49 199

[asio][coroutine] forbid_suspend blocks
by Vinícius dos Santos Oliveira 07 Aug '19

07 Aug '19

I've implemented a dumb linter using Python + clang API that allows you to mark certain blocks as “atomic in respect to coroutines” using C++11 attributes. Usage example follows: void f() { int yield; g(yield); [[bt::forbid_suspend]] { // Comment this call to make linter accept the code g(yield); t(); } } You can change bt::forbid_suspend to another identifier by tuning settings on the beginning of the script. The prefix forbid was inspired by Rust's linters[1] as you cannot disallow the linter from inside the forbid_suspend block. Some limitations follow: - A suspend point is identified by looking references to any id equals to yield in the last argument passed to function calls. It means that yield[ignored_ec] and alike will be correctly identified, but it needs to be named yield and it needs to be the last argument to the function call. - I haven't found a way to extract attributes related to COMPOUND_STMT nodes with clang API, so I manually look for token gaps and do a simple regex. It means you cannot use macros to [[bt::forbid_suspend]] as the macro won't be expanded. - You better call the script with '-x c++' and also ' -I/usr/lib/clang/5.0.1/include'. Like I've said in the beginning of the email, it's a *dumb* linter, which means it doesn't try to handle all cases. Therefore, I don't hope to do many changes to it or maintain it to work against newer releases of clang and I'm only uploading it to gist (not fullblow Github): < https://gist.github.com/vinipsmaker2/d930fbe5b7597432b021effe618da171>. It should also be easy to hack as it is very small. I'm releasing the linter under public domain. Enjoy. I have been using fibers in a daily basis on the last months of my job to solve networking problems on a gateway project. Some of the technologies I use are: - Boost.Asio and its spawn function. - A few custom synchronization primitives for the fibers (e.g. mutex, semaphore). - Eventually I'll have to write a custom spawn function that returns a joinable handle so I can kill the usage of a fiber::barrier in a few places. I've been using the linter for about a week already and looks fine. My use case are: - To prevent iterator invalidation in regions accessing shared variables. - To guarantee events order in algorithms that handle races (cannot yield while task YYY hasn't finished). The project I use it in is not an open source project, so I cannot talk much more about it. Also, I don't claim my solution is original. I wouldn't be surprised if the very same solution exists in the wild (please let me know if you know of a similar approach). This is not a new problem. It is know for some time. For instance, in P0171, Gor Nishanov noted this same problem: “In coroutines the suspend point is clearly marked with await, which tells the reader that something unusual happens in this function and allows the reader, for example, to confirm whether the lifetimes of the objects of interest align with the lifetime of the coroutine or not, whether some locks need to be acquired to protect some concurrently accessed data, and whether some locks need to be released before the execution reaches the suspend point.” — <http://open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0171r0.html>, 2015 However, the solution he presented was to manually examine whole blocks of code without help from the compiler. I argue that the solution he presented is as error-prone as manually looking for exit paths that don't free acquired resources in languages lacking RAII. And I've been spoiled too much by RAII. Furthermore, I take this comment of his with highly suspicious look: “Since we are on the subject of maintenance nightmares, we would like to offer a conjecture that the absence of the await in P0114 is a likely source of many maintenance nightmares. Without a syntactic marker to signal to the person reading the code that something funny is going on, it is impossible to tell whether the following code is correct or not” — http://open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0171r0.html If I had to give a vote to the proposal he was defending or Chris' proposal, I'd probably have chosen Chris'. [1] https://doc.rust-lang.org/reference/attributes.html# lint-check-attributes -- Vinícius dos Santos Oliveira https://vinipsmaker.github.io/

2 3

Non-ASCII Path Names in Repo
by Tom Kent 25 May '19

25 May '19

In the last few days we've had a non-ASCII path name added to the repo: tools/boostdep/test/utf8-test-ßµ™∃ Which came with commit 8893d1c57951a [1] I noticed this because a python 2 script (calling shutil.copytree) I had running on windows that copied the repo around started to fail. I've long needed to update that script to python 3, and am working on this. However, I wanted to point this out to the list so we could discuss if there are any other ramifications of having a non-ascii path. I vaguely remember some discussion about something like this in the past, but couldn't find it via search. If this is already a settled topic, that's great. Tom [1] https://github.com/boostorg/boostdep/commit/8893d1c57951a4a83705ed203005576…

2 1

Re: [boost] [ Interest? ] [ out_ptr ] Tiny C++ Abstraction for C-Style Output Pointers
by Bjorn Reese 12 May '19

12 May '19

On 06/28/18 21:03, ThePhD via Boost wrote: > out_ptr is a small abstraction for making types such as > std::unique_ptr, std::shared_ptr, boost::shared_ptr, and the upcoming > std::retain_ptr > <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0468r0.html> work > work C-Style output functions as a parameter, addressing the need of > wanting to be able to do "my_c_api_init( foo, bar, &my_smart_ptr );". It's Does out_ptr have other use-cases than C interoperability?

7 14

[thread] compiler error gcc 7.3 on cygwin
by James E. King III 06 May '19

06 May '19

Getting an internal compiler error with gcc 7.3 but only on cygwin 64-bit. Jim@pulsar /cygdrive/c/boost/libs/thread $ ../../b2 --abbreviate-paths toolset=gcc cxxstd=11 define=_POSIX_C_SOURCE=200112L define=__USE_ISOC99 threadapi=pthread address-model=64 variant=release -q ... gcc.compile.c++ ../../bin.v2/libs/thread/test/test_10963_c.test/gcc-7.3.0/rls/cxstd-11-iso/thrd-mlt/vsblt-hdn/test_10963_c.o In file included from ../../boost/thread/detail/invoker.hpp:30:0, from ../../boost/thread/future.hpp:31, from ../../libs/thread/test/test_10963.cpp:13: ../../boost/thread/detail/invoke.hpp: In function ‘decltype (*(forward<A0>)(boost::detail::invoke::a0).*boost::detail::invoke::f) boost::detail::invoke(Fp&&, A0&&) [with Fp = void (boost::executors::basic_thread_pool::*)(); A0 = boost::executors::basic_thread_pool*]’: ../../boost/thread/detail/invoke.hpp:102:43: internal compiler error: in gimplify_expr, at gimplify.c:12006 return (*boost::forward<A0>(a0)).*f; ^ Please submit a full bug report, with preprocessed source if appropriate. See <https://gcc.gnu.org/bugs/> for instructions. "g++" -std=c++11 -fvisibility-inlines-hidden -m64 -mthreads -O3 -finline-functions -Wno-inline -Wall -pedantic -fvisibility=hidden -Wextra -Wno-long-long -Wno-unused-parameter -Wunused-function -pedantic -DBOOST_ALL_NO_LIB=1 -DBOOST_THREAD_THROW_IF_PRECONDITION_NOT_SATISFIED -DNDEBUG -D_POSIX_C_SOURCE=200112L -D__USE_ISOC99 -I"../.." -c -o "../../bin.v2/libs/thread/test/test_10963_c.test/gcc-7.3.0/rls/cxstd-11-iso/thrd-mlt/vsblt-hdn/test_10963_c.o" "../../libs/thread/test/test_10963.cpp" ...failed gcc.compile.c++ ../../bin.v2/libs/thread/test/test_10963_c.test/gcc-7.3.0/rls/cxstd-11-iso/thrd-mlt/vsblt-hdn/test_10963_c.o... If I change the C++ language level to 03 the problem goes away. I also cannot reproduce it on linux with the same version of compiler (but it probably isn't the exact same compiler code). Should I go ahead and file that gcc bug? - Jim

2 1

[review][variant2] Variant2 Review Starts April 1
by Michael Caisse 06 Apr '19

06 Apr '19

The Boost formal review of Peter Dimov's Variant2 library will take place April 1 - 10, 2019. Please consider participating in this review. The success of Boost is partially a result of the quality review process which is conducted by the community. You are part of the Boost community. I will be grateful to receive a review based on whatever level of effort or time you can devote. Variant2 is a never-valueless C++11/14/17 implementation of std::variant. >From the README: The class boost::variant2::variant<T...> is an almost conforming implementation of std::variant with the following differences: * A converting constructor from, e.g. variant<int, float> to variant<float, double, int> is provided as an extension; * The reverse operation, going from variant<float, double, int> to variant<int, float> is provided as the member function subset<U...>. (This operation can throw if the current state of the variant cannot be represented.) * variant<T...> is not trivial when all contained types are trivial. To avoid going into a valueless-by-exception state, this implementation falls back to using double storage unless * one of the alternatives is the type monostate, * one of the alternatives has a nonthrowing default constructor, or * all the contained types are nothrow move constructible. If the first two bullets don't hold, but the third does, the variant uses single storage, but emplace constructs a temporary and moves it into place if the construction of the object can throw. In case this is undesirable, one can force emplace into always constructing in- place by adding monostate as one of the alternatives. You can find the source code here: <https://github.com/pdimov/variant2> and the documentation here: <https://pdimov.github.io/variant2/doc/html/variant2.html> Please take an early look at the library and ask questions now. Peter Dimov is very active on the Cpplang Slack #boost channel; however, please consider using the Boost Dev or User Mail Lists so that the entire community might benefit from your conversation. Note: The repository contains an expected implementation also; however, that is not being considered in this review. Thank you for your participation! michael -- Michael Caisse Ciere Consulting ciere.com

5 12

GSoC'19 [Boost.Geometry : Implementing algorithms for the concave hull problem]
by yaghyavardhan singh khangarot 06 Apr '19

06 Apr '19

Hi, I am interested in contributing to Boost.Geometry and would like to work on the Project 1 (Implementing algorithms for the concave hull problem) as my GsoC’19 project. I had some discussion regarding this with Adam Wulkiewicz. I have read the paper ( Moreira, Adriano J. C., and Maribel Yasmina Santos. “Concave hull: A k-nearest neighbors approach for the computation of the region occupied by a set of points.”) and currently going through the paper “A New Concave Hull Algorithm and Concaveness Measure for n-dimensional Datasets*” ( https://www.iis.sinica.edu.tw/page/jise/2012/201205_10.pdf )) . These are the papers given in the project description. I am also searching for any other algorithms (newer or better) for the concave hull problem. Please direct me to any other algorithms related to this project. Regards Yaghyavardhan

2 3

Master branch open for merging
by Marshall Clow 03 Apr '19

03 Apr '19

The master branch is is now open for post-beta merges, but only as described in the Post-Beta Merge Policy. See < https://github.com/boostorg/boost/wiki/Releases%3A-Beta-Merge-Policy> -- The Boost Release Team

11 48

[gsoc19] Seeking a mentor for Boost.GIL project
by Igor Antropov 02 Apr '19

02 Apr '19

DearSir/Madam, My name isIgor Antropov and I would like to participate in GSoC 2019.I amfirst-year undergraduate master majoring in Software Engineering at ITMOUniversity (Saint Petersburg National Research University of Information Technologies,Mechanics and Optics).I aminterested in computer vision and C++. I have made AR-application using Unityand OpenCVForUnity at my third-year of bachelor degree. Unfortunately, thatOpenCVForUnity was based on OpenCV version 2.1 or smaller and was the only onefree to use. There was no algorithm for markers detection, so I had to codeit. At the fourth-year, I have implementobject tracking algorithm with C++ and OpenCV using HOG features and colornames features. Additionally, I havebeen working as programmer with Qt for 1 year. I aminterested in implementation of different algorithms using GIL, so I propose toimplement some image feature detection and matching algorithms. For example,ORB keypoints detector(http://www.willowgarage.com/sites/default/files/orb_final.pdf) and brute-forcematching. Besides, I think Boost.GIL numeric algorithms can have some improvements (add 2D convolution, add convolve_option_extend_reflect as convolve_boundary_options). If Boost.GIL users need some other algorithms to be implemented,please contact me. As my competencytest, I have implement a simple Canny edge detection algorithm using GIL. https://github.com/boostorg/gil/pull/258 Sincerely, IgorAntropov

2 1

[gsoc19] Seeking a mentor for Boost.Geometry project related to triangulation and random sampling
by Tinko Bartels 01 Apr '19

01 Apr '19

Hi, I am interested in participating in this year's Google Summer of Code with a contribution to Boost.Geometry. I am looking for mentors and I understand that potential mentors for Boost.Geometry-related projects are Vissarion Fysikopoulos and Adam Wulkiewicz. My proposal is a project that is based on project 3 and 4 for Boost.Geometry in the Wiki. I propose to add concepts for triangles, triangulation, and point-generators for random sampling, as well as corresponding models and an algorithm for Delaunay-triangulation with parametrizable geometric predicates. The first draft of my proposal can be found here: https://docs.google.com/document/d/17M44Hpn0KMuECztCbkvTYIeN2EiXbMAUsVni22K… My implementation of the tasks in the competency tests can be found here: https://tinko92.github.io/boost_geometry_GSoC_2019_project_3_4_test/ I'd be thankful for any feedback. Kind regards, Tinko Bartels -- Sent from: http://boost.2283326.n4.nabble.com/Boost-Dev-f2600599.html

3 10

[format] Allow the format library to use std::optional
by Sean Farrow 30 Mar '19

30 Mar '19

Hi, Would be possible/desired to allow boost.format to use std::optional instead of boost.optional when compiling a C++17 project. I've raised a GitHub issue to resolve this: https://github.com/boostorg/format/issues/63 I would be happy to do this if it were warranted. Kind regards Sean.

1 0

Re: [boost] [Boost-build] Building Boost 1.69 with Visual Studio 1.69
by Steven Watanabe 29 Mar '19

29 Mar '19

AMDG On 3/27/19 12:02 PM, Paul Bristow wrote: >> <snip> > I was fully up-to-date on develop yesterday, and installed git a week ago (new machine ;-) ). > The current revision of Boost.Build in develop should be e22a75c8 (March 18) > I am also slightly concerned that specifying the cl.exe fully may not be updated when Visual studio is updated, as happens today? > But it does seem to using the new compiler version, even though the full cl.exe file specification is no longer correct. > Similarly vsvarsall.bat location in the set command will change. > > But I am getting Boost library files built OK for several compilers and versions, so that's progress. > Hmm. It looks like VS2019 isn't being autodetected. It seems to be working for Tom's test runners. Maybe see what you get from: vswhere -latest -products * -requires Microsoft.VisualStudio.Component.VC.Tools.x86.x64 -property installationPath -version "[16.0,17.0)" (This is how Boost.Build tries to detect VS2019.) In Christ, Steven Watanabe

6 12

Regarding BOOST.Astronomy
by Sarthak Singhal 29 Mar '19

29 Mar '19

Hello everyone, I am not able to understand what exactly is to be done to complete the parser for FITS and I have also tried understanding the codebase but I am not getting what is the work done till now. Can you also provide some resources? Thanking you Sarthak Singhal

4 3

[visibility][test][osx] visibility warnings with 1.70beta
by Raffi Enficiaud 28 Mar '19

28 Mar '19

Hi, I have a side project that requires boost.test and I thought it is the right time to use the beta build of 1.70. At link time for my project (in this case a simple boost.test module), I have tons of warnings like the following: ld: warning: direct access in function 'boost::unit_test::decorator::depends_on::apply(boost::unit_test::test_unit&)' from file '/Users/raffi/from-big-laptop/code/software_workshop/sw_thirdparties/osx/boost_1_70_0_b1/lib/libboost_unit_test_framework-xgcc42-mt-x64-1_70.a(decorator.o)' to global weak symbol 'boost::unit_test::basic_cstring<char const>::null_str()::null' from file '/Users/raffi/code/mpi/mpi_kmeans/build/MPI-Kmeans.build/Debug/test_mpi_kmeans.build/Objects-normal/x86_64/test_cls_and_func_impl.o' means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings. running Xcode 10.1 on 10.14/mojave. I am building boost like this: ./b2 \ cflags="-mmacosx-version-min=10.10" \ cxxflags="-std=c++11 -stdlib=libc++ -mmacosx-version-min=10.10" \ mflags="-mmacosx-version-min=10.10" \ mmflags="-mmacosx-version-min=10.10" \ linkflags="-stdlib=libc++ -mmacosx-version-min=10.10" \ --prefix=`pwd`/../${build_folder} \ --without-log \ --layout=versioned \ install Each of the files that are being built in my project and that are raising the warning have a compilation command like this: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ -DBOOST_ALL_NO_LIB -DKMEANS_VERBOSE=0 -I/Users/raffi/code/mpi/mpi_kmeans/include -I/Users/raffi/code/mpi/mpi_kmeans/applications/include -isystem /Users/raffi/from-big-laptop/code/software_workshop/sw_thirdparties/osx/boost_1_70_0_b1/include/boost-1_70 -O3 -DNDEBUG -std=gnu++11 -o CMakeFiles/test_mpi_kmeans.dir/test/test_kmeans.cpp.o -c /Users/raffi/code/mpi/mpi_kmeans/test/test_kmeans.cpp which is pretty much what I had so far and before 1.70. Boost.test is using BOOST_SYMBOL_VISIBLE to make a symbol public, including the static build variant. Why does the linker say """ This was likely caused by different translation units being compiled with different visibility settings. """ is completely unclear to me. How can I inspect what b2 emits as compilation command line for further debugging? All those visibility issues are causing me a lot of headache :) Thanks! Raffi

3 5

Gsod19 interest
by Damian Vicino 27 Mar '19

27 Mar '19

I'm wondering if there is interest to make boost participate in the Google season of docs. The program is similar to Google summer of code in many ways, but the outcome is production of documentation. It Details: g.co/seasonofdocs <https://developers.google.com/season-of-docs/>

5 15

[GSOC 2019]
by shehab alaa 27 Mar '19

27 Mar '19

Hi, I’m student willing to participate in GSOC 2019. I have finished my competency test for Boost.uBLAS and I have interest in projects 2 (Adding new numerical linear and multilinear algebra algorithms).So I’m writing looking for mentor who have interest to guide me. And here is my GitHub link for competency test https://github.com/Shehabalaa/CompetencyTest Best regards, Shehab Alaa

2 1

Re: [boost] [review][variant2] Variant2 Review Starts April 1
by dariomt＠gmail.com 26 Mar '19

26 Mar '19

> > The class boost::variant2::variant<T...> is an almost conforming > implementation of std::variant with the following differences: > I see the useful comparison to std::variant in the doc, however I'm using boost::variant extensively in my code. It would be very useful to have also a short comparison to boost::variant in the doc, as I would expect many more current users of the venerable boost::variant than of its much younger cousin std::variant. Thanks!

6 8

Building Boost 1.69 with Visual Studio 1.69
by Trueman, Chris 26 Mar '19

26 Mar '19

Maybe I'm getting ahead of myself given the recent topic about picking a version number for the latest MSVC toolset but I'm having trouble building boost 1.69 with Visual Studio 2019 preview. I blindly assumed the toolset was 14.20 (given the directory where cl.exe is found). Letting b2 determine the version yields vc141 in the lib names. Trying to force 142 with: using msvc : 14.2 : <path to cl.exe> ; in project-config.jam yields errors about unescaped characters. Suggestions welcomed. Chris. INTELLICORP LEGAL NOTICE: This E-Mail message and all attachments transmitted with it are intended solely for the use of the addressee and may contain legally privileged and confidential information. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution, copying or other use of this message or its attachments is strictly prohibited. If you received this message in error, please notify the sender immediately by replying to this message, and then delete it.

6 11

[fibers] Great amount of errors and warnings raising out of valgrind
by Stephan Menzel 26 Mar '19

26 Mar '19

Hello all, I was just in the process of doing vagrind runs on a server process that recently switched to an architecture using boost fibers. Specifically buffered_channel as a number of worker fibers run in a thread. The process was regularily checked with valgrind before but now I'm getting overwhelmed by the amount of messages. Uninitialized values, invalid writes and reads all across the board and all seem to come out of fibers. I see no direct mention of my code. A few samples: ==8024== Thread 1: ==8024== Conditional jump or move depends on uninitialised value(s) ==8024== at 0x454F98: unique (circular_list_algorithms.hpp:112) ==8024== by 0x454F98: empty (list.hpp:540) ==8024== by 0x454F98: boost::fibers::buffered_channel<std::function<void ()> >::close() (buffered_channel.hp ==8024== by 0x454FDB: boost::fibers::buffered_channel<std::function<void ()> >::~buffered_channel() (buffere ==8024== by 0x4376BF: operator() (unique_ptr.h:78) ==8024== Invalid read of size 8 ==8024== at 0x9C1756: boost::fibers::context::~context() (in /my_server) ==8024== by 0x9C31CF: boost::fibers::main_context::~main_context() (in /my_server) ==8024== by 0x6B0B85E: __call_tls_dtors (in /usr/lib64/libc-2.26.so) ==8024== by 0x5D49558: start_thread (in /usr/lib64/libpthread-2.26.so) ==8024== by 0x6BC92FE: clone (in /usr/lib64/libc-2.26.so) ==8024== Address 0xa6f0010 is 32 bytes inside a block of size 232 alloc'd ==8024== at 0x4C2D1DA: operator new(unsigned long) (vg_replace_malloc.c:334) and thousands more similar to this. Now, is there something about fibers that causes this as false positives (such as valgrind not knowing about fibers or coroutines) or is there an underlying problem here? This is running on AWS Linux 2, built with gcc 7.3, boost 1.69. Multithreaded release build with debug info. Nothing out of the ordinary. I am a bit concerned about this and wanted to let the list know. Can provide more output on demand. Cheers, Stephan

2 2

Re: [boost] [review][variant2] Variant2 Review Starts April 1
by dariomt＠gmail.com 26 Mar '19

26 Mar '19

> > On Mon, 25 Mar 2019 at 17:18, dariomt--- via Boost <boost(a)lists.boost.org> > wrote: > > > ... as I would expect many more current users of the venerable > > boost::variant than of its much younger cousin std::variant. > > > > Why do you expect that and do you think that will stay that way? Well, Boost.Variant has been around so much more time than std::variant, so this seems obvious to me. For new code, maybe people will just use std::variant, but there's more old code than new code. Also, I'd say the cost of migrating from Boost.Variant to std::variant is non-zero, and the benefits are not clear (to me), so I'd expect not many people to undergo this migration. My feeling is that the library is aimed at current users of std::variant, offering a "better" pin-compatible alternative, but if I'm using Boost.Variant I believe I also should be considered a potential user. That's why I'm curious about the Boost.Variant2 review, we might get more clarity by comparing the three versions, and we may even get guidance for a migration path from Boost.Variant to Boost.Variant2. > My > personal feeling is that C++17-use is picking up at break-neck speed. For > good or for worse, although there appears to be a lot of controversy over a > (any) variant [and there are quite some quite different implementations > around], the std::variant is the one in the std, which seems to give it a > head start. Well, in my (limited) experience Boost is ubiquitous, so being in std is not that much of a head start. > In my view there can only be one objective with boost varant2, > and that is if it is decided [here] that it is (much) better than the > current std::variant, the C++20 std::variant should be/become the proposed > boost::variant2. > > degski > I wonder if code dealing explicitly with valueless_by_exception() will break if you make this change.

2 1

Re: [boost] [review][variant2] Variant2 Review Starts April 1
by dariomt＠gmail.com 26 Mar '19

26 Mar '19

> > dariomt--- wrote: > > > The class boost::variant2::variant<T...> is an almost conforming > > > implementation of std::variant with the following differences: > > > > > > I see the useful comparison to std::variant in the doc, however I'm > using > > boost::variant extensively in my code. > > > > It would be very useful to have also a short comparison to > boost::variant > > in the doc, as I would expect many more current users of the venerable > > boost::variant than of its much younger cousin std::variant. > > The main difference is that Variant2 is a pin-compatible replacement for > std::variant, whereas Boost.Variant isn't (at least for now). So it's > easier > to switch from std::variant to Variant2 and back (depending f.ex. on > whether > std::variant is available.) > > The second most important difference would probably be the fact that > Boost.Variant may do heap allocations. > This is useful info, thanks! I understand that the main objective is to offer a "better" std::variant, but as a user of Boost.Variant wondering "Should I consider migrating to Boost.Variant2?", I would expect a section in the doc addressing this question.

1 0

Which forum to handle issues/questions regarding libraries
by Robert Ramey 25 Mar '19

25 Mar '19

I've been studying the boost multiprecision library and I have a few questions relating to various aspects of said library. These questions are quite specific to that library and I'm not sure that they are of wider interest other than to a couple people. So I'm wondering if it would be better to post these as library issues on github or on this list or both. It used to be simple but now we have at least three places to discuss these things: slack, here and github issues for the library in question. Also sometimes some PRs can highlight differences which can get ironed out in the PR comments. Do we have a consensus as to the preferred way to select the correct forum? Robert Ramey

5 4

Looking for a Mentor: GSoC 19: Boost.uBLAS: Linear and Multilinear...: Project 1 and 2
by forcha glen 24 Mar '19

24 Mar '19

Hello, I am interested in any of these two projects. I do not yet have a mentor. I need mentor. Regards, Glen

2 1

Re: [boost] Master branch open for merging
by Nikita Kniazev 22 Mar '19

22 Mar '19

I would like to merge Spirit to master. The develop contains bunch of minor changes, but I important ones are: Endian namespace pollution and macros conflict fixes: https://github.com/boostorg/spirit/commit/6c258d506c2bbadccdb9f25e481984aca… https://github.com/boostorg/spirit/commit/74c0ec310a2345cb95ffb947327f69007… https://github.com/boostorg/spirit/commit/9d48b5a23197bbbcc4a3a8990c164b1cf… GCC 6/7 regression avoidance: https://github.com/boostorg/spirit/commit/8bd9b6ece40f9324a902bb0f726e785ff… The regression matrix is green for two weeks.

2 1

[release] Boost 1.70.0 Beta 1 is now available
by Marshall Clow 22 Mar '19

22 Mar '19

[ resending with a non-empty subject line ] Boost release 1.70.0 beta 1 is now available at: <https://dl.bintray.com/boostorg/beta/1.70.0.beta1/source/> The SHA256 checksums are as follows: dbf89645e509acb2e53eac3c633834f1dec80bd8622e6e652a9741dcf0807f17 ./boost_1_70_0_b1.7z 957b984b58656a3ec00661ecad7ef82e3a094bad36e37b9e6624843237854679 ./boost_1_70_0_b1.tar.bz2 76d149c1fb9e8a5ceb3bc1e5587edc40fa79a43e8b990d877c2210f0382b9421 ./boost_1_70_0_b1.tar.gz 71e990b2c26880521fd98459b184ee172ce1c46dcf554b6eaab7776b8b6369a6 ./boost_1_70_0_b1.zip For details of what's in the release, see < https://www.boost.org/users/history/version_1_70_0.html>. Please download the beta, give it a try, and report any problems you encounter. Thanks, -- The Boost Release Team

6 14