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

github pull request process on non-owned submodule
by Jeff Garland 22 Mar '20

22 Mar '20

Sorry if this is obviously documented somewhere, but searches of mailing list aren't helping. I'm looking to submit a pull request for the icl library to remove dependencies on date_time compiled library -- in conjunction with changes to date_time on develop now. I've basically followed the cheat sheet on the wiki: https://github.com/boostorg/wiki/wiki/Getting-Started%3A-Cheat-Sheet but when I try to push my branch I get permission errors. Is there something I did wrong or is the icl repo setup wrong? Thx, Jeff jeff@jeff-mint193:~/dev/boost/libs/icl$ git push origin dt_nolib Username for 'https://github.com': JeffGarland Password for 'https://JeffGarland@github.com': remote: Permission to boostorg/icl.git denied to JeffGarland. fatal: unable to access 'https://github.com/boostorg/icl.git/': The requested URL returned error: 403

2 2

Fwd: Projects for GSoC 2020
by degski 20 Mar '20

20 Mar '20

---------- Forwarded message --------- From: degski <degski(a)gmail.com> Date: Sun, 1 Mar 2020 at 17:00 Subject: Re: [boost] Projects for GSoC 2020 To: David Bellot <david.bellot(a)gmail.com> Yes. On Sun, 1 Mar 2020 at 04:26, David Bellot <david.bellot(a)gmail.com> wrote: > It sounds a good idea to me. Would you like to propose a project and be a > mentor? > It would be great! > > David > > On Thu, Feb 27, 2020 at 8:19 AM degski via Boost <boost(a)lists.boost.org> > wrote: > >> On Wed, 26 Feb 2020 at 14:39, David Bellot via Boost < >> boost(a)lists.boost.org> >> wrote: >> >> > Hi Boost community, >> > >> > so far we received a few good contributions for projects for GSoC 2020. >> The >> > proposals are from our usual mentors but I'm surprised we don't have >> more >> > projects in data structures and algorithms. Most of what we have concern >> > numerical problems. It's great but I wish to see more diversity in the >> type >> > of projects we propose. >> > >> >> Maybe the suggestions put forward do solicit few 'other' proposals. For >> containers, f.e. there are many 'entertaining' and useful things to >> consider, segment tree, spaghetti stack, trie, binary index tree, beap, >> kd-tree, bkd-tree, disjoint-set, n-ary tree, etc etc, etc. >> https://www.geeksforgeeks.org/advanced-data-structures/ presents many >> different data structures, there also a section on algos. >> >> degski >> -- >> @realdegski >> https://brave.com/google-gdpr-workaround/ >> "We value your privacy, click here!" Sod off! - degski >> "Anyone who believes that exponential growth can go on forever in a finite >> world is either a madman or an economist" - Kenneth E. Boulding >> "Growth for the sake of growth is the ideology of the cancer cell" - >> Edward >> P. Abbey >> >> _______________________________________________ >> Unsubscribe & other changes: >> http://lists.boost.org/mailman/listinfo.cgi/boost >> > -- @realdegski https://brave.com/google-gdpr-workaround/ "We value your privacy, click here!" Sod off! - degski "Anyone who believes that exponential growth can go on forever in a finite world is either a madman or an economist" - Kenneth E. Boulding "Growth for the sake of growth is the ideology of the cancer cell" - Edward P. Abbey -- @realdegski https://brave.com/google-gdpr-workaround/ "We value your privacy, click here!" Sod off! - degski "Anyone who believes that exponential growth can go on forever in a finite world is either a madman or an economist" - Kenneth E. Boulding "Growth for the sake of growth is the ideology of the cancer cell" - Edward P. Abbey

3 7

binomial distribution setter function
by Kemin Zhou 18 Mar '20

18 Mar '20

This is my first time posting in this mailing list. Not sure how to post to the developer only mailing list after reading the document for mailing list for a good half an hour. If I posted in he wrong mailing please let me know and kindly provide the developer mailing list. I am looking at the binomial.hpp file. I need to use the binomial object in a loop which requires to have high performance. I am thinking constructing the binomial object each time in the loop would be less efficient than if I construct a single object, the each time reset the p parameter and use the object. I am not sure why the setter method was not provided. 296 RealType success_fraction() const 297 { // Probability. 298 return m_p; 299 } 300 void set_success_fraction(RealType p) { 301 m_p=p; 302 } Line 296 is the getter method, I added the setter method at line 300. -- Kemin Zhou 858 366 8260

4 4

Boost.Nowide Ready for release
by Alexander Grund 16 Mar '20

16 Mar '20

Hi all, after the discussion in January this year I took over maintenance of Boost.Nowide. First goal: Integrate all changes and requests that came up during review and as Github Issues including the docs. Second goal: Get extensive CI running with coverage especially on Windows (it is a mainly Windows library) Third goal: Iron out bugs, performance issues and incompatibilities. Of great help was my fork I prepared (and announced here) earlier but it was still an incredible amount of work. I can now say I'm done! I invite everyone to test it, (re-)review the code or check the docu for anything that's missing: https://github.com/boostorg/nowide One of the bigger changes was to make the library "less header-only" (it already required compilation on Windows when using iostreams). This was due to some required functions being considered extensions by e.g. MinGW/Cygwin and hence failing for consumers build with `-std=c++98` (or similar). This now works! Final note for those interested: The standalone (non-Boost) version and converter will be available later. Happy poking!

3 3

[gil] Broken bit-aligned pixel locator on MSVC++ 64-bit optimized builds only
by Mateusz Loskot 14 Mar '20

14 Mar '20

Hi, Over the last few months, intermittently I've been chasing a peculiar bug that has been revealing itself in failing checksum tests in GIL's test/legacy/image.cpp [1] since we started testing GIL with MSVC++ (VS2017, VS2019) with b2 toolset=msvc variant=release address-model=64 [1] https://github.com/boostorg/gil/blob/2ff2d31895dae665ef3e05d0496bc082470e22… The peculiarity of this bug is that it has not been observed using any of these compilers: - GCC: 4.8, 4.9, 5, 6, 7, 8, 9 - Clang: 3.9, 4.0, 5.0, 6.0, 7, 8, 9, 10 - XCode: 8.3, 9.0, 9.1, 9.2, 9.3, 9.4, 10 There is complete report [2], but I also decided to reach the list looking for any insights that may help me to understand what may be causing the bug. Complete repo [3] has GitHub Actions to build and run minimal_test.cpp test. [2] https://github.com/boostorg/gil/issues/447 [3] https://github.com/mloskot/boost-gil-checksum-bug This minimal_test.cpp (at the bottom) leaves out the checksum calculation and narrows the scope of the bug down to the `xy_locator` and advances of the iterators. The test basically is this: 1. Create 3x3 image based on bit-aligned BGR or RGB pixel (e.g. bgr121_image_t) 2. Fill image with red 3. Draw blue diagonal ``` bgr121_image_t img(3, 3); // ... fill img with `bgr121_red` pixels // draw blue diagonal auto v = view(img); auto loc = v.xy_at(0, v.height() - 1); for (std::ptrdiff_t y = 0; y < v.height(); ++y) { *loc = bgr121_blue; // set blue pixel value ++loc.x(); // INCREMENT X FIRST --loc.y(); } ``` If the loop like this is compiled using either - `b2 toolset=msvc variant=release address-model=64 optimization=space` (/O1 /Ob2) - `b2 toolset=msvc variant=release address-model=64 optimization=speed` (/O2 /Ob2) then pixels of the blue diagonal are messed up. If the loop is compiled without optimization using either - `b2 toolset=msvc variant=debug address-model=64` (/Od /Ob2) - `b2 toolset=msvc variant=release address-model=64 optimization=off` (/Od /Ob2) then pixels of the blue diagonal are correct. Now, if the `for` loop above is modified, that is, lines incrementing the `x_iterator` and `y_itertor` are reordered: ``` for (std::ptrdiff_t y = 0; y < v.height(); ++y) { *loc = bgr121_blue; // set blue pixel value --loc.y(); ++loc.x(); // PRE-INCREMENT X SECOND } ``` or ``` for (std::ptrdiff_t y = 0; y < v.height(); ++y) { *loc = bgr121_blue; // set blue pixel value --loc.y(); ++loc.x(); // POST-INCREMENT X SECOND } ``` then the blue diagonal is drawn correctly regardless of the MSVC++ optimizations. If the loop is manually unrolled, see minimal_test.cpp below, the blue diagonal is correct too. I'm yet to try the CE to see compare the generated code, as far as my limited assembly fu goes, but currently Boost for MSVC++ on CE is broken (https://github.com/mattgodbolt/compiler-explorer/issues/1816) If anyone would have any insights on what may be causing the problem, or any suggestions what else to test, I would greatly appreciate that. Obviously, I'm getting suspicious about the MSVC++ optimizer, but I do know blaming a compiler is last+1 resort :) Thanks Mateusz ``` // minimal_test.cpp #include <boost/version.hpp> #include <boost/core/lightweight_test.hpp> #if BOOST_VERSION < 106900 #include <boost/gil/gil_all.hpp> #else #include <boost/gil.hpp> #endif namespace gil = boost::gil; #if BOOST_VERSION > 107200 using channel_sizes_t = boost::mp11::mp_list_c<int, 1, 2, 1>; #else using channel_sizes_t = boost::mpl::vector3_c<int, 1, 2, 1>; #endif using bgr121_ref_t = gil::bit_aligned_pixel_reference < std::uint8_t, channel_sizes_t, gil::bgr_layout_t, true > const; using bgr121_image_t = gil::image<bgr121_ref_t, false>; using bgr121_view_t = typename bgr121_image_t::view_t; using bgr121_pixel_t = typename bgr121_view_t::value_type; bgr121_pixel_t bgr121_red(0), bgr121_blue(0); void fill_image_red(bgr121_image_t& img) { gil::rgb8_pixel_t red8(255, 0, 0); gil::rgb8_pixel_t blue8(0, 0, 255); gil::color_convert(red8, bgr121_red); gil::color_convert(blue8, bgr121_blue); auto v = view(img); std::fill(v.begin(), v.end(), bgr121_red); for (auto it = view(img).begin().x(), end = view(img).end().x(); it != end; ++it) BOOST_TEST(*it == bgr121_red); } void test_draw_with_xy_locator_loop_fail(std::ptrdiff_t w, std::ptrdiff_t h) { bgr121_image_t img(w, h); fill_image_red(img); { auto v = view(img); auto loc = v.xy_at(0, v.height() - 1); for (std::ptrdiff_t y = 0; y < v.height(); ++y) { *loc = bgr121_blue; // OPTION 1 FAILS ++loc.x(); // PRE-INCREMENT X FIRST --loc.y(); // OPTION 2 FAILS TOO //loc.x()++; // POST-INCREMENT X FIRST //loc.y()--; // OPTION 3 FAILS TOO //auto& x_it = loc.x(); // PRE-INCREMENT NAMED X FIRST //++x_it; //auto& y_it = loc.y(); //--y_it; } } { auto it = view(img).begin().x(); // row 0 BOOST_TEST(*it == bgr121_red); ++it; BOOST_TEST(*it == bgr121_red); ++it; BOOST_TEST(*it == bgr121_blue); ++it; // row 1 BOOST_TEST(*it == bgr121_red); ++it; BOOST_TEST(*it == bgr121_blue); ++it; // FAIL BOOST_TEST(*it == bgr121_red); ++it; // row 2 BOOST_TEST(*it == bgr121_blue); ++it; BOOST_TEST(*it == bgr121_red); ++it; BOOST_TEST(*it == bgr121_red); } } void test_draw_with_xy_locator_loop_good(std::ptrdiff_t w, std::ptrdiff_t h) { bgr121_image_t img(w, h); fill_image_red(img); { auto v = view(img); auto loc = v.xy_at(0, v.height() - 1); for (std::ptrdiff_t y = 0; y < v.height(); ++y) { *loc = bgr121_blue; // OPTION 1 WORKS --loc.y(); ++loc.x(); // PRE-INCREMENT X SECOND // OPTION 2 WORKS TOO //loc.y()--; //loc.x()++; // POST-INCREMENT X SECOND } } { auto it = view(img).begin().x(); // row 0 BOOST_TEST(*it == bgr121_red); ++it; BOOST_TEST(*it == bgr121_red); ++it; BOOST_TEST(*it == bgr121_blue); ++it; // row 1 BOOST_TEST(*it == bgr121_red); ++it; BOOST_TEST(*it == bgr121_blue); ++it; BOOST_TEST(*it == bgr121_red); ++it; // row 2 BOOST_TEST(*it == bgr121_blue); ++it; BOOST_TEST(*it == bgr121_red); ++it; BOOST_TEST(*it == bgr121_red); } } void test_draw_with_xy_locator_step_good(std::ptrdiff_t w, std::ptrdiff_t h) { bgr121_image_t img(w, h); fill_image_red(img); { auto v = view(img); auto loc = v.xy_at(0, v.height() - 1); *loc = bgr121_blue; // red red blue ++loc.x(); --loc.y(); *loc = bgr121_blue; // red blue red ++loc.x(); --loc.y(); *loc = bgr121_blue; // blue red red ++loc.x(); --loc.y(); } { auto it = view(img).begin().x(); // row 0 BOOST_TEST(*it == bgr121_red); ++it; BOOST_TEST(*it == bgr121_red); ++it; BOOST_TEST(*it == bgr121_blue); ++it; // row 1 BOOST_TEST(*it == bgr121_red); ++it; BOOST_TEST(*it == bgr121_blue); ++it; BOOST_TEST(*it == bgr121_red); ++it; // row 2 BOOST_TEST(*it == bgr121_blue); ++it; BOOST_TEST(*it == bgr121_red); ++it; BOOST_TEST(*it == bgr121_red); } } int main() { test_draw_with_xy_locator_loop_fail(3, 3); test_draw_with_xy_locator_loop_good(3, 3); test_draw_with_xy_locator_step_good(3, 3); return boost::report_errors(); } ``` Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

1 1

[website] Update notes of historic releases
by Mateusz Loskot 11 Mar '20

11 Mar '20

Hi, Is this possible to update release notes of historic releases? I'd like to update notes of GIL for 1.69 which, as I found, have been never collected and are completely missing https://github.com/boostorg/gil/commit/2ff2d31895dae665ef3e05d0496bc082470e… Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

2 2

C++ Deflate (zlib-like) library
by Janson R. 11 Mar '20

11 Mar '20

Hello everyone, I have recently been working on a C++ compression library very similar to zlib after trying to implement some HTTP compression support over Boost.Beast and realizing after some discussion with sir Falco that while it would be a nice builtin feature for Beast, it would possibly be a better idea to have zlib-like compression be a separate library in order to be properly maintainable and likely more useful. The current working version can be viewed at https://github.com/ryanjanson/Deflate however the API could still be helped in terms of modern C++ usability, and what I currently have in mind can be found annotated here: https://gist.github.com/AeroStun/687ec9ca69404e26f8e02e5084926036 Do you thing that this could be useful to have as its own entity in the Boost environment? Any kind of feedback on the idea and the library is warmly welcome. Regards, Janson

14 58

boost thread strange behaviour
by Adham Sabry 08 Mar '20

08 Mar '20

hi , i am trying to learn executors and executors thread pools using with boost::async but i found strange behabiour when i make thread pool adaptor ea and submit tasks to it and make ea00 and submit tasks to it if i started ea with async , it automatically starts ea00 the attached file has the code i thought that async will only start the passed thread pool"adaptor" But i think there is underlying thing which gather all threads of different pools into single entity and starts them with any call to boost::async is this a bug??? i run this from windows 7 64 by visual studio 2017

3 7

[GSoC20] [Boost.Geometry] Seeking mentor for project 1
by João Tavares 07 Mar '20

07 Mar '20

Hello, I am a third year undergraduate student from IST - University of Lisbon in Applied Mathematics and Computer Science. I am very interested in the project 1 on the Boost.Geometry library. Having dealt with this sort of problem both on my university courses and on my own, in the context of competitive programming, I feel like I could contribute to this project during GSoC 2020. Regarding the competency test I have not been able to understand how or where it should be submitted. I am sending this e-mail to know whether there is someone willing to mentor me for this project. Thanks for the replies in advance. Best regards, João Tavares IST - University of Lisbon

2 1

ublas GSOC'20 Project
by Mrityunjay Tripathi 07 Mar '20

07 Mar '20

Hi everyone, I am Mrityunjay Tripathi, a 3rd-year Computer Science & Engineering undergraduate. I have been getting familiar with the boostorg/math and boostorg/ublas repositories for quite a few weeks. I find it quite interesting in terms of the functionalities they provide. But I see that the tensors section of uBLAS can be more improved by parallelizing the code using OpenMP and providing support for cuBLAS. I also wanted to add flexible NumPy/PyTorch tensor features such as autograd on tensors. Any feedback or suggestions are most welcome. Best Regards, Mrityunjay Tripathi

1 0

Hello!
by Kishan shukla 07 Mar '20

07 Mar '20

Hello Everyone! My name is Kishan Shukla, and I am a third-year undergraduate student of mathematics at IIT Kanpur. I am interested in contributing to Boost.real and have already sent two PR's https://github.com/BoostGSoC19/Real/pull/40 and https://github.com/BoostGSoC19/Real/pull/41, which are yet to be reviewed. Currently, I am stuck at a problem that I want to discuss with the mentors. Can I ask the project-specific issues here, or are there project-specific channels?

2 1

[build] ERROR: rule "[[bbv2.builtin.features.warnings]]`warnings`::" unknown in module "warnings-feature"
by Mateusz Loskot 06 Mar '20

06 Mar '20

Hi, (CC'ed to boost and boost-build) Two of Boost.Geometry users reported that peculiar error, [1] and [2] ``` /home/digu_j/boost/tools/build/src/tools/features/warnings-feature.jam:27: in load ERROR: rule "[[bbv2.builtin.features.warnings]]`warnings`::" unknown in module "warnings-feature". ``` and I'm having a hard time understanding what is going wrong here and what causes this issue, on Linux. The line 27 is a typical Jam line: ``` feature.feature warnings : on all extra pedantic off : incidental propagated ; ``` but this refers to something that puzzles me most ``` ERROR: rule "[[bbv2.builtin.features.warnings]]`warnings`::" unknown ``` a bit of comment block? ``` #| tag::doc[] [[bbv2.builtin.features.warnings]]`warnings`:: ``` Is this a parsing issue? Is this related to potentially existing system-wide installation of Boost.Build? If yes, why none of the dumps in [1] and [2] refer to any files in /usr? [1] ./b2 headers attempt https://github.com/boostorg/geometry/pull/667#issuecomment-584794370 [2] b2 attempt to build a program in libs/geometry https://github.com/boostorg/geometry/pull/665#issuecomment-595595900 Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

2 2

[date-time] USE_DATE_TIME_PRE_1_33_FACET_IO to be removed in next release
by Jeff Garland 06 Mar '20

06 Mar '20

//crosspost from users list In case you've not checked the calendar (see below) it's 2020 and a the c++ world has moved on from the issue this macro solved. boost date-time also needs to move forward into the decade with a modernized all header code base . If you're dependent on this macro for any reason I'd like to hear about it. Thanks, Jeff using namespace boost::gregorian; date today = day_clock::local_day(); cout << today.year() << endl; //2020 ;)

1 0

Help: [Boost.GIL] setup
by R Rajiv 06 Mar '20

06 Mar '20

Hi I am Rajiv, a student whose looking to contribute to Boost's GIL library this year for GSOC 2020. I have read through the contribution.md page for setup of the environment for Boost.gil @ https://github.com/boostorg/gil/blob/develop/CONTRIBUTING.md. As I do not have cloning rights for the repo boost.git, I have forked and cloned my fork with --recurse-submodules.This leads me to the following issue: _______ fatal: repository 'https://github.com/rRajivramachandran/accumulators.git/' not found fatal: clone of 'https://github.com/rRajivramachandran/accumulators.git' into submodule path 'libs/accumulators' failed ________ I have been unable to proceed due to this issue. -- Thanks Rajiv

3 2

[program_options] Codecov failing on Travis CI for long time
by Mateusz Loskot 06 Mar '20

06 Mar '20

Hi, I've just submitted my first PR [1] to the library and Travis CI failed with: +lcov --gcov-tool=gcov-7 --rc lcov_branch_coverage=1 --base-directory /home/travis/build/boostorg/boost-root/libs/program_options --directory /home/travis/build/boostorg/boost-root --capture --output-file all.info Capturing coverage data from /home/travis/build/boostorg/boost-root Can't locate PerlIO/gzip.pm in @INC (you may need to install the PerlIO::gzip module) (@INC contains: /etc/perl /usr/local/lib/perl/5.18.2 /usr/local/share/perl/5.18.2 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.18 /usr/share/perl/5.18 /usr/local/lib/site_perl .) at /usr/local/bin/geninfo line 62. BEGIN failed--compilation aborted at /usr/local/bin/geninfo line 62. The command "ci/codecov.sh" exited with 2. I see this failure has been happening for a year now affecting all PRs from that period. I think it's desirable to keep the CI-s green, especially if there is no huge potential of breaking it as the library has not seen much activity. I can't offer a solution myself, but it may ring a bell to maintainer or someone else who knows how to fix it. [1] https://github.com/boostorg/program_options/pull/92 Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

1 0

yabs: Yet Another Build System, seeking input/micro-team member
by degski 03 Mar '20

03 Mar '20

Hi All, Recently, I have started to get more and more dis-enchanted with Windows. The OS is being dumbed down every step of the way, while the internal complexity keeps going up. The latest and the most fun break-down to date of Windows was last week, the story is long, but in the end in came down to not being able to open the system-settings in the W10-style settings. The W7-style settings are also available, but the API's are overlapping but neither is a super-set of the other, so no way to fix the settings, because the settings themselves are broken (had something to do with display-drivers), way to go MS. In the meanwhile W10 is sorted again, but the whole lot is just getting increasingly fragile, while Fedora is getting increasingly solid (no bt-headphone stuttering, while connected to wifi and look at that brightness/crispness of that Full HD screen I have never seen before under W10!), the latter not upping complexity (2'001 packages to download and install to get from F30 to F31, but that's not complexity). I want to move to Fedora, and for now I'm dual-booting. This involves dumping VS in favor of VSCode (which is flat-packed for Fedora and compadres and is also available on OSX, so there is potentially a large audience), no acceptable other options (other than the one(s) VSCode is based on) are available AFAIKS, gnome-builder seems to have different goals from VS and it appears to be early days. VSCode seems (to me) to be like the best thing since sliced-bread, iff you are writing Python or Rust (Prolog works nicely as well), but C++ is only partially great, the language server works very nicely, code completion, good, but the build-system, proposed, is cumbersome. I would like VSCode to work more like VS, but without the complexity, the endless clicking, drop-down boxes etc etc. It comes down to writing json-files, which is good, but on a per project basis. Having to do this on a per project basis is a problem (that's going backwards from using project-templates in VS, I now in VS can create a new project in 3 seconds flat, and every detailed setting (clang and vc) is set correctly and how **I** want it, and I am running "Hello World!" (the default main in the template) in total 10 secs, this very handy to try things out). I don't want to go backwards. Therefore, I would like to do this on a repo-basis (the only one I have), with, iff required, another json in the project-folder (in the parent repo-folder), i.e.: /repos/ /repos/repo.json /repos/project-one/ /repos/project-one/project.json /repos/project-two/ /repos/project-two/project.json /repos/ ... I (want to) use vcpkg. I structure my projects always the same, all build systems (to my purpose) are basically an over-shoot on the one hand and overly fiddly on the other hand. The task at hand, build the .cpp files in the root of the project folder into one binary. The include files are either in the vcpkg/installed/.../include folder or in a sub-include-folder in the project. Libraries to link are either in vcpkg/installed/.../lib, or vcpkg/installed/.../debug/lib. We are not talking rocket-science here, I presume that many people have simple needs like this/me, or that if building (adopting this structure) becomes easy enough people would adopt such a structure. I would like to have one json to rule them all, and one json to either over-ride the defaults, or to add to the defaults, depending on whether the setting is defined in the repo.json. The repo.json might well be layered itself, to accommodate the various compilers, and/or configuration. For the moment nlohman's json seems perfectly adequate for the job, and it's certainly easy to use (and seems to just use std::maps in a clever way, so it's easy to follow what's going on). It's all about merging, fusing, overlaying those json's as needed (gonna be entertaining, making it smart), and pass that on to some generic API for building. So a new compiler would mean to just add a json-section, or a json-file, fill that with appropriate data (possibly nothing, iff the default-defaults are good), and it should work. The current way VSCode is setup, means that this imaginary build-system can be easily and readily included/used in VSCode (with more json). Yes, just like the working name indicates YABS, it must be as simple as possible, but no simpler. Any input is appreciated, but please refrain from arguing that BS-X does this better (and exists) or BS-Y has a large crowd of followers (and is used for a long period of time), that's water under the bridge, I will pursue this, just to see how far one can get pushing these initial ideas further. As usual my write-ups are a bit messy, I am learning I'm slightly dyslexic, sorry for the endless comma's. Thanks in advance for any ideas submitted. I would not mind partnering with somebody else, ya'll have a nice day, degski -- @systemdeg "We value your privacy, click here!" Sod off! - degski "Anyone who believes that exponential growth can go on forever in a finite world is either a madman or an economist" - Kenneth E. Boulding "Growth for the sake of growth is the ideology of the cancer cell" - Edward P. Abbey

1 0

Fwd: Boost.StaticString (formerly Boost.FixedString) is ready for release!
by degski 03 Mar '20

03 Mar '20

---------- Forwarded message --------- From: degski <degski(a)gmail.com> Date: Mon, 2 Mar 2020 at 23:14 Subject: Re: [boost] Boost.StaticString (formerly Boost.FixedString) is ready for release! To: Alexander Grund <alexander.grund(a)tu-dresden.de> On Mon, 2 Mar 2020 at 09:57, Alexander Grund <alexander.grund(a)tu-dresden.de> wrote: > Because if you use a signed type you have no compile-time guarantee that > the value is unsigned (using "type" and "value" to differentiate those 2). > You have indeed the guarantee that it is non-negative, compile-time, the problem is that, although you now know it is positive, you have lost (compile-time) any means of determining whether this value is correct (at run-time), while the guarantee at compile-time is just tautological. I don't understand really what you have against it, one can always use an int64_t, iff worried about int32_t overflow. Same as with a pointer: It can be NULL. > This value of null in itself is nothing special, it points at the top/bottom of the stack, there's nothing, so we hit UB. I don't think this is a good parallel. Pointers are not numbers, addition is meaningless. Adding up sizes is not meaningless, and we do it every day. Adding (or deducting) up a size and a pointer-difference is not meaningless either, that's why size needs to be signed. > If you want an interface where you want to guarantee at compile-time that > the value passed over an API is never NULL, you use e.g. a reference that > can never be NULL (or not_null<T>) > Herb's most recent post puts another angle on this: http://herbsutter.com/2020/02/23/references-simply/ . > > >> Didn't you argue in the mail before that there will never be anything of >> size 2^32 and hence even not anything like 2^64? How could you overflow >> that then? >> > > If you are manipulating (subtracting, adding differences) pointers, I > thought I wrote that. The pointers might be pointers into Virtual Memory > and can have any value [1, 2^56]. > > Not sure I understand that. Can we agree that a 64-bit unsigned type is > big enough to store any size of any container and hence no overflow is > possible? > Yes, certainly, what about a 63-bit value (the positive part of a signed 64-bit int), is that too small? ... signed type which may be an unsigned value. You'll have to check. > No, a signed value is never an unsigned value in disguise (that would result in overflow), the other way around, yes. I disagree. And as mentioned you can do things like `int difference = > int(obj.size()) - 1` anytime you want to do operations that are not fully > defined on unsigned types (as in: may result in values outside the range) > same as you can't to `int foo = sqrt(integer)` because you may get an > imaginary number (if sqrt could do that, but I think you get the gist). > C++ has questionable math's. How is that any different from `assert(a <= size); return size - a;`? > That's not what you wrote earlier. The you introduced a branch in release and made the function throw. > > all that because it upsets you that something that should not occur in > the first place in correct code can occur iff one is writing code that now > (as one observed it got negative) is known to have a bug. > > Again: How is that different to using a signed type for "size"? You have > exactly the same potential for bugs. You always have to make sure you stay > in your valid domain, and a negative size is outside of that valid domain. > Hence you got to check somewhere or use control flow to make sure this > doesn't happen. So no difference in signed vs unsigned size regarding that > The unsigned cannot overflow, that is not a bonus, that's a problem! > The use of unsigned is false security (actually no security) and serves > nothing. In the end, you still need to write correct code (so the signed > int's WON'T BE negative, there where they shouldn't be), but this practice > makes you're code less flexible, more verbose (the unavoidable casts add to > that) and probably slower than using signed. All that because of this > 'natural' way of looking at sizes. > > It serves as a contract on the API level: "This value is unsigned. > Period." > No, it says, if the value is out of the problem domain, don't worry, I'll cover it up (behind you're back so your app appears to be working, I make sure of that at compile-time). If the type was signed you'd need something else to enforce that the value > is unsigned. So yes you still need to write correct code and passing a > negative value to an API expecting an unsigned value is in any case a bug. > Of course, I never said, quite the opposite, that one not needs to write correct code. > Surely at runtime. How else could you guarantee that your value isn't > negative after you subtract something from it? It can be compile-time if > you only add something to it and ignore overflow but you already do that > when using signed values anyway. > > So, why does it need to be guaranteed positive at compile time? It just needs to be positive (size) at run-time, and as per above, you'll have to check. > But all this arguing doesn't solve much: What piece of code would actually > benefit from having a signed size? > I have already spelt out the reasons in an earlier post in this thread. > And not only the part where you request the size and use it, but also the > part where you give that size back to the object, so you'll need to ensure > an unsigned value. And yes `for(int i=0; i<int(obj.size())-1; i++)` is a > known example that would allow to get rid of the cast if the size was > signed. But again: That is due to operation used. `for(unsigned i=0; > i+1<obj.size(); i++)` is perfectly valid assuming no overflow > Thou shall not compare signed and unsigned values, my compilers insist and keep on telling me that. So now you need a cast to shut the thing up, and I would write: for ( int i = 0, back = static_cast<int> ( obj.size ( ) ) - 1; i < back; ++i ). I would like: for ( int i = 0, back = obj.size ( ) - 1; i < back; ++i ). This is my last post on the subject (bar new arguments). Thank you for the discussion. degski -- @systemdeg "We value your privacy, click here!" Sod off! - degski "Anyone who believes that exponential growth can go on forever in a finite world is either a madman or an economist" - Kenneth E. Boulding "Growth for the sake of growth is the ideology of the cancer cell" - Edward P. Abbey -- @systemdeg "We value your privacy, click here!" Sod off! - degski "Anyone who believes that exponential growth can go on forever in a finite world is either a madman or an economist" - Kenneth E. Boulding "Growth for the sake of growth is the ideology of the cancer cell" - Edward P. Abbey

2 2

Boost.StaticString (formerly Boost.FixedString) is ready for release!
by Krystian Stasiowski 02 Mar '20

02 Mar '20

Hi all, After some post-review polishing, Boost.StaticString is good to go for release! I have been in touch with the review manager, and everything has been checked over. Repo: https://github.com/sdkrystian/static_string Docs: https://sdkrystian.github.io/doc/static_string Here are some things that have been changed post-review: - Library has been renamed from Boost.FixedString to Boost.StaticString. Class template fixed_string has been renamed to basic_static_string, and aliases have been added for common character types, similar to std::string. - constexpr support to the fullest extent supported by available compilers has been added. - Functions that will not throw have been marked noexcept. - Moved to a single header configuration. - std::hash and boost::hash_value support has been added. - It has been decided that functions will throw on capacity overflow. - A specialization for when the capacity is 0 has been added that has no member. Additionally, the type of the member used to store the size of the string is now statically chosen to be the smallest possible width unsigned standard integer type that can hold all the needed size values. - operator+ has been implemented. - Floating point conversion support has been added to to_static_string/to_static_wstring. - Lots of bugs fixed. More behind the scenes, a bunch of optimizations have been added, taking advantage of the fact that the capacity is part of the type and known at compile time. Again, thank you all who participated in the review, and thank you Joaquin for managing it! Regards, Krystian Stasiowski

7 16

Projects for GSoC 2020
by David Bellot 01 Mar '20

01 Mar '20

Hi Boost community, so far we received a few good contributions for projects for GSoC 2020. The proposals are from our usual mentors but I'm surprised we don't have more projects in data structures and algorithms. Most of what we have concern numerical problems. It's great but I wish to see more diversity in the type of projects we propose. We want to attract the best students around the world and push toward new C++ standards and improvements of what we already have. Being a mentor is a great experience and on top of it, without too much effort, you will get someone of quality working for you during all the summer. The wiki page for projects is here: https://github.com/boostorg/wiki/wiki/Google-Summer-of-Code%3A-2020 Please come, edit and contribute. Cheers, David

2 2

What is the right way to close and clean boost::log
by JH 01 Mar '20

01 Mar '20

Hi, I built boost::log in my application library, it created boost::log::sinks::synchronous_sink<boost::log::sinks::text_file_backend> and close it by calling the boost::log::core::get()->remove_all_sinks() in destructor of the Log library, then one of my application link to my log library got Segmentation fault when it exited: Program received signal SIGSEGV, Segmentation fault. 0x00007ffff5fdd961 in boost::log::v2_mt_posix::core::remove_all_sinks() () from /usr/lib/x86_64-linux-gnu/libboost_log.so.1.65.1 If I add boost::log::core::get()->remove_all_sinks() in my application main before it return 0, the segmentation was gong, but it stuck. What is the proper right way to close and clean the boost::log? There is a blog suggested to run boost::log::core::get()->remove_all_sinks() when the main end, but that does not seem work. https://www.boost.org/doc/libs/1_62_0/libs/log/doc/html/log/rationale/why_c… Thank you. Kind regards, - jupiter

2 3