- Boost - lists.preview.boost.org

[release] Boost 1.67.0 Beta 1 Release Candidate 2
by Daniel James 16 Mar '18

16 Mar '18

The second release candidates for the 1.67.0 beta release are now available at: <https://dl.bintray.com/boostorg/beta/1.67.0.beta.1/source/> The release notes can be previewed at: <http://www.boost.org/users/history/in_progress.html> The documentation is available at: <http://www.boost.org/doc/libs/1_67_0_beta1/> The SHA256 checksums are as follows: 154cf490da858fd9c2307bb904b07a42cbe8355ecf99d5477f0d843c6d03cdda boost_1_67_0_b1_rc2.7z 0d854b208fefaeb5837d6c417f505b189275e32d017f6226001fb165a5ac51ed boost_1_67_0_b1_rc2.tar.bz2 6eb3f9ca8db355765f41361e1e26976228f0c2dff400aade8a5e97aec6aa59f4 boost_1_67_0_b1_rc2.tar.gz 678a6459f2517932536ec97297be1de46ea073f2e2ee17ec8397b80aa0953f49 boost_1_67_0_b1_rc2.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.

6 8

[gsoc18] sharing of proposal
by vardhan gupta 15 Mar '18

15 Mar '18

Hi, I have shared the 1st draft of my proposal for "adding multicore and GPU computations to uBLAS" through the gsoc portal, but haven't yet gotten any feedback on it. Do I need to share it again on the mailing list too? Regards, Vardhan Gupta

3 3

[qvm] Tait–Bryan/Euler angles implemented for matrices
by Emil Dotchevski 15 Mar '18

15 Mar '18

See: https://boostorg.github.io/qvm/rot_mat.html https://boostorg.github.io/qvm/set_rot_mat.html https://boostorg.github.io/qvm/rotate_mat.html Emil

1 0

[gsoc18] Student proposal reviewing (Internal process)
by madhur4127 14 Mar '18

14 Mar '18

Hi Boost Community, As per Submission template <https://svn.boost.org/trac10/wiki/SoCSubmissionTemplate> a candidate is required to show competency in C++ and must be "genuinely" interested in the project and also in open-source community. Judging of competency is straight forward, but how can interest be judged? Considering myself as example who had just got in serious open source projects(Sophomore Undergraduate). My coding ablilities <https://github.com/madhur4127/Programming-Competency-Test> are not at expert level but I am improving and learning myself while my university teaches knapsack greedy and automaton. Doesn't this gives an idea of interest in open source of a candidate or am I being a sophomore is a disadvantage with respect to other post graduate candidates? I know boost requires serious level work and it has world's most craftiest libraries but does Boost prefer experienced candidates or take chances with candidates genuinely interested in development and are moderately skilled? As per the division rules "A student must be able to write in C++". Regards, Madhur gsoc18 aspirant [Boost.Intrusive] -- Sent from: http://boost.2283326.n4.nabble.com/Boost-Dev-f2600599.html

1 0

Re: [boost] [interprocess] file_mutex class proposal
by mateusz janek 14 Mar '18

14 Mar '18

Hey, any thoughts on that? Thanks, Mateusz 2018-03-04 3:42 GMT-08:00 mateusz janek <stryku2393(a)gmail.com>: > Hello boost::interprocess community, > > During my pet projects development I found that a file access > synchronization is a common problem so, I wrote a class that wraps it and > thought that it can be useful for wider community. I would like to ask you > what do you think about such functionality in boost::interprocess? I'm > aware that class from the repo is not ready to release. Just wanted to show > about what functionality I'm talking about. > > Here you can find the repo: https://github.com/stryku/file_mutex > You can find there the proposed class and a simple usage example. > > If you will find it interesting I will prepare more formal merge proposal, > update docs, maybe more examples etc. > > Looking forward to hearing from you what do you think about it. > > Thank you, > Mateusz Janek > >

2 2

[release] Boost 1.67.0 Beta 1 Release Candidate 1
by Daniel James 14 Mar '18

14 Mar '18

The release candidates for the first 1.67.0 beta release are now available at: <https://dl.bintray.com/boostorg/beta/1.67.0.beta.1/source/> The release notes can be previewed at: <http://www.boost.org/users/history/in_progress.html> The documentation is available at: <http://www.boost.org/doc/libs/1_67_0_beta1/> The SHA256 checksums are as follows: 3d52af11ea6c45c73e18bf9b386056d31dab5092923cc9ed8efa29a083ffb9de boost_1_67_0_b1_rc1.7z 680336bd9a56dccda359061660348c5656cab71cb76713b157ce9a6f840659f0 boost_1_67_0_b1_rc1.tar.bz2 a4608b3ee0b4fadad7b2a2a9efa7c4ad8ce120ee94232e0ee86796f38cced319 boost_1_67_0_b1_rc1.tar.gz 3d1faa96ddda6f0a864f3292c014420457159f0960ff82efcca9feb898d21c1a boost_1_67_0_b1_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.

11 29

[gsoc18] Boost.Detour & Mentor Search
by Michael Kiros 14 Mar '18

14 Mar '18

Hello, I'm a C++ developer and have been developing in C++ for over 6 years now in my personal time. I wanted to accomplish two things with this post: 1. Propose the idea of boost::detour 2. Find a mentor in the process Boost.Detour is not something new that I'd like to implement but a concept in programming that I have been using for a very long time now and would love to have it easily accessible with the inclusion of a simple <boost/detour.hpp>. The idea is to have function hooking easily accessible to everyone using C++. Though it may seem like a niche feature, function hooking is more commonly used than most people think (e.g. modifying binaries after compilation for feature addition, reverse engineering proprietary software). It's a beautiful concept when you see it working. In the process I need a mentor to guide me through the process of putting down my ideas to paper and implementing them according to the standards that Boost holds. This includes replacing components from my library with Boost concepts (e.g. boost::process). I'm also a student at Texas Tech University studying Computer Science. Can't wait to hear from someone. Michael

2 1

[type_traits] is_list_constructible regression failures
by Lorenzo Caminiti 13 Mar '18

13 Mar '18

Hello all, I noticed the following failure in Boost.TypeTraits regression tests on GCC 4.6 C++11. Any idea why this is failing? http://www.boost.org/development/tests/master/developer/type_traits.html Test output: igaztanaga-master-gcc-4.6c++11 - type_traits - cxx14_aliases_test / gcc-4.6c+ Rev cb62bbf20f4a0000ee6f16835b0c2dc92edea8cd / Sun, 11 Mar 2018 03:16:04 +0000 Compile [2018-03-11 10:15:18 UTC]: fail "C:/Programs/mingw-builds/x32-4.6.4-posix-dwarf-rev0/mingw32/bin/gcc-4.6.bat" -pipe -fmax-errors=1 -std=c++0x -m32 -O0 -fno-inline -Wall -pedantic -Werror -march=i686 -Wextra -Wno-bool-operation -Wno-int-in-bool-context -Wno-uninitialized -DBOOST_ALL_NO_LIB=1 -I".." -I"..\libs\type_traits\test\libs\tt2\light\include" -c -o "c:\boost\master\results\boost\bin.v2\libs\type_traits\test\cxx14_aliases_test.test\gcc-4.6c+\dbg\dbg-symbl-off\cxx14_aliases_test.o" "..\libs\type_traits\test\cxx14_aliases_test.cpp" In file included from ../boost/type_traits.hpp:110:0, from ..\libs\type_traits\test\cxx14_aliases_test.cpp:10: ../boost/type_traits/is_list_constructible.hpp:36:61: error: expected class-name before 'decltype' compilation terminated due to -fmax-errors=1. I am asking because a couple of Boost.Contract tests that #include <boost/type_traits.hpp> fail with the same Boost.TypeTraits error on this compiler. Thanks. --Lorenzo

3 4

Re: [boost] [gsoc18]Boost.SafeFloat
by Rajat Miglani 13 Mar '18

13 Mar '18

Is there any specific template that I should follow for the proposal or I can make it my own way? Thanks, Rajat Miglani On Tue, Feb 27, 2018 at 12:43 AM, Damian Vicino <damian(a)vicino.com.ar> wrote: > Hi, > From the top of my head, the big missing pieces are the safefloat > literals, some pieves of unit testing (copile and runtime), documentation, > implementing some of the policies that are already defined. Maybe a better > way to specify policies could be implemented. > However, the complete list of things being done is what your proposal is > about, you need to define the milestones and goals for the project. > > 2018-02-25 18:57 GMT+00:00 Rajat Miglani <rajatmiglani26(a)gmail.com>: > >> I have read the paper "Goldberg, David. "What every computer scientist >> should know about floating-point arithmetic." ACM Computing Surveys (CSUR) >> 23.1 (1991): 5-48."and documentation and now having a little >> understanding of what this project is about.Presently going through the >> code and concepts, please guide me of what changes I have to do in the >> previous code to make it better. >> >> On Wed, Feb 21, 2018 at 11:52 PM, Damian Vicino <damian(a)vicino.com.ar> >> wrote: >> >>> Hi Rajat, >>> For the Boost.SafeFloat project, I suggest you take a look to the >>> following links: >>> - Repository: https://github.com/sdavtaker/safefloat >>> - Documentation: https://sdavtaker.github.io/safefloat/doc/htm >>> l/index.html >>> >>> Also, try to read this paper if you didn't before: Goldberg, David. >>> "What every computer scientist should know about floating-point >>> arithmetic." ACM Computing Surveys (CSUR) 23.1 (1991): 5-48. >>> From the C++ perspective, key concepts you need to know are: >>> - Templates (a lot of it) >>> - Custom Literals >>> >>> A good proposal would be to take a read to the documentation and code >>> base and describe what is missing to complete the project. >>> Best regards, >>> Damian Vicino >>> >>> >>> >>> >>> 2018-02-21 14:11 GMT-03:00 Rajat Miglani via Boost < >>> boost(a)lists.boost.org>: >>> >>>> Dear boost community, >>>> I am a GSOC aspirant and I'd like to contribute to your organization. >>>> I have read the project ideas and is interested in working on:- >>>> 1)Boost.SafeFloat or >>>> 2)Enhancing Boost.Intrusive Library >>>> Can I get some more info about how to work on these projects and the >>>> basic >>>> requirements so that I can learn them and be able to contribute to my >>>> fullest. >>>> >>>> Thank you, >>>> >>>> _______________________________________________ >>>> Unsubscribe & other changes: http://lists.boost.org/mailman >>>> /listinfo.cgi/boost >>>> >>> >>> >> >

2 1

[gsoc2018]Guidance for Google Summer of code on Project1
by sumit_kumar 12 Mar '18

12 Mar '18

I am a third year undergraduate student. I have a good implementation skills in C++ . I know machine learning algorithms & math required for it very well. So ,I would like to contribute to the Boost.uBLAS by doing project1. Could you please guide me. -- Sent from: http://boost.2283326.n4.nabble.com/Boost-Dev-f2600599.html

2 1

Re: [boost] [gsoc18] Mentor Request for uBLAS (prefer support for tensors)
by David Bellot 11 Mar '18

11 Mar '18

Hi Karl, you're exactly the kind of people I want to see in GSOC: student with passion for C++ and some already implemented library. Your competency test is good. Best now is to work on the proposal and send it to us directly (no need to go through the main mailing-list from now on). Cheers, David On Wed, Mar 7, 2018 at 9:27 PM, Karl Chen <karl.chen(a)mail.utoronto.ca> wrote: > Hi, > > > Thanks for replying! Here is a link to my competency test: > https://github.com/HiImKarl/GSOC18-uBLAS. > > The link in my first email was to a different library, more of a > basic proof of concept than anything. > > > Cheers! > > Karl > ------------------------------ > *From:* mohammad sharique <1sharique1(a)gmail.com> > *Sent:* Wednesday, March 7, 2018 12:06:05 PM > *To:* boost(a)lists.boost.org; Karl Chen > *Cc:* David Bellot > *Subject:* Re: [boost] [gsoc18] Mentor Request for uBLAS (prefer support > for tensors) > > Hi Karl, > David and I are mentoring this project. Thanks for sending in the source. > We'll have a look at it, and get back to you soon. > You may start writing proposal in the meanwhile. The proposal usually > involves details about what you want to achieve > with the project, the resource required, approach(s) for the same, time division, > class designs and interactions, implementation > details etc. > > Should there be any questions, please feel free to ask. > > Regards, > Sharique > > On Wed, Mar 7, 2018 at 2:36 PM, HiImKarl via Boost <boost(a)lists.boost.org> > wrote: > > Hi, > > I am Karl, a financial engineering student that is very passionate about > C++. I think my background in applied math and stats would make me a great > candidate for writing a tensor library. I would also like to point to this > header-only multi-dimensional array template library with compile time > tensor rank that I've written in the past: > https://github.com/HiImKarl/Tensors, which may be good groundwork. > > It is a little late into March, so I was wondering if there were any > mentors > still looking for students for this project. I have already completed the > competency test. > > > > -- > Sent from: http://boost.2283326.n4.nabble.com/Boost-Dev-f2600599.html > > _______________________________________________ > Unsubscribe & other changes: http://lists.boost.org/mailman > /listinfo.cgi/boost > > >

1 0

[gsoc18] uBLAS competency test
by Arun Ramachandran 11 Mar '18

11 Mar '18

Hello, I'm Arun, a final year computer science undergrad. I'm interested in working on project 1 of the uBLAS library (adding statistics and machine learning functions). I have experience with developing in C++ from working on Code Character (https://github.com/delta/codecharacter-simulator) an online AI programming challenge that some fellow students and I hosted. Since this is an application, I've taken the competency test for uBLAS and have implemented a small matrix library using expression templates along with some unit tests and benchmarks. The repo is currently private, so if a mentor shares their GitHub handle I can add them as a collaborator for reviewing it. Thank you, Arun Ramachandran

3 3

[gsoc18] Request for Guidance
by Mohd Faisal 11 Mar '18

11 Mar '18

Hello, my name is Mohd Faisal. I want to work on Boost.uBLAS: linear algebra and matrix computations. Is there a specific reason that only the listed algorithms have to be implemented. Because there are many good ML algorithms that can also be implemented like SVM.

3 2

[gsoc18] how to share a competency test
by vardhan gupta 11 Mar '18

11 Mar '18

Hi, My name is Vardhan Gupta. I am a 2nd year undergraduate student from IIT Kanpur. I am interested in working on project #3 of Boost.uBLAS on adding multicore and gpu computations to uBLAS. I have created a private repository of it's competency test on gitlab. Now, I am having trouble in sharing the repository with the mentors since I do not have their email address. how do I share it/find their e-mail address? Thank you, Yours sincerely; Vardhan Gupta

6 10

[gsoc2018]Mentor Required
by P.H S 11 Mar '18

11 Mar '18

Hello, my name is Zhixuan Xiao, a student from BUPT, BeiJing China. I am interested to Boost.uBLAS:project 3, Add Multicore and GPU computations to uBLAS and I want to connect with a mentor. Thanks, Zhixuan Xiao

2 1

Google Summer of Code: Potential Applicant
by Christos Maris 10 Mar '18

10 Mar '18

Hey there, My name is Christos (Chris for short) and I would love to work with you via the GSoC program this summer. I am sending this mail because I am in a need for some instructions on how to find a mentor and a project (at first). Can anyone help me with that? Also is there any potential mentor here? Any info helps. Thanks a lot in advance!

2 1

[gsoc18] Regarding Boost uBLAS Google Summer of Code 2018
by Varun Mehrishi 09 Mar '18

09 Mar '18

Hi, I am Varun Mehrishi, a third year engineering student from Manipal University Jaipur (MUJ), India. I am currently pursuing Bachelors of Technology in Computer Science and Engineering. I am most comfortable with C++(STL) and Python, and also follow the new and experimental features introduced in the new standards with additional help of cppcon and BoostCon. I also have interests in Data Science, Machine Learning. I wish to participate and contribute to Boost.uBLAS. I've read the project idea and description from the suggested GSoC project proposals. I am really interested in working on the project "Project 1 : Add statistics and machine learning functions" which is focused on extending Boost.uBLAS functionality towards statistics/ML. I have implemented a basic template version of the mentioned Programming Competency Test (basic-matrix-lib <https://github.com/varunmehrishi/basic-matrix-lib>) and used C++14 generic lambdas wherever necessary. Your feedback and suggestions will be extremely valuable as they will help me improve my implementation and add more functionality. Looking forward to your guidance -- With warm regards, Varun Mehrishi GSoC 2018 Aspirant

1 0

Re: [boost] How to set LDFLAGS in 1.66.0?
by Nana Sakisaka 09 Mar '18

09 Mar '18

> I'm not looking to find an external library, I'm trying to set the RUNPATH on the boost shared libraries There's no need to use an external library. You just pass options to b2. Are you sure that you've tried my suggestion on previous reply? > Ordinarilly, one just adds LDFLAGS to the configure script with the -Wl,rpath ... Using boost libraries does not prevent you to do so. One could either specify RPATH for your boost library files, application executable, or both. BTW, looking at your pasted output of ldd indicates that you've set your RPATH for wrong value, but that should not be boost specific; try googling without 'boost' keyword? 2018-03-09 9:59 GMT+09:00 Dean Anderson <dean(a)av8.com>: > Thanks for the reply. > > I'm not looking to find an external library, I'm trying to set the RUNPATH > on the boost shared libraries. For example: > > The path on libstdc++ is set by the ld, so it finds the right compiler > runtime... > > libboost_wave.so needs a RUNPATH to where its going to be installed. > > Ordinarilly, one just adds LDFLAGS to the configure script with the > -Wl,rpath ... > > --Dean > > ldd libboost_wave.so.1.66.0 > linux-vdso.so.1 => (0x00007ffebf1b6000) > libboost_filesystem.so.1.66.0 => not found > libboost_thread.so.1.66.0 => not found > libboost_date_time.so.1.66.0 => not found > libboost_chrono.so.1.66.0 => not found > libboost_system.so.1.66.0 => not found > librt.so.1 => /lib64/librt.so.1 (0x00007f5082f0a000) > libstdc++.so.6 => /efs/dist/gnu/gcclib/4.9.4/.ex > ec/x86-64.rhel.7/lib/libstdc++.so.6 (0x00007f5082c00000) > libm.so.6 => /lib64/libm.so.6 (0x00007f50828fd000) > libgcc_s.so.1 => /efs/dist/gnu/gcclib/4.9.4/.ex > ec/x86-64.rhel.7/lib/libgcc_s.so.1 (0x00007f50826e6000) > libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f50824ca000) > libc.so.6 => /lib64/libc.so.6 (0x00007f5082108000) > /lib64/ld-linux-x86-64.so.2 (0x00007f508343e000) > > > > On Fri, 9 Mar 2018, Nana Sakisaka via Boost wrote: > > You could try passing this option to b2: >> >> dll-path="'$ORIGIN/../lib'" >> >> Make sure to escape $ and " appropriately for your CI scripts. >> Note that there are actually two types of flags, i.e. >> (1) the flag for your application executable (the RPATH) >> and >> (2) a flag for your build system's sanity check (e.g. the "checking if >> *whatever* works..." internal binary flag for ./configure) >> >> p.s. Invoke command below to check whether the flags are set: >> objdump -p ./a.out|grep RPATH >> >> >> >> 2018-03-09 8:33 GMT+09:00 Dean Anderson via Boost <boost(a)lists.boost.org >> >: >> >> I need to set an rpath on the shared libraries. Any ideas how to do that? >>> >>> Alternatively, is there a fork of boost that use the gnu build system? >>> >>> Thanks! >>> >>> --Dean >>> >>> Av8 Internet Prepared to pay a premium for better service? >>> www.av8.net faster, more reliable, better service >>> 617 256 5494 >>> >>> >>> _______________________________________________ >>> Unsubscribe & other changes: http://lists.boost.org/mailman >>> /listinfo.cgi/boost >>> >>> >> _______________________________________________ >> Unsubscribe & other changes: http://lists.boost.org/mailman >> /listinfo.cgi/boost >> >>

1 0

How to set LDFLAGS in 1.66.0?
by Dean Anderson 09 Mar '18

09 Mar '18

I need to set an rpath on the shared libraries. Any ideas how to do that? Alternatively, is there a fork of boost that use the gnu build system? Thanks! --Dean Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 256 5494

2 1

[foreach][polygon][xpressive][bimap][ptr_container][gil][assign][typeof][msm] PRs for removing executable attribute for files
by Edward Diener 08 Mar '18

08 Mar '18

The following libraries still have PRs, which I have previously submitted, for removing the executable attribute for one or more files: foreach polygon xpressive bimap ptr_container gil assign typeof msm None of these PRs affect anything other than the file attribute, so no testing is needed AFAICS since no code changes. If the maintainers of the above libraries, or someone else with write access to these libraries, can merge the appropriate PR to 'develop', and then merge 'develop' to 'master', we can get rid of having any files with their executable attribute set in the next release.

5 13

[gsoc18] Boost.Intrusive mentor request
by BogdanCodreanu 08 Mar '18

08 Mar '18

Hello, I've read about the Boost.Intrusive library and it matches my desires of programming. Is there a mentor available for this project? How should I prove myself worthy of this project? -- Sent from: http://boost.2283326.n4.nabble.com/Boost-Dev-f2600599.html

2 1

Re: [boost] [system] [teeks99] Mass test failures on MSVC-14.0
by Andrey Semashev 08 Mar '18

08 Mar '18

On 02/26/18 17:20, Tom Kent wrote: > On Mon, Feb 26, 2018 at 6:56 AM, Andrey Semashev via Boost > <boost(a)lists.boost.org <mailto:boost@lists.boost.org>> wrote: > > On 02/26/18 15:43, Tom Kent via Boost wrote: > > On Sat, Feb 24, 2018 at 3:45 PM, Andrey Semashev via Boost < > boost(a)lists.boost.org <mailto:boost@lists.boost.org>> wrote: > > Hi, > > Most of Boost.System tests are failing on the > teeks99-09-f-win2016-64on64 > tester, MSVC-14.0[1]. The test logs don't show any errors > and I can't > reproduce it locally. I'm seeing similar test failures in > other libraries, > like Boost.Atomic for example, and the links point to > Boost.System. > > Is it possible to get the error log from the tester? > > >> > > Here's all 82MB of it: > > http://boost.teeks99.com/temp/teeks99-09-f-results-bjam-2018-02-26.log > <http://boost.teeks99.com/temp/teeks99-09-f-results-bjam-2018-02-26.log> > > > > But be warned, I just moved the -09 runner onto a new (Win 2016) VM about a > > week ago, and there have been some teething issues. If all goes well, the > > -f run should hit again in the next 24-48hrs. > > The link returns 403: Forbidden. > > Try again now. Sorry about that. I got the log now, thanks. The relevant part seems to be this: msvc.link.dll D:\teeks99-09\run\results\boost\bin.v2\libs\system\build\msvc-14.0\dbg\adrs-mdl-64\thrd-mlt\boost_system-vc140-mt-gd-x64-1_67.dll call "D:\teeks99-09\run\results\boost\bin.v2\standalone\msvc\msvc-14.0\adrs-mdl-64\archt-x86\msvc-setup.bat" amd64 >nul link /NOLOGO /INCREMENTAL:NO /DLL /DEBUG /MACHINE:X64 /MANIFEST /subsystem:console /out:"D:\teeks99-09\run\results\boost\bin.v2\libs\system\build\msvc-14.0\dbg\adrs-mdl-64\thrd-mlt\boost_system-vc140-mt-gd-x64-1_67.dll" /IMPLIB:"D:\teeks99-09\run\results\boost\bin.v2\libs\system\build\msvc-14.0\dbg\adrs-mdl-64\thrd-mlt\boost_system-vc140-mt-gd-x64-1_67.lib" @"D:\teeks99-09\run\results\boost\bin.v2\libs\system\build\msvc-14.0\dbg\adrs-mdl-64\thrd-mlt\boost_system-vc140-mt-gd-x64-1_67.dll.rsp" if %ERRORLEVEL% NEQ 0 EXIT %ERRORLEVEL% Creating library D:\teeks99-09\run\results\boost\bin.v2\libs\system\build\msvc-14.0\dbg\adrs-mdl-64\thrd-mlt\boost_system-vc140-mt-gd-x64-1_67.lib and object D:\teeks99-09\run\results\boost\bin.v2\libs\system\build\msvc-14.0\dbg\adrs-mdl-64\thrd-mlt\boost_system-vc140-mt-gd-x64-1_67.exp msvc.manifest.dll D:\teeks99-09\run\results\boost\bin.v2\libs\system\build\msvc-14.0\dbg\adrs-mdl-64\thrd-mlt\boost_system-vc140-mt-gd-x64-1_67.dll if exist "D:\teeks99-09\run\results\boost\bin.v2\libs\system\build\msvc-14.0\dbg\adrs-mdl-64\thrd-mlt\boost_system-vc140-mt-gd-x64-1_67.dll.manifest" ( call "D:\teeks99-09\run\results\boost\bin.v2\standalone\msvc\msvc-14.0\adrs-mdl-64\archt-x86\msvc-setup.bat" amd64 >nul mt -nologo -manifest "D:\teeks99-09\run\results\boost\bin.v2\libs\system\build\msvc-14.0\dbg\adrs-mdl-64\thrd-mlt\boost_system-vc140-mt-gd-x64-1_67.dll.manifest" "-outputresource:D:\teeks99-09\run\results\boost\bin.v2\libs\system\build\msvc-14.0\dbg\adrs-mdl-64\thrd-mlt\boost_system-vc140-mt-gd-x64-1_67.dll;2" ) 'mt' is not recognized as an internal or external command, operable program or batch file. ...failed msvc.manifest.dll D:\teeks99-09\run\results\boost\bin.v2\libs\system\build\msvc-14.0\dbg\adrs-mdl-64\thrd-mlt\boost_system-vc140-mt-gd-x64-1_67.dll D:\teeks99-09\run\results\boost\bin.v2\libs\system\build\msvc-14.0\dbg\adrs-mdl-64\thrd-mlt\boost_system-vc140-mt-gd-x64-1_67.lib D:\teeks99-09\run\results\boost\bin.v2\libs\system\build\msvc-14.0\dbg\adrs-mdl-64\thrd-mlt\boost_system-vc140-mt-gd-x64-1_67.pdb D:\teeks99-09\run\results\boost\bin.v2\libs\system\build\msvc-14.0\dbg\adrs-mdl-64\thrd-mlt\boost_system-vc140-mt-gd-x64-1_67.pdb D:\teeks99-09\run\results\boost\bin.v2\libs\system\build\msvc-14.0\dbg\adrs-mdl-64\thrd-mlt\boost_system-vc140-mt-gd-x64-1_67.pdb D:\teeks99-09\run\results\boost\bin.v2\libs\system\build\msvc-14.0\dbg\adrs-mdl-64\thrd-mlt\boost_system-vc140-mt-gd-x64-1_67.pdb D:\teeks99-09\run\results\boost\bin.v2\libs\system\build\msvc-14.0\dbg\adrs-mdl-64\thrd-mlt\boost_system-vc140-mt-gd-x64-1_67.pdb... ...removing D:\teeks99-09\run\results\boost\bin.v2\libs\system\build\msvc-14.0\dbg\adrs-mdl-64\thrd-mlt\boost_system-vc140-mt-gd-x64-1_67.dll ...removing D:\teeks99-09\run\results\boost\bin.v2\libs\system\build\msvc-14.0\dbg\adrs-mdl-64\thrd-mlt\boost_system-vc140-mt-gd-x64-1_67.lib ...removing D:\teeks99-09\run\results\boost\bin.v2\libs\system\build\msvc-14.0\dbg\adrs-mdl-64\thrd-mlt\boost_system-vc140-mt-gd-x64-1_67.pdb I think, this problem has been discussed on the list not long ago - `mt` being not found on the system after some MSVC update: http://boost.2283326.n4.nabble.com/build-msvc-14-linker-step-failing-tc4701… Looks like MSVC needs to be reinstalled or installed on a separate machine. Will you be able to fix this?

3 7

[release] 1.67.0 closed for Beta
by Daniel James 07 Mar '18

07 Mar '18

The master branch is now closed for all changes except by permission for the Beta release. Also, remember to add your libraries' changes to the release notes at: <https://github.com/boostorg/website/blob/master/feed/history/boost_1_67_0.q…> You can preview the release notes at: <http://www.boost.org/users/history/in_progress.html> Thanks, -- The Boost Release Team

1 0

About authorizing CircleCI
by Vicente J. Botet Escriba 07 Mar '18

07 Mar '18

Hi, recently I heard of CircleCI (https://circleci.com/) and it seems much faster than Travis. Is someone using it? What is your feedback? If the feedback is positive, could someone authorize CircleCI to access boostorg? Best, Vicente

6 11

[gsoc18] Mentor Request for uBLAS (prefer support for tensors)
by HiImKarl 07 Mar '18

07 Mar '18

Hi, I am Karl, a financial engineering student that is very passionate about C++. I think my background in applied math and stats would make me a great candidate for writing a tensor library. I would also like to point to this header-only multi-dimensional array template library with compile time tensor rank that I've written in the past: https://github.com/HiImKarl/Tensors, which may be good groundwork. It is a little late into March, so I was wondering if there were any mentors still looking for students for this project. I have already completed the competency test. -- Sent from: http://boost.2283326.n4.nabble.com/Boost-Dev-f2600599.html

2 1

[gsoc2018] Project 1.1: Add statistics and machine learning functions
by Dattatreya Mohapatra 07 Mar '18

07 Mar '18

Hi, My name is Dattatreya Mohapatra. I am an undergrad at IIIT Delhi, majoring in CS. I am interested in working on extending the Boost.uBLAS library as a project. I have taken courses on Linear Algebra and Machine Learning in the past, so I have a decent basic understanding of the subject. I have used C++11 in several of my course projects, so I have some familiarity with advanced features like lambdas and template programming. I have gone through the earlier threads on the same, and have started working on the core-competency test (CCT). Can the mentors of this project please guide me as to how should I get the CCT reviewed when its ready? Also, is there anything else I should look at apart from the documentation which would be helpful? Thanks and regards, Dattatreya Mohapatra

2 2

VS 2017 15.6 released, _MSC_VER=1913...
by Peter Dimov 07 Mar '18

07 Mar '18

... and Boost.Config once again warns: 1>c:\boost-git\develop\boost\config\compiler\visualc.hpp(349): note: Info: Boost.Config is older than your compiler version - probably nothing bad will happen - but you may wish to look for an updated Boost version. Define BOOST_CONFIG_SUPPRESS_OUTDATED_MESSAGE to suppress this message. Maybe we should display this only on 1920 and above, as I suggested last time? :-)

5 5

[gsoc18] [Boost.Intrusive] Mini version of project
by Rishija Mangla 07 Mar '18

07 Mar '18

Hello, My name is Rishija Mangla. I’m a mathematics graduate and pursuing my MCA (2nd year) from University of Delhi, India. I want to contribute in enhancing Boost.Intrusive library and have implemented a mini library for the same ( as asked for competency test ). Library includes: - Generic segment tree ( support range queries where operation is given by the user over any general class ) - Expression templates for lazy evaluation - Written test programs to check the accuracy ( using Boost.test unit test framework ) - Test cases are generated randomly Link to library implemented https://github.com/Rishija/boost_competency_test <https://github.com/Rishija/boost_competency_test> I plan to implement more complex data structures that have been mentioned in the list. I have already implemented prefix tree, both dynamic and via filesystem ( will provide link to the project in case you want to have a look ). So I’ll be pretty comfortable in developing other similar data structures and algorithms for them. Thanks

1 0

[Boost.Yap] Review results
by Louis Dionne 06 Mar '18

06 Mar '18

Dear Boost, I am pleased to announce that the Yap library is CONDITIONALLY ACCEPTED into Boost. I counted the following formal reviews: - Alex Hagen-Zanker: REJECT / CONDITIONAL ACCEPT - Barrett Adair: ACCEPT - Brook Milligan: CONDITIONAL ACCEPT - John Fletcher: ACCEPT - Paul Fultz II: ACCEPT - Steven Watanabe: ACCEPT I'd like to thank everyone who participated to the review for their feedback, and also Zach Laine for his submission. The following is a summary of the main issues that were raised during the review: - Contextual evaluation of terminals The concern was that there was no way of evaluating an expression tree with a custom context other than to first transform it with a custom transform, and then evaluate it. This, however, requires encoding the recursion into the transform even when we only want to modify terminals. After a lot of discussion, everybody seemed to agree that the following would be desirable (paraphrasing Steven): `transform_evaluate` would behave exactly like `transform`, except that the default behavior for nodes that are not handled by the context is to evaluate the operators instead of building a new expression. Zach fixed that in https://github.com/tzlaine/yap/issues/63 by introducing a new transform called `evaluation()` which evaluates terminals, and the ability to pass multiple transforms `t1`, ..., `tN` to `transform`. The first matching transform is executed, and `transform` will copy-and-recurse if no transforms match. `transform_evaluate(expr, tform)` can then be implemented as `yap::transform(expr, tform, yap::evaluation())`. - Auto-unwrapping of terminals in transform and automatic application of terminal transforms before unwrapping There was a concern that automatically unwrapping terminals in transforms and applying terminal transforms before unwrapping would result in counter intuitive behavior. After some discussion, it was determined that automatic application of transforms before unwrapping could indeed lead to surprising results and was removed. However, unwrapping of terminals is necessary to keep the matching of terminals reasonable, so it was kept. I am comfortable with that decision, as the unwrapping of terminals, which leads to a very intuitive way of matching terminals, was one of the features that sprung to me as being a great usability boost when I first looked at the library. - Positional placeholders should stay or go? Some of the reviewers felt like it was not desirable to provide positional placeholders as part of Yap, because those aren't the primary purpose of the library and C++14 obsoletes them with lambdas. Other reviewers felt like they were in fact very useful and shouldn't be removed. Since no clear consensus could be reached, no acceptance condition is attached to this issue. However, I personally favor the removal of placeholders from the core API on the basis of minimality. I would like to encourage Zach to check whether their removal would result in API simplifications; if so, I would encourage (but not require) their removal, at Zach's discretion. - Documentation The documentation is not sufficiently extensive, and takes too much for granted from the reader. This was raised by a couple of reviewers and it has been my largest problem with the library so far. More on this below. - The eval_xxx customization points. Nobody liked them, and they are already gone. - BOOST_YAP_CONVERSION_OPERATOR_TEMPLATE Nobody liked it, and it is already gone. - Short-circuiting of && and || in evaluate Steven brought up the fact that `yap::evaluate` would not short-circuit the evaluation of && and ||. This issue was mooted when customization points were removed. Also, the new `evaluation()` transform, which could suffer from the same short-circuiting problems, doesn't because it was implemented properly. - Support for Boost.Build is missing. - Hana vs not Hana Full disclosure: I am the author of Boost.Hana. A couple of reviewers raised concerns with Hana being part of the public interface. The main concern seemed to be about MSVC not being able to compile Hana, and hence Yap being unusable on MSVC. While I agree that MSVC is a big player, I believe that should not dictate what all Boost libraries do. Some libraries are meant to bridge gaps with older compilers, some libraries are cutting edge. Yap is the latter, and that's fine. The MSVC folks are working hard on their C++ conformance, and they will eventually get there. Also, it is likely that Hana wouldn't be the barrier anyway: Yap relies a lot on SFINAE and MSVC is known to be poor at it. Many of the features that one would likely want to use when using Yap are also not too well supported by MSVC, so users would probably hit limitations there anyway. Plus, as soon as MSVC is close enough, I'll start working on Hana's side to support it. Taking my review manager hat off for a second, I'd also like to point out that Yap is exactly the kind of use case that Hana was built for. Just like MPL was (and is) used in many libraries' implementation and APIs, I don't see a problem with using Hana in Yap's API, since that is the right tool for the job. That being said, if Zach wishes to explore using Hana's concepts (like hana::Sequence) to conceptify his API, I encourage him to do so. This may make it possible to use any tuple-like sequence for the children of an expression, thereby reducing the coupling between the two libraries. If Zach wants to explore using Fusion instead of Hana, that is also an option that would make MSVC support achievable. - A single macro for symmetric binary operators It was brought up that there's no macro to define both `arg <op> expr` and `expr <op> arg` at once. I believe this was initially done to avoid potential conflicts with the member variants, which already provide `expr <op> arg`. I believe it should still be possible to do it, since, as Steven said, most of the time a user will need symmetric behavior anyway. - External dependencies checked-into the repository The library includes internal copies of some of its dependencies, which is unusual for a Boost library. Zach said it wasn't his intent to put the library into Boost that way if it were accepted. To see all the issues that were raised during the review, you can search for tickets labeled with `Boost Review` on GitHub: https://github.com/tzlaine/yap/issues?q=label%3A%22Boost+Review%22 Based on the concerns above, the following lists the conditions for acceptance: - Documentation In my opinion, this was the biggest concern to be addressed. A lot of progress was made during and after the review, but I still think the documentation can be improved and made more complete. I especially believe that integrating more examples inside the "tutorial" (not just at the end) and introducing new concepts more gradually would help readers that are not already expression template gurus. It is very difficult to set a clear action item for "improving the documentation". For this reason, Brook Milligan and I will work with Zach to define what it means for the documentation to meet this acceptance condition. Brook was kind enough to agree to this when I asked him in a private communication. - A single macro for symmetric binary operators The library must provide a way to define symmetric binary operators in one go. Exactly how this can be achieved and whether we should be able to SFINAE-constrain the arguments is left to Zach's discretion. - External dependencies The external dependencies must not be packaged with the library itself. Another mechanism should be used; I leave that mechanism unspecified, but it should be possible to test the library using the usual Boost.Build workflow (e.g. an ExternalPackage download that would only work in CMake is not acceptable). - Boost.Build Yap needs to support Boost.Build like all the other Boost libraries. I will post an update to this list when the conditions of the review are met. If they wish to do so, reviewers can then verify that the conditions are met in a satisfactory fashion and the library will automatically be accepted unless someone objects. I would like to thank everyone who participated in the review, and congratulations to Zach for his library. Regards, Louis Dionne

5 7

[graph] r_c_shortest_paths writes/reads outside allocated memory
by Mateusz Polnik 06 Mar '18

06 Mar '18

Dear Colleagues, The algorithm for computing resource constrained shortest path writes/reads outside allocated memory which may result in segmentation faults. The finding is confirmed using Valgrind. I fixed the bug and opened a pull request. Could you review the pull request and give feedback if there is something more that should be done to meet quality requirements for the merge? The pull request https://github.com/boostorg/graph/pull/93 explains the issue, fixes it and contains a test for preventing regressions. Thank you in advance for your help. Regards, Mateusz Polnik

1 0

GSoc - Request for guidance
by Fady Saeed 06 Mar '18

06 Mar '18

Hello, I’m Fady Saeed. I’m Studying Computer & System Engineering at Faculty of Engineering (3rd year) at Ain Shams University in Egypt I read GSoc projects idea list and it was really interesting and I want to contribute I’m interested in contributing to Boost Geometry, Boost SafeFloat Project 1 So If it’s possible I’d like to connect to a mentor and know what should I do next and If there’s anything I need to read about so I can contribute Thanks in advance

3 2

[filesystem] Boost 1.66 fails to compile under Android NDK r16b
by Robert Dailey 06 Mar '18

06 Mar '18

I'm following a bug reported against boost filesystem here on github: https://github.com/boostorg/filesystem/issues/65 This issue has gone dead. Early on they asserted it was an NDK issue. However, the NDK developers say it's a filesystem issue. I'm not able to build Boost 1.66 with the following configuration: Android NDK Version: r16b Architecture: armeabi-v7a API: 15 Toolchain: Clang STL: libc++ (LLVM) This is blocking my migration away from GNUSTL. Can anyone confirm that this issue is being looked at? Either I'm the only one seeing this, or my toolchain combination exposes the bug but not many people build boost this way.

3 4

Proposed SG14 <system_error2> ready for feedback
by Niall Douglas 05 Mar '18

05 Mar '18

Back after the Outcome discussion died down, I started a thread discussing making breaking changes to Boost.System to test the feasibility of fixing some of the unfortunate design choices now apparent through hindsight in `<system_error>`. I won one argument - constexprification - the others I lost. I said at the time that I'd go off and make a better mousetrap i.e. a proposed `<system_error2>`. That proposed `<system_error2>` is now ready for feedback: Single file include: https://github.com/ned14/status-code/raw/develop/single-header/system_error… Github: https://github.com/ned14/status-code Docs: https://ned14.github.io/status-code/ Lots of detail about the differences between proposed `<system_error2>` and `<system_error>` is in the front page of the docs and pasted after this email, but essentially it fixes all the problems listed in https://wg21.link/P0824, and a few other problems I considered important as well. It works well in C++ 11, is believed to be freestanding C++ (https://wg21.link/P0829) friendly, and generates really lovely and tight codegen. If SG14 smile upon it in the April meeting, it'll be heading to Rapperswil for standardisation. Boost members should be aware that there will be shortly a push by the WG21 leadership to improve the current state of exception and error handling in the C++ standard as it is becoming increasingly obvious that the current design is no longer sufficient. You may see a paper on that from the leadership at Jacksonville, if not then fairly definitely you will at Rapperswil. This proposed `<system_error2>` *may* have a part to play in the reform proposals, if it is felt that this approach is a wise one by SG14, you guys here, and then WG21. So, as a quick introduction given that there is no documentation, instead of `error_code` we have a `status_code<D>` where `D` is the type of the code's *domain*. The domain provides all of the heavy lifting so status code itself can be trivial. Status codes can be type erased of their domain, you can always erase to `status_code<void>` but at the cost that it cannot be copied, moved nor deleted. If your domain's value type is trivially copyable, it can also be type erased into any `status_code<erased<U>>` where `U` is an integer type, and the size of the erased status code is bigger or equal to its unerased form. There is a special status_code called `generic_code`, which is a typedef for `status_code<_generic_code_domain_impl>`. Its value type is `errc`, which is a slight superset of `std::errc`. The reason it is special is because it is the baseline error code, all other codes must be semantically comparable to it, if that is possible. In current STL speak, `generic_code` is what `std::error_condition` with a `std::generic_category` is. On all POSIX platforms, we provide a `posix_code`. Its value type is `int`, as from `errno`. This maps the local POSIX implementation's error coding. It is *not* necessarily equal to `generic_code`, but usually is a superset, so all codes in `generic_code` can exist in `posix_code`, but not the other way round. On Windows, we have three main system error coding systems, so we have `win32_code`, `nt_code` and `com_code`. Their value types are `DWORD` from GetLastError(), `LONG` from `NTSTATUS`, and `HRESULT` from Microsoft COM. On all systems, there is a typedef `system_code` which is to the erased status code sufficiently large that you are guaranteed that all possible system error coding schemes can be safely erased into it. For POSIX, this is `status_code<erased<int>>`, as `int` can hold all possible error codings. For Windows, this is `status_code<erased<intptr_t>>`, as `intptr_t` can hold any of a `DWORD`, a `LONG` and a `HRESULT`. All comparisons between status codes are *semantic*. As in, `operator==()` returns true if the two types are semantically equal e.g. `win32_code(ERROR_SUCCESS) == generic_code(errc::success) == com_code(S_OK)`. Semantic comparison is the only form of comparison, if you want literal comparison, it can be done by hand by comparing value and domain by hand. There is no boolean testing at all, as it is ambiguous as we learned with `std::error_code`. One always writes: `if(sc.failure()) ...` etc. `status_code` can represent success codes, failure codes, and empty. Empty is there to say "no code was set". Empty is neither a success, nor a failure. It is there for code where a virtual function call to determine success/failure is too expensive and where the domain is known for a fact to only ever represent failure. You should only ever use empty as a local optimisation, and never ever expose empty status codes to code that you don't 100% control. And that's basically it. Idiomatic usage is for extern functions to return type erased status codes or to take one by lvalue reference. Code local to the translation unit uses typed status codes, and lets any implicit conversion into the erased form occur as needed. I've copy and pasted relevant excerpts from the Readme.txt below for those not willing to click on a link. If you have any questions, please do shout. My next step is to start work on preparing Outcome for entry into Boost now a month of settling time has passed since the review. Once the Jacksonville meeting has finished and I've done any post-meeting correspondence, I'll be starting on my (currently five!) papers for Rapperswil where I'll hopefully be attending my very first WG21 meeting! Niall --- Readme.md (excerpt) -- Solves the problems for low latency/large code base users with `<system_error>` as listed by [WG21 P0824](https://wg21.link/P0824). This proposed `<system_error2>` library is EXPERIMENTAL and is subject to change as the committee evolves the design. To fetch a drop-in standalone single file implementation: ``` wget https://github.com/ned14/status-code/raw/develop/single-header/system_error… ``` ## Features: - Portable to any C++ 11 compiler. These are known to work: - >= GCC 5 (due to requiring libstdc++ 5 for sufficient C++ 11 type traits) - >= clang 3.3 with a new enough libstdc++ (previous clangs don't implement inheriting constructors) - >= Visual Studio 2015 (previous MSVC's don't implement inheriting constructors) - Aims to cause zero code generated by the compiler most of the time. - Never calls `malloc()`. - Header-only library friendly. - Type safe yet with type erasure in public interfaces so it can scale across huge codebases. - Minimum compile time load, making it suitable for use in the global headers of multi-million line codebases. ## Problems with `<system_error>` solved: 1. Does not cause `#include <string>`, and thus including the entire STL allocator and algorithm machinery, thus preventing use in freestanding C++ as well as substantially impacting compile times which can be a showstopper for very large C++ projects. Only includes the following headers: - `<atomic>` to reference count localised strings retrieved from the OS. - `<cassert>` to trap when misuse occurs. - `<cerrno>` for the generic POSIX error codes (`errno`) which is required to define `errc`. - `<cstddef>` for the definition of `size_t` and other types. - `<cstring>` for the system call to fetch a localised string and C string functions. - `<exception>` for the basic `std::exception` type so we can optionally throw STL exceptions. - `<initializer_list>` so we can permit in-place construction. - `<new>` so we can perform placement new. - `<type_traits>` as we need to do some very limited metaprogramming. - `<utility>` if on C++ 17 or later for `std::in_place`. These may look like a lot, but in fact just including `<atomic>` on libstdc++ actually brings in most of the others in any case, and a total of 200Kb (8,000 lines) of text is including by `system_error2.hpp` on libstdc++ 7. Compiling a file including `status_code.hpp` takes less than 150 ms with clang 3.3 as according to the `-ftime-report` diagnostic (a completely empty file takes 5 ms). 2. Unlike `std::error_code` which was designed before `constexpr`, this proposed implementation has all-`constexpr` construction and destruction with as many operations as possible being trivial or literal, with only those exact minimum operations which require runtime code generation being non-trivial (note: requires C++ 14 for a complete implementation of this). 3. This in turn means that we solve a long standing problem with `std::error_category` in that it is not possible to define a safe custom C++ 11 error category in a header only library where semantic comparisons would randomly break depending on the direction of wind blowing when the linker ran. This proposed design is 100% safe to use in header only libraries. 4. `std::error_code`'s boolean conversion operator i.e. `if(ec) ...` has become unfortunately ambiguous in real world C++ out there. Its correct meaning is "if `ec` has a non-zero value". Unfortunately, much code out in the wild uses it as if "if `ec` is errored". This is incorrect, though safe most of the time where `ec`'s category is well known i.e. non-zero values are always an error. For unknown categories supplied by third party code however, it is dangerous and leads to unpleasant, hard-to-debug, surprise. The `status_code` proposed here suffers from no such ambiguity. It can be one of exactly three meanings: (i) success (ii) failure (iii) empty (uninitialised). There is no boolean conversion operator, so users must write out exactly what they mean e.g. `if(sc.success()) ...`, `if(sc.failure()) ...`, `if(sc.empty()) ...`. 5. Relatedly, `status_code` can now represent successful (informational) codes as well as failure codes. Unlike `std::error_code` where zero is given special meaning, we impose no requirements at all on the choice of coding. This permits safe usage of more complex C status coding such as the NT kernel's `NTSTATUS`, which is a `LONG` whereby bits 31 and 30 determine which of four categories the status is (success, informational, warning, error), or the very commone case where negative numbers mean failure and positive numbers mean success-with-information. 6. The relationship between `std::error_code` and `std::error_condition` is confusing to many users reading code based on `<system_error>`, specifically when is a comparison between codes *semantic* or *literal*? `status_code` makes all comparisons *semantic*, **always**. If you want a literal comparison, you can do one by hand by comparing domains and values directly. 7. `std::error_code` enforced its value to always be an `int`. This is problematic for coding systems which might use a `long` and implement coding namespaces within the extended number of bits, or for end users wishing to combine a code with a `void *` in order to transmit payload or additional context. As a result, `status_code` is templated to its domain, and the domain sets its type. A type erased edition of `status_code<D>` is available as `status_code<void>`, this is for obvious reasons non-copyable, non-movable and non-destructible. A more useful type erased edition is `status_code<erased<T>>` which is available if `D::value_type` is trivially copyable, `T` is an integral type, and `sizeof(T) >= sizeof(D::value_type)`. This lets you use `status_code<erased<T>>` in all your public interfaces without restrictions. As a pointer to the original category is retained, and trivially copyable types may be legally copied by `memcpy()`, type erased status codes work exactly as normal, except that publicly it does not advertise its type. 8. `std::system_category` assumes that there is only one "system" error coding, something mostly true on POSIX, but not elsewhere. This library defines `system_code` to a type erased status code sufficiently large enough to carry any of the system error codings on the current platform. This allows code to construct the precise error code for the system failure in question, and return it type erased from the function. Depending on the system call which failed, a function may therefore return any one of many system code domains. 9. Too much `<system_error>` code written for POSIX uses `std::generic_category` when they really meant `std::system_category` because the two are interchangeable on POSIX. Further confusion stems from `std::error_condition` also sharing the same coding and type. This causes portability problems. This library's `generic_code` has a value type of `errc` which is a strong enum. This prevents implicit confusion with `posix_code`, whose value type is an `int` same as `errno` returns. There is no distinction between codes and conditions in this library, rather we treat `generic_code` as something special, because it represents `errc`. The cleanup of these ambiguities in `<system_error>` should result in users writing clearer code with fewer unintended portability problems. -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

5 13

Trouble getting feedback on a program_option feature PR
by Eyal Rozenberg 05 Mar '18

05 Mar '18

Hello Boosters, Following a (much) earlier suggestion on this list, I've implemented one of the features I'd like to see in program_option, and created Pull Request for initial review/feedback on GitHub: https://github.com/boostorg/program_options/pull/40 I've noticed, however, that there are 4 other unattended PRs, the earliest being from 2016. Some of them have comments such as "Can you please merge or decline?" urging a response. Also, there have been no commits for the past 4 months. I've also emailed Vladimir (Prus) last month - a short message, merely to ensure he's noticed my PR, not to demand anything; but I've gotten no reply. Now, I don't want to sound accusatory - I'm sure there are perfectly good reasons for the lack of responsiveness, and I'm very appreciate of the work of writing the library and maintaining it over the years. Still, given the situation I thought I'd bring this up here on the list. What would you suggest I do? Eyal

1 0

Gsoc2018/mentor required
by nivyatheresa 05 Mar '18

05 Mar '18

Hello, I am Nivya and I am a btech student from IIT Roorkee. I would like to contribute to the Boost.Real project. I need a mentor to help me to proceed further. Thanks in advance, Sincerely, Nivya. -- Sent from: http://boost.2283326.n4.nabble.com/Boost-Dev-f2600599.html

2 1

[serialization] RTTI issue with non-polymorphic types
by Jorge Lodos 05 Mar '18

05 Mar '18

Hi I am trying to use the serialization library for non-polymorphic types without RTTI. In release mode everything works fine, but in debug mode there are problems because dynamic_cast is used for debugging purposes. The code is in smart_cast.hpp, starting in line 87: #if ! defined(NDEBUG) \ || defined(__MWERKS__) // do a checked dynamic cast return cross::cast(u); #else I believe the first line could be replaced with: #if (! defined(NDEBUG) && ! defined(BOOST_NO_RTTI) ) \ Is this something you are willing to consider? I decided to ask before creating any ticket or pull request because there is a number of previous attempts to make serialization work without RTTI for the general case. But this is specific for non-polymorphic types. Thanks. Jorge

3 3

Re: [boost] Proposed SG14 <system_error2> ready for feedback
by Bjorn Reese 04 Mar '18

04 Mar '18

On 02/28/18 23:10, Niall Douglas via Boost wrote: > 7. `std::error_code` enforced its value to always be an `int`. This is > problematic for coding systems which might use a `long` and implement > coding namespaces within the extended number of bits, or for end users > wishing to combine a code with a `void *` in order to transmit payload > or additional context. As a result, `status_code` is templated to its > domain, and the domain sets its type. A type erased edition of > `status_code<D>` is available as `status_code<void>`, this is for > obvious reasons non-copyable, non-movable and non-destructible. > > A more useful type erased edition is `status_code<erased<T>>` > which is available if `D::value_type` is trivially copyable, `T` is an > integral type, and `sizeof(T) >= sizeof(D::value_type)`. This lets you > use `status_code<erased<T>>` in all your public interfaces without > restrictions. As a pointer to the original category is retained, and > trivially copyable types may be legally copied by `memcpy()`, type > erased status codes work exactly as normal, except that publicly it does > not advertise its type. While I do see the need for providing extensions, I am not sure if status_code<void> is useful given all its "non-" characteristics. Can you elaborate on its use-cases? I propose that the customizable status_code<D> is renamed to basic_status_code<D>. In keeping with the pre-established practices of std::error_code using int, I furthermore suggest that status_code becomes a non-templated alias for basic_status_code<int>.

3 5

Gsoc2018/Mentor required.
by nivyatheresa 04 Mar '18

04 Mar '18

Hi, I am Nivya Theresa Jose, b-tech student from Indian Institute of Technology Roorkee. I would like to contribute to boost.uBLAS project 1, which is to add support for tensors .I would like to connect with a mentor and would like to know about further procedures. Thanks in advance, sincerely, Nivya Theresa Jose. -- Sent from: http://boost.2283326.n4.nabble.com/Boost-Dev-f2600599.html

1 0

Help/Mentor required
by Devika Krishnadas 04 Mar '18

04 Mar '18

Hi, I am Devika Krishnadas, an Undergrad Computer Science student from Amrita University. I am interested in contributing to boost.uBLAS project #1, which is to add Statistics and Machine learning functions. It would be great if anyone could help me proceed further. Thanks in advance, Regards, Devika Krishnads.

2 1

gsoc2018 inquiry and mentor seeking
by fady esam 04 Mar '18

04 Mar '18

Hello, I am Fady Esam student at 3rd year of computer engineering in ASU university in Egypt I want to cobtribute the the project of "Adding multicore and gpu computations to uBLAS" As i was the team leader and main contributer in an open source library for complex-numbers matrices that has the same parsing and interface as matlab and supports all operations like computing inverse by gaussian elimination and determinant by LU decomposition and +, - , * ,/ , .* , ./ and computing power of matrix in a very optimized way That's a github link to the library : https://github.com/boostorg/boost/wiki/Boost-Google-Summer-of-Code-2018 I want to know do i have to implement part of the library again in template for the competency test? And is there a mentor that is interested so i can submit a proposal to? Thanks for reading :)

2 2

[interprocess] file_mutex class proposal
by mateusz janek 04 Mar '18

04 Mar '18

Hello boost::interprocess community, During my pet projects development I found that a file access synchronization is a common problem so, I wrote a class that wraps it and thought that it can be useful for wider community. I would like to ask you what do you think about such functionality in boost::interprocess? I'm aware that class from the repo is not ready to release. Just wanted to show about what functionality I'm talking about. Here you can find the repo: https://github.com/stryku/file_mutex You can find there the proposed class and a simple usage example. If you will find it interesting I will prepare more formal merge proposal, update docs, maybe more examples etc. Looking forward to hearing from you what do you think about it. Thank you, Mateusz Janek

1 0

Which headers to include?
by Lakshay Garg 03 Mar '18

03 Mar '18

Hello Boost I am using a few Boost libraries in a project I am working on. I must confess that this is perhaps my first serious use of boost so all this could just be due to lack of familiarity. The one thing that keeps frustrating me about boost is finding out _which headers to include?_ I am not sure if this is a problem with my googling skills or library documentation or maybe I just don't know the proper place to look at but most of the times I need to use a library with lots of headers (I am looking at Boost.Log) I have to go grepping the boost code. Is there something I am missing or is there a better way to go about this problem? Lakshay

3 2

why boost does not have skip list implementation?
by David Frank 03 Mar '18

03 Mar '18

like java concurrentSkipListSet for example. Thanks, David

3 2

past few days coding:=>>makefile generator
by Ggh 03 Mar '18

03 Mar '18

#-------------------------------------------------------------------------------- # # Command Line Options: # # For each argument add a space between the switch and the argument to the switch, # e.g.: # # mkmakefile -tt exe -t targetname # # mkmakefile --help # # -tt <exe|dynamic|objs|static> Target type # -t <targetname> Target name # -i <include directory> Include directory # Include directories can be several. Prepend # each directory with an '-i' # -L <library directory> Library directory # Library directories may also be several, prepend each # directory with an '-L' # -l <library name> Library name, may also be several, prepend each # library with '-l'. # -d <define> Define # May also be several, prepend each define with '-d'. # -hd Header dependencies # This flag makes the generator scan # the source files for header files # included. Creates dependency rules # in the generated makefile. # If a header file is included in a source file # and found in any of the include directories given # it will be listed as a dependency to the source file. # -o <makefile filename> Makefile filename to generate # -c <c compiler> C compiler, the compiler needs to be in the PATH # environment variable. # -cc <c++ compiler> C++ compiler, the C++ compiler needs to be in # the PATH environment variable aswell. # -sl <static library> Link to static library # The number of static libraries can be any. # Prepend each library name with an '-sl' tag. # -wd <target directory> Target directory. The program changes # to the target directory, creates the makefile # and reverts back to the directory it was # started from. The makefile is written # to the target directory. If this argument is # not set then the current directory will be used. # -mk Make the program / library. This option executes # 'make' with the make file given. If no makefile # argument is given it will use 'makefile.mk' by # default # # -help This help information # #--------------------------------------------------------------------------------

1 0

[gsoc18]project1-1: Add statistics and machine learning functions
by SheldonZhang 02 Mar '18

02 Mar '18

Hi, My name is Zhang Bohan(Sheldon Zhang) from China. I am a freshman in Beijing University of Posts and Telecommunications, majoring in Information and Communication Engineering. I want a mentor who can guide me to accomplish the project. I am interested in working for Boost.uBLAS because in my profession there are plenty of calculation about matrix. I believe this will lead me to better understanding about it. And I love machine learning, it is the way to the future. I am taking a machine learning course(taught by Andrew Ng) on coursea. So I know what I am going to do in the project. I do quite well in Linear Algebra. In the exam, I got top 10% in the grade. I have been programming since junior high school. I am familiar to C++-11 and its features(like lambdas and template). I have good command of basic algorithms. I participated in National Olympiad in Informatics and got good grades. Besides, I am a teaching assistant in Program Designing Course. I am googd at English, so there is few difficulty in communicating. I have done the programming competency test https://github.com/ltg001/gsoc18-codeCompetencyTest At last, what should I do in this period? With regard, Sheldon Zhang -- Sent from: http://boost.2283326.n4.nabble.com/Boost-Dev-f2600599.html

2 1

[gsoc18] [Boost.Real] Competency Test
by Parth Mittal 02 Mar '18

02 Mar '18

Hi My name is Parth Mittal, and I'm a third year computer science undergraduate. Here is my attempt at the competency test: (wrt the first, second, and third bullet on the project page) 1. I uploaded my code here (https://github.com/parthmittal/boost_competency_test) I'm not sure how much of it is required to be functional but (of course) I can write more code if required. The current code uses an std::pair of the chosen rational type to represent intervals, it is probably more sensible to replace this with a dedicated type for intervals. Also I have two different ideas for dealing with integers in the binary operators: (i) Wrap them into a "real" number (with an approximation function that always returns the exact value and an error term of 0). (ii) Add a facility for additive and multiplicative rational factors to the class. 2. For sure there is no way to be sure two numbers are equal in finite time, so while checking if a and b are equal, we should pass an integer parameter, say K, and then for every pair of integers i, j between 1 and K, we should check if a(i) = b(j) (of course a(i) = b(j) iff the intervals share a point). This feels somewhat inefficient (it would be nice to eliminate the quadratic runtime with K), but since we don't have a guarantee that a(i + 1) is a subset of a(i), I don't see any obvious way to improve this. 3. To be honest, I had to google for "Small String Optimization" - and the analogue I can see is to store as an array the values of a(k) for all k <= K for some small constant K. I'm not sure how to implement this at compile time; it makes sense that the approximation function(s) for the real number involved be constexpr, but I've never written any code which is constexpr. Perhaps my code in (1) already makes this clear, but I'm not very experienced at writing C++; I've written probably 100k+ lines while doing programming contests, but this was rather simple code which was written once and read never. I can fill in the gaps in my knowledge of the language on an ad-hoc basis (or using the time until the SoC officially begins). Thank you for reading Parth Mittal

2 1

Boost Performance
by Ian Kosen 01 Mar '18

01 Mar '18

Hi, I was looking at this benchmark https://github.com/mloskot/spatial_index_benchmark <https://github.com/mloskot/spatial_index_benchmark> which attempts to compare the performance between Boost and LibSpatialIndex. It caught my eye that Boost was magnitudes faster than LibSpatialIndex. Is there an obvious reason for this? Design considerations and trade offs? Thank you :) Regards, Kosen

2 1

[teeks99-09-p-win2016-64on64][poly_collection] Regression with latest MSVC 14.1 in C++17 mode
by Joaquin M López Muñoz 28 Feb '18

28 Feb '18

Hi, MSVC 14.1 (_MSC_FULL_VER=191225834) in C++17 mode (_MSVC_LANG=201704L) is having a regression when compiling Boost.PolyCollection tests: http://www.boost.org/development/tests/develop/developer/output/teeks99-09-… The problem happens in this seemingly innocent context (https://github.com/boostorg/poly_collection/blob/654018c7ce14674a1c0527206a… ): template< typename ForwardIterator1,typename ForwardIterator2,typename Predicate > bool operator()( ForwardIterator1 first1,ForwardIterator1 last1, ForwardIterator2 first2,Predicate pred)const { ... using difference_type= typename std::iterator_traits<ForwardIterator1>::difference_type; difference_type l1=std::distance(first1,last1); // syntax error (wrongly) signalled here Is there some kind soul with access to this compiler who'd like to try the following workarounds and report the results? // workaround 1 using difference_type= typename std::iterator_traits<ForwardIterator1>::difference_type; typename difference_type l1=std::distance(first1,last1); // workaround 2 typedef typename std::iterator_traits<ForwardIterator1>::difference_type difference_type; difference_type l1=std::distance(first1,last1); Thank you! Joaquín M López Muñoz

2 2

request for comments in a new format library
by Roberto Hinz 28 Feb '18

28 Feb '18

Dear boost community, some time ago I announced a format library I'm working on. I think at that time it was still too incipient for one to evaluate whether it looked promising, thought some few but very useful observation were made ( one regarding i18n and other code bloat ) that made me change many things. Now the library is more evolved and I think it will be ready for review somewhere in the second half of this year, if no big change happens. This is a c++14 text format library with some unique features: - designed to be utf8 friendly - easy to extend for new destination types ( like some different string type ) - able to align (justify) a set of sub-arguments as one ( see joins <https://robhz786.github.io/stringify/doc/html/special_input_types/special_i…> ) - it enables the use of translations tools ( like gettext ), yet the formatting is not specified by a format string. And the problem with format strings that they lead to run time errors (instead of compilation error ) when they are incorrect. Hence I much appreciate any comments, especially if can identify any flaw I didn't realize. repo: https://github.com/robhz786/stringify doc: https://robhz786.github.io/stringify/doc/html/ best regards roberto

3 7

Re: [boost] [Boost-bugs] [Boost C++ Libraries] #13458: 'cl' is not recognized as an internal or external command, operable program or batch file. Failed to build Boost.Jam build engine. Please consult bjam.log for furter diagnostics.
by Andrew Depke 28 Feb '18

28 Feb '18

It looks like you're missing "cl.exe" on your system, or have not included it in your PATH. cl.exe, as seen here <https://msdn.microsoft.com/en-us/library/f35ctcxw.aspx>, is Microsoft's C++ compiler, which can be obtained by downloading the latest version of Visual Studio. Downloading and installing MSVS will automatically place it in your PATH. On Tue, Feb 27, 2018 at 2:28 PM, Boost C++ Libraries < noreply(a)lists.boost.org> wrote: > #13458: 'cl' is not recognized as an internal or external command, > operable program > or batch file. Failed to build Boost.Jam build engine. Please consult > bjam.log for furter diagnostics. > ------------------------------+--------------------- > Reporter: anonymous | Owner: (none) > Type: Bugs | Status: new > Milestone: To Be Determined | Component: None > Version: Boost 1.41.0 | Severity: Problem > Keywords: | > ------------------------------+--------------------- > 'cl' is not recognized as an internal or external command, > operable program or batch file. > > Failed to build Boost.Jam build engine. > Please consult bjam.log for furter diagnostics. > > -- > Ticket URL: <https://svn.boost.org/trac10/ticket/13458> > Boost C++ Libraries <http://www.boost.org/> > Boost provides free peer-reviewed portable C++ source libraries. > > _______________________________________________ > Boost-bugs mailing list > Boost-bugs(a)lists.boost.org > https://lists.boost.org/mailman/listinfo.cgi/boost-bugs > >

1 0

[release] 1.67.0 closed for major changes
by Daniel James 28 Feb '18

28 Feb '18

The master branch is now closed for major changes and will be closed for the beta in a week. Also, you can also add your libraries' changes to the release notes at: <https://github.com/boostorg/website/blob/master/feed/history/boost_1_67_0.q…> Remember that after editing the file, you need to submit the form to create a pull request. You can preview the release notes at: <http://www.boost.org/users/history/in_progress.html> Thanks, -- The Boost Release Team

1 0

Boost managed_shared_memory not working with C's mmap call on freeBSD
by vijay sharma 27 Feb '18

27 Feb '18

Hi All, I am having two processes and they are sharing shared-memory. - Process-1 (implemented in c++ and using boost::interprocess::managed_shared_memory interface) - Process-2 (implemented in c and using "she_open" and "mmap" interfaces) This code was working fine on Linux But When I deployed same code on FreeBSD. Process-2 (C lang based) is keep on throwing error in mmap. Error is "Bad file Descriptor". Please let me know: 1. Do I need to change the interface while moving from Linux to FreeBSD. 2. Is there any known issue with this design. Code Snippet: Process-1(c++): obj = new boost::interprocess::managed_shared_memory( boost::interprocess::open_or_create,<shm_name>, <shm_size>); // to create shm obj->allocate(<data_size>) ; // to write in shm Process-2 (c): int fd = shm_open(<shm_name>,O_RDWR, 0666);void * startpoint = mmap(NULL, <shm_size>, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0); // using the startpoint to read data written by process-1. Boost version: Boost.1.63.0 I have raised same on stackoverflow.com and below is the link: https://stackoverflow.com/questions/48984703/boost-managed-shared-memory-no… Thanks, Vijay

2 1

[Boost][CMake] Status of cmake support.
by Mike 26 Feb '18

26 Feb '18

Hi everyone, since I couldn't find any official information about that, I wanted to ask if there is any new information about the cmake support in boost (since the initial discussion on the ml after the steering committee's announcement)? Is there some agreement on how to do the transition or at least a popular formal/informal proposal? Is there any place to track which libraries can already be built with cmake? What is the best way for a non library authors like me to help with the transition? IIRC there was talk about a cmake library some time ago, but I haven't heard anything about that in a long time. Is such a library even desired/necessary? Imho getting all of boost to compile with cmake should be pretty simple, but if this is expected to happen in a transparent manner (same output, same workflow including test result upload), a fair bit of boost knowledge, cmake skills and support machinery might be required. Best regards Mike

10 15

[winapi] Bumping default target to Windows 7?
by Andrey Semashev 26 Feb '18

26 Feb '18

Hi, I was thinking about bumping the default target Windows version to 7 in Boost.WinAPI. The current default is Vista, which EOLed in April 2017. There is not much difference from the available API standpoint (in Boost.WinAPI this would enable a few constants related to process management), but there may be some interesting extensions that could be useful to libraries. Note that this will not preclude targeting older Windows versions, just as it doesn't preclude targeting XP or 2000 now. Users will still be able to specify the target Windows version as they can now. Note also that I'm not planning this for 1.67, only 1.68. Any objections/thoughts?

1 0

[gsoc18] Project - Add statistics and machine learning functions
by Anagha G 26 Feb '18

26 Feb '18

Hi, I'm Anagha G. I'm pursuing 2nd year Bachelor of Engineering in Information Science and Engineering in R.V College of Engineering, Bangalore, India. I'm interested to work on a project to add statistics and machine learning functions to Boost.uBLAS. I've a good knowledge in Statistics, data visualization and Machine Learning. I've also learnt C++ and use it everyday for projects and academic assignments. Please let me know further details about finding a mentor and also how I should submit my competency test. Thanks Anagha G

1 0

[system] [teeks99] Mass test failures on MSVC-14.0
by Andrey Semashev 26 Feb '18

26 Feb '18

Hi, Most of Boost.System tests are failing on the teeks99-09-f-win2016-64on64 tester, MSVC-14.0[1]. The test logs don't show any errors and I can't reproduce it locally. I'm seeing similar test failures in other libraries, like Boost.Atomic for example, and the links point to Boost.System. Is it possible to get the error log from the tester? [1]: http://www.boost.org/development/tests/develop/developer/system.html

2 2

Re: [boost] [Boost][CMake] Status of cmake support.
by Mike 26 Feb '18

26 Feb '18

I don't believe in conspiracies. But I've seen enough resistance (me st of it well reasoned) on the ml after the steering committee made their announcement that I wouldn't be surprised if a lot of reviews focus on deficiencies / differences compared to boost build that are inherent to cmake and not the library itself.

6 5

crash during bad_file_descriptor
by VIKRAM LODHI 26 Feb '18

26 Feb '18

Hi, Working Scenario: I have a scenario of single server and multiple client. server is constantly sending update to connected client. all the connection and transmission is async. Problem: lets say i have 3 client connected. which they are receiving update . if one client closed during in middle of transmitting. (killing the process of client ) my server crashes .. socket.async_write_some(buffer, [&](error_code& e, size_t size_) { if(e) { cout << e.message() << endl; } }); the last error i get is bad_file_descriptor . pfa : error thrown by gdb

1 0

make makefile
by Ggh 26 Feb '18

26 Feb '18

Hello all, The past few days I have kept myself busy coding a kind of makefile generator. It can scan directories and generate makefile(s) from what c/c++ files it finds. Is such a program of interest to the boost lib? If so, I'd like to contribute. thank's Greg

2 2

Re: [boost] [gsoc18]Boost.SafeFloat
by Rajat Miglani 25 Feb '18

25 Feb '18

I have read the paper "Goldberg, David. "What every computer scientist should know about floating-point arithmetic." ACM Computing Surveys (CSUR) 23.1 (1991): 5-48."and documentation and now having a little understanding of what this project is about.Presently going through the code and concepts, please guide me of what changes I have to do in the previous code to make it better. On Wed, Feb 21, 2018 at 11:52 PM, Damian Vicino <damian(a)vicino.com.ar> wrote: > Hi Rajat, > For the Boost.SafeFloat project, I suggest you take a look to the > following links: > - Repository: https://github.com/sdavtaker/safefloat > - Documentation: https://sdavtaker.github.io/safefloat/doc/html/index.html > > Also, try to read this paper if you didn't before: Goldberg, David. > "What every computer scientist should know about floating-point > arithmetic." ACM Computing Surveys (CSUR) 23.1 (1991): 5-48. > From the C++ perspective, key concepts you need to know are: > - Templates (a lot of it) > - Custom Literals > > A good proposal would be to take a read to the documentation and code base > and describe what is missing to complete the project. > Best regards, > Damian Vicino > > > > > 2018-02-21 14:11 GMT-03:00 Rajat Miglani via Boost <boost(a)lists.boost.org> > : > >> Dear boost community, >> I am a GSOC aspirant and I'd like to contribute to your organization. >> I have read the project ideas and is interested in working on:- >> 1)Boost.SafeFloat or >> 2)Enhancing Boost.Intrusive Library >> Can I get some more info about how to work on these projects and the basic >> requirements so that I can learn them and be able to contribute to my >> fullest. >> >> Thank you, >> >> _______________________________________________ >> Unsubscribe & other changes: http://lists.boost.org/mailman >> /listinfo.cgi/boost >> > >

1 0

[gsoc18] Project - Add statistics and machine learning functions
by Anagha G 25 Feb '18

25 Feb '18

Hi, I'm Anagha G. I'm pursuing 2nd year Bachelor of Engineering in Information Science and Engineering in R.V College of Engineering, Bangalore, India. I'm interested to work on a project to add statistics and machine learning functions to Boost.uBLAS. I've a good knowledge in Statistics, data visualization and Machine Learning. I've also learnt C++ and use it everyday for projects and academic assignments. Please let me know further details about finding a mentor and also how I should submit my competency test. Thanks Anagha G

1 0

GSoC 2018
by shubham soni 25 Feb '18

25 Feb '18

Hello Boost Community! I'm Shubham Soni, fourth year dual degree student from IIT Kharagpur, India. I have experience in working with C/C++, Python, ruby and good theoretical knowledge in parallel programming. I've gone through the project list and found out* Boost.UBLAS (Add statistics & machine learning function)* to be interesting and i want to contribute in it. I have downloaded the code base and i am trying to understand it. Is there something else that i should read or anything you would suggest? Thanks *shubham soni*

1 0

regarding gsoc 2018
by Akshay Raut 23 Feb '18

23 Feb '18

hello everyone i am from india doing bachelors in computer science. I am very passionate for c++ and hence, I want to contribute to it through this organization in this year's gsoc. can someone please tell me the best way to get started so that i get selected this year??

2 1

[yap] Re-announcing Yap
by Zach Laine 23 Feb '18

23 Feb '18

I posted 2-3 months ago about Yap, an expression template library I've written that I intend to propose for Boost. This is just a reminder that the library exists, and where to find it. I'm giving a talk about it at C++Now 2017, and some time after that I intend to submit it to the queue. Louis Dionne has offered to serve as review manager when the time comes. You can find the main repo on GitHub: https://github.com/tzlaine/yap And online docs are here: https://tzlaine.github.io/yap Zach

4 6

Query for interest in library: reflective enum
by Nir Friedman 23 Feb '18

23 Feb '18

Hello, I recently needed a reflective enum for work (that is an enum where you can programmatically convert to and from strings, know how many enumerators there are, and iterate over all enumerators). I looked online but I didn't find anything that met my requirements. I was surprised that there wasn't one in Boost. So I'd like to see if there is interest; I wrote an implementation that I think has several nice features. The most polished existing smart enum implementation I could find was http://aantron.github.io/better-enums/. However, the enum implemented there is not a true enum; it uses a nested member of a class kind of approach. So for example, the is_enum type trait will not recognize is as an enum. You cannot use it as a non-type template parameter. I strongly think that a good generic smart enum macro should generate the exact "vanilla" enum (or enum class) declaration. My library's syntax looks like this: WISE_ENUM(Foo, BAR, (BAZ, 3)) This generates, among other things, exactly: enum Foo { BAR, BAZ=3}; I intend this as an explicit guarantee of the library that the programmer can count on. That way when Foo is used for things unrelating to reflection, the developer can be confident that there will not be any surprises. Beyond compatability with C++ facilities for enums, and minimizing surprise, another advantage of this approach is that it's guaranteed to be backwards compatible. An existing codebase with an existing enum/enum class can switch to this smart enum with very high confidence that existing code will continue to work as before. The WISE_ENUM macro, beyond generating the vanilla enum, also generates a switch-case function for to-string conversion (for maximal efficiency), and finally it generates a constexpr function that returns a std::array<std::pair<const char*, Foo>> listing all of the arrays and their string descriptions. This constexpr function, which is found via ADL, allows writing a sequence of (constexpr) variables and functions providing the rest of the desired functionality. Usage looks like this: std::cerr << "My enum's size is : " << wise_enum::size<Foo> // this is constexpr template variable auto x = wise_enum::from_string<Foo>("BAR").value(); // from_string returns an optional auto y = wise_enum::to_string(x); // y is string literal, no heap allocation My implementation (POC level) is here: https://github.com/quicknir/wise_enum. I don't yet have separate macros to cover enum/enum class/explicit/implicit backing type combinations. It's only about 100 lines of code, leaning heavily on BOOST_PP to do the heavy lifting. It requires variadic macros, and can probably target C++11 (if it doesn't already). I probably need to "comma harden" the macros for bizarre stuff like WISE_ENUM(Foo, (BAR, my_func<3,4>())). It has the limitation that the macro cannot be used inside a class (this is hard to workaround for reflective macros). It's also unclear how repeated enumeration values would be handled (enum Foo { BAR = 1, BAZ = 1}). As it stands this will cause a compilation failure in the generated switch case of the to_string function. Can discuss more in subsequent emails. One suggested feature is an is_contiguous trait. Another reasonable bit of functionality might be an is_wise_enum trait. Version 2 of this library could target enum sets. Although it's not fancy, I think this nicely covers a piece of functionality I often need, and it does so avoiding any downside compared to using a simple enum (beyond having to use macros). Hope other people will agree! Cheers, Nir

4 5

[Math] Only a fraction of the tests showing up online
by John Maddock 23 Feb '18

23 Feb '18

I assume this is an issue with the test matrix, but only about 1/3 of the Math lib tests are showing up at http://www.boost.org/development/tests/develop/developer/math.html Thanks, John. --- This email has been checked for viruses by AVG. http://www.avg.com

2 4

[gsoc18] - Similarity Between Geometries and Timeframe Question
by Aidan Nyquist 23 Feb '18

23 Feb '18

Hello, My name is Aidan Nyquist, a sophomore at North Park University. I'm currently majoring in Math and Physics, and minoring in computer science. I have been programming for about 4 years now, and have experience with a fair amount of languages (Python, C/C++, Java, LISP, Haskell, SQL, etc.). Sifting through all the GSoC projects, while fun, can be somewhat difficult. I have just found the "Similarity between geometries" project and think I am a great fit. I wish I had found it sooner though, so I could have started the evaluation test done by now. Is there a rough deadline for its submission? I'm applying for one other organization, and they had a Feb. 28 deadline. If there is a similar date, I will reluctantly not attend the Hackathon I was hoping to go to this weekend. However, if there is some buffer time, that would be great to know, so I could be at ease. Any advice is always appreciated. Thanks, Aidan Nyquist

2 1

Yap's formal review is starting now!
by Louis Dionne 23 Feb '18

23 Feb '18

Dear Boost community, The formal review of Zach Laine's Yap library starts Monday, February 5th and ends on Wednesday, February 14th. Yap is a C++14-and-later library to build expression templates. Yap uses new features introduced in C++14/17 to make the library simpler to use and compile faster than existing solutions, such as the well known Boost.Proto library. The documentation is available here: https://tzlaine.github.io/yap/doc/html/index.html The GitHub repository is available here: https://github.com/tzlaine/yap We encourage your participation in this review. At a minimum, please state: - Whether you believe the library should be accepted into Boost - Your name - Your knowledge of the problem domain You are strongly encouraged to also provide additional information: - What is your evaluation of the library's: * Design * Implementation * Documentation * Tests * Usefulness - Did you attempt to use the library? If so: * Which compiler(s)? * What was the experience? Any problems? - How much effort did you put into your evaluation of the review? All issues discussed during this review will be tracked on the library's GitHub issue tracker at https://github.com/tzlaine/yap/issues. Regards, Louis Dionne P.S.: I've been having trouble posting to this list. If this ends up being a duplicate post, let's make this one the official one.

14 107

Re: [boost] New Astronomy Library
by Pranam Lashkari 22 Feb '18

22 Feb '18

These days I was studying already available astronomy libraries in different languages. I found that "Astropy"( http://www.astropy.org/ ) is well established and it is being used in many places. Maybe one of the reasons for its success is that it is for Python. As we all know that python is one of the easiest languages to learn. Not all scientists are programmers and maybe that's why they find python and Astropy easy to use. So what I was thinking is, what if we build a similar structure to the same library? It will make things easier for those scientists who do not have much time to learn a new programming language and this will make the transition easier from python to C++. Is it a good idea? Pranam Lashkari On Mon, Feb 12, 2018 at 7:31 PM, JC Passy <jcpassy(a)gmail.com> wrote: > Dear Pranam, > > Sorry for taking so long to get back to you. > So I talked to some of my former colleagues about potential projects > related to the analysis of astronomical data. They forwarded me the > following paper which gives an example of the amount of data they are > dealing with and some solutions they have found. I think you might find it > interesting: > http://adsabs.harvard.edu/abs/2017PASA...34...38V > > I must say in terms of concrete ideas, they did not have anything specific > to suggest. Most of these large surveys have already teams dedicated to > develop a pipeline to deal with their specific data. However, we will keep > looking and talking to people, may be something will come up in the future. > > In the meantime, you seem to already have ideas for amateur astronomers. I > suggest you start with it (I am happy to help you if you feel like it) and > I will let you know if a potential project for professionals comes up. Does > it sound good to you? > > Cheers, > > Jean-Claude > > > On 26. Jan 2018, at 12:17, JC Passy <jcpassy(a)gmail.com> wrote: > > Dear Pranam, > > Sure, I am waiting for some feedback from two former colleagues of mine on > that matter. I should get something by early next week, I will let you know > as soon as I do. > > Cheers, > > Jean-Claude > > On 25. Jan 2018, at 13:49, Pranam Lashkari <plashkari628(a)gmail.com> wrote: > > Dear Jean-Claude; > > As you mentioned in your emails, you are having some ideas what can be > implemented in this library as per requirement of professionals in this > field. > Can you start discussing those ideas so that we can get a better idea of > how to structure this library? > > On Mon, Jan 22, 2018 at 1:40 AM, JC Passy <jcpassy(a)gmail.com> wrote: > >> Dear Pranam, dear Vinicius, >> >> not sure that my initial email made it to the mailing list. If it did, >> sorry for repeating myself. >> I am working as a computer scientist at the MPI for Intelligent Systems >> in Tübingen. Before that, I did my PhD in astrophysics and a postdoc. In >> general, I am also interested in using boost and developing a library that >> could be used by astronomers and astrophysicists. >> >> Looking at your proposal, I would second Vinicius’ opinion in the sense >> that one should try to make it a bit more specific. In particular, you >> should emphasize the *why* (what do you wish to accomplish? why would >> someone need/use it?) and the *who* (who is your target audience?). >> Regarding the latter, I see two options: >> >> 1) *amateur astronomers*: I personally do not know what their needs are, >> but I could try to find out. There are some open source projects dedicated >> to amateur astronomers (for instance https://openphdguiding.org to which >> we contributed), so that could be an option; >> >> 2) *professional astronomers*: I think a lot can be done, in particular >> regarding observational data analysis. They used *REALLY* old tools >> (IDL, IRAF, …) and given the future and upcoming surveys that will produce >> very large amount of data, they might have serious performance issues. This >> is why I believe they might benefit from using cutting-edge C++ libraries. >> >> I would be quite interested in option 2, and it could impact potentially >> a large audience IMHO. Of course, the “selling” part won’t be easy (people, >> especially astrophysicists :) won’t give up their old methods easily even >> though the new method is 10x faster) but we can facilitate this process by >> pin-pointing features that they really need. I will try to talk to some of >> my former colleagues this week and see what they think about that. In this >> case, this is a project that would need a bit of time to be properly >> defined and the deadline for GSoC18 is coming too soon. As far as I am >> concerned, this is no problem as this project does not need to be tied to >> it. >> >> Cheers, >> >> Jean-Claude >> >> >> On 21. Jan 2018, at 15:00, Vinícius dos Santos Oliveira via Boost < >> boost(a)lists.boost.org> wrote: >> >> 2018-01-21 8:07 GMT-03:00 Pranam Lashkari <plashkari628(a)gmail.com>: >> >> I have made this proposal for this new library(check attachment) >> Suggestions are invited. >> >> >> You need to focus more on "selling your project". Why is it important to >> have such library in C++ specifically? Isn't this one of those projects >> where other languages will do just fine? What market are we missing by not >> having this library? What C++ have to offer to make such library be >> inviting to write in C++? >> >> You mention "gather information from observation data". Does this mean >> you'll include a parser for some format? >> >> Can you compare this library with some non-C++ library and detail a little >> how will scope between the two differ (e.g. your library will focus >> initially only on X given the library is only starting)? >> >> For now, this should be good. When it's time to submit the student form >> through the GSoC platform, you'll also focus on selling yourself. I'll >> give >> more feedback on this when the time comes. Don't worry. >> >> Should I publish this on the wiki page of Boost GSoC 2018? >> >> >> >> Yes, please. You can put my name as a potential mentor. >> >> -- >> Vinícius dos Santos Oliveira >> https://vinipsmaker.github.io/ >> >> _______________________________________________ >> Unsubscribe & other changes: http://lists.boost.org/mailman >> /listinfo.cgi/boost >> >> >> > > >

3 4

[gsoc18] SafeFloat or Real
by Thomas Ferrand 21 Feb '18

21 Feb '18

Hello everyone, I'm a student willing to be part of this year GSoC program and I'd love to work with Boost. Among the proposed projects, I'm interested in two of them, Boost.SafeFloat and Boost.Real. As Damian Vicino is said to be the potential mentor of both, I already send him an email but don't have any answer for now. I've already made the competency test for Boost.SafeFloat but I don't know what to do now, wait for an answer? Seek another mentor? Can you please guide me? Thanks, Thomas Ferrand

2 1

new to the organization
by Rajat Miglani 21 Feb '18

21 Feb '18

Dear boost community, I am a GSOC aspirant and I'd like to contribute to your organization. I have read the project ideas and is interested in working on:- 1)Boost.SafeFloat or 2)Enhancing Boost.Intrusive Library Can I get some more info about how to work on these projects and the basic requirements so that I can learn them and be able to contribute to my fullest. Thank you,

2 1

Legal problem with Stackoverflow contribution under the "Creative Commons Attribution Share Alike 3.0" license
by Dominique CHABAUD 21 Feb '18

21 Feb '18

Hi all, In Boost 1.62.0 we saw in the following header file : boost/thread/win32/thread_primitives.hpp that the function inline ticks_type __stdcall GetTickCount64emulation() is a contribution coming from https://stackoverflow.com /questions/8211820/userland-interrupt-timer-access-such- as-via-kequeryinterrupttime-or-similar Stackoverflow re-lisensing to MIT is told to be in place starting Feb 1, 2016 and only for new contributions. But the StackOverflow contribution that has been borrowed in Boost is Nov 23, 2011 and contributions prior to Feb1, 2016 are under the "Creative Commons Attribution Share Alike 3.0" license which is not permissive. This causes legal problem. Hope somebody can fix this. Thanks Dominique

15 37

Re: [boost] C++03 / C++11 compatibility question for compiled libraries
by Glen Fernandes 21 Feb '18

21 Feb '18

Olaf van der Spek wrote: > > Glen Fernandes wrote: >> Before I became a contributor to Boost, and before I became a Boost >> library author, I was a user of Boost at Microsoft. Even as late as >> 2014 when I left the company, those projects depended on Boost for >> C++03 support. (In fact, at least one of the projects only dropped >> C++03 support as late as 2016). > > Where did the C++03 support requirement come from though, an old compiler? > Even VS 2010 knows some C++11 stuff. Supporting teams that were still on older compilers was the motivation, yes. Boost was upgraded more frequently than upgrading to a newer compiler (even though in this particular case, the compiler was developed within the same company). For that project I referenced which dropped C++03 support in 2016, they also dropped VC10 support in the same year. Those projects came to depend on the reliability of Boost for its implementation of standard library facilities that were otherwise defective in VC that wouldn't be fixed until the next major release of the compiler, while Boost releases were every few months. Even trivial standard library things like std::ref, std::addressof, std::unique_ptr::~unique_ptr (wrong order of operations in VC10, fixed in VC11), std::align (wrong return value in VC11, fixed in VC12), std::call_once (was 1500 times slower than InitOnceExecuteOnce, fixed in VC14), the list went on. After a while, certain projects that dropped compatibility still chose to use Boost instead of the corresponding [now fixed] standard library facilities, just operating under the assumption that Boost would provide a higher quality of implementation, and more rapid rate of maintenance. Glen

2 1

failing accumulators tests
by Yuval Lifshitz 21 Feb '18

21 Feb '18

Dear All,Did anyone seen these failures on p_square_cumul_dist and weighted_median (latest checkout from github and gcc7.3.1/fedora27)? libs/accumulators/test/p_square_cumul_dist.cpp(66): error: in "p_square_cumulative_distribution test/test_stat": difference{0.0331329} between 0.5 * (1.0 + my_erf( histogram[i].first / std::sqrt(2.0) )){0.010331329148570989} and histogram[i].second{0.01} exceeds 3%libs/accumulators/test/p_square_cumul_dist.cpp(66): error: in "p_square_cumulative_distribution test/test_stat": difference{0.0372556} between 0.5 * (1.0 + my_erf( histogram[i].first / std::sqrt(2.0) )){0.020755484496021825} and histogram[i].second{0.02001} exceeds 3% libs/accumulators/test/p_square_cumul_dist.cpp(66): error: in "p_square_cumulative_distribution test/test_stat": difference{0.0326898} between 0.5 * (1.0 + my_erf( histogram[i].first / std::sqrt(2.0) )){0.030980693519017} and histogram[i].second{0.029999999999999999} exceeds 3% libs/accumulators/test/p_square_cumul_dist.cpp(66): error: in "p_square_cumulative_distribution test/test_stat": difference{0.0306804} between 0.5 * (1.0 + my_erf( histogram[i].first / std::sqrt(2.0) )){0.041227215128245343} and histogram[i].second{0.040000000000000001} exceeds 3% libs/accumulators/test/weighted_median.cpp(50): error: in "weighted_median test/test_stat": difference{0.0327894} between 1.{1} and weighted_median(acc_dens){0.96825159071079681} exceeds 3% libs/accumulators/test/weighted_median.cpp(51): error: in "weighted_median test/test_stat": difference{0.0316788} between 1.{1} and weighted_median(acc_cdist){0.96929395242297978} exceeds 3% Best Regards, Yuval

1 0

[release] 1.67.0 closed for major changes
by Daniel James 21 Feb '18

21 Feb '18

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. Although I'm allowing HOF to merge a little late, as I haven't had much to time to check it for release this week. 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_67_0.q…> After editing the release notes, you should get a form to create a pull request, remember to submit it, otherwise I won't see your change. Also, a reminder that there are now templates for linking to github issues and pull requests. To link to a github issue use [github module-name issue-number] and to link to a pull request [github_pr module-name issue-number]. For example, to link to issue 24 from uuid, use [github uuid 24] which generates the text '#24'. Thanks, -- The Boost Release Team

1 0

C++03 / C++11 compatibility question for compiled libraries
by Raffi Enficiaud 20 Feb '18

20 Feb '18

Dear list, I have a technical question I do not know how to address, and I would like to know how people deal with this. To put things in the background: boost.test uses heavily boost::function and boost::bind, however I would like to use in some circumstances std::function and std::bind, which are, for instance, variadic. Boost.test is compiled with b2. I believe if the user does not pass additional parameters to the build, the default is to use whatever is provided in the Jamfile, that compiles the static and shared libraries in C++03 mode. If the user of boost.test compiles in C++03, it is ok if the library is used in a C++11 project. The other way is obviously not true. Now, in the headers of boost.test, I can detect for the compiler version, and depending on the language settings, activate an API that is C++11. OTOH, if I do not want users to be confused, this API should be header only. But this hardly work in practice, as the C++03 and C++11 APIs are usually not separable. Say: struct test_case { // compiled member function test_case(boost::function<void ()> function_to_test); #if Cpp11 // std::function variant to ensure compatibility with std::bind test_case(std::function<void ()> function_to_test); #endif private: boost::function<void ()> m_function_to_test; }; This API is obviously not good at all, and for having the slightest chance to make this work, the 2 APIs C++11 vs C++03 should be mutually exclusive. This also produces 2 different incompatible shared/static libraries, which is even more confusing for the user as the compiler options should be transitively passed to the user's code, or the user should be aware of which library to link with. So, the questions are: * how do other boost developers deal with this? * what is your experience on users in terms of compilation+linking? are usually people aware of this problem and they compile in C++11 all the code including boost? * is there any better option? All the other options I see are even worse. Thanks, Raffi

24 140

C++03 / C++11 compatibility question for compiled libraries
by Mike 20 Feb '18

20 Feb '18

Hello everyone, I hope it is ok, for me as a non-boost-dev, to chime in here. What I generally expect " dropping c++03 support" to mean are the following things: - Any library may start to use c++11 features at any point without prior announcement and/or without having to wait a few releases (I.e. it is no longer considered a breaking change). - c++03 builds are removed from the test matrices - Compilation paths that are c++03 only can be removed (thus simplifying the code base and future refactoring/development) - My hope (obviously no one can or should force a volunteer to do anything) is that - where applicable - libraries start to replace boost types & functions that have been merged into the c++11 standard with their std equivalent or the equivalent c++11 language feature. - In the long run, libraries that have been fully merged into c++11 could be deprecated and removed all together. Just to be clear: Dropping c++03 support doesn't mean a developer is forced to use c++11 constructs (if we ignore the potential future removal of boost libraries) - it primarily means that a user can no longer rely on the lib being usable in c++03 mode. And yes, this could be done on a per library basis, but especially older boost libraries are so tightly coupled that such decisions affect a lot of other libraries anyway. So my guess is that very few maintainers would dare to drop c++03 support as long as that hasn't been deemed acceptable by larger parts of the boost community.j Best regards Mike -- Diese Nachricht wurde von meinem Android Mobiltelefon mit GMX Mail gesendet.

7 8

Review of Yap concluded today
by Louis Dionne 20 Feb '18

20 Feb '18

Dear Boost, The review of Zach Laine's Yap library concluded today, February 19th. I'd like to thank everyone who submitted a review or participated to the discussion in one way or another. The following reviews were submitted: - Barrett Adair (accept): https://lists.boost.org/Archives/boost/2018/02/241284.php - Alex Hagen-Zanker (reject/conditional accept): https://lists.boost.org/Archives/boost/2018/02/241296.php - Paul Fultz II (accept): https://lists.boost.org/Archives/boost/2018/02/241251.php - John Fletcher (accept): https://lists.boost.org/Archives/boost/2018/02/241212.php - Brook Milligan (conditional accept): https://lists.boost.org/Archives/boost/2018/02/241386.php - Steven Watanabe (accept): https://lists.boost.org/Archives/boost/2018/02/241442.php Please let me know if I've missed anyone. Also, for reference purposes, here are other notable general threads in the list archives that are related to the review: - Discussion on contextual evaluation of terminals: https://lists.boost.org/Archives/boost/2018/02/241092.php - Discussion on std::tuple vs hana::tuple: https://lists.boost.org/Archives/boost/2018/02/241351.php - Steven Watanabe on the documentation: https://lists.boost.org/Archives/boost/2018/02/241196.php - Steven Watanabe on the implementation: https://lists.boost.org/Archives/boost/2018/02/241281.php - Kickoff post: https://lists.boost.org/Archives/boost/2018/02/241076.php - Post extending the review until February 19th: https://lists.boost.org/Archives/boost/2018/02/241303.php I will summarize what was discussed during the review and announce the result of the review in a future post. Regards, Louis Dionne

1 0

[gsoc 18] - Enhancing Boost.Intrusive Library
by harisaicharan.challa＠gmail.com 19 Feb '18

19 Feb '18

Hello Boost community, I am Hari sai charan challa, 3rd year undergraduate student from International Institute of Information Technology, Hyderabad (IIIT). I have been working on boost-libraries since 2 months, trying to fix a bug.I can code efficiently in C++ .I have good knowledge in Data structures and Algorithms.I am interested in "Enhancing Boost.Intrusive Library" project so i am looking for a mentor to guide me in this project.

3 3

(no subject)
by karan singh 18 Feb '18

18 Feb '18

hello all , i want to contribute for boost and want to participate in gsoc18. i have c++ knowledge but dont know where to start.

2 1

[gsoc 18] Enhancing Boost.Intrusive Library
by harisaicharan.challa＠gmail.com 18 Feb '18

18 Feb '18

Hello, I am Hari.I am working on competency test of "Enhancing Boost.Intrusive library" project , so can someone please elaborate on the following requirement for the competency test. Requirement:- Test programs for ensuring accuracy and performance benchmark tests against various type of solutions (brute-force, recursive, iterative) Thank-you.

1 0

(no subject)
by karan singh 18 Feb '18

18 Feb '18

hi all , i want to contribute for boost , can anyone help i am a newbie

1 0

Moving Boost.HigherOrderFunctions(formely know as Fit) to boostord
by paul 15 Feb '18

15 Feb '18

Hi All, Can someone with Admin access help me move my repo to boostorg? Thanks, Paul

2 3

[GSoC'18] Project : Add support for tensors
by Manan Sharma 15 Feb '18

15 Feb '18

Hello Boost Community, My name is Manan Sharma. I am a 3rd year undergraduate student pursuing my B.Tech in Computer Science and M.S by research in IIIT Hyderabad, India. I have good understanding of Linear Algebra and Machine Learning. I have a sound background in data structures and algorithms and have qualified twice for ACM ICPC regionals. I have secured good rank in other programming contests too. I have good understanding of C++ having done all my competitive programming and several different projects using it. I am interested in project for adding support for tensors in uBLAS. Since I am new to open source, please let me know as to how can I get started. Thanks Manan Sharma

2 1

Can't build docs in downloaded Boost 1.66 sources
by Zach Laine 15 Feb '18

15 Feb '18

I came across this while trying to build the Yap docs, outside the Boost source tree. It turns out it doesn't work in the Boost source tree either. This: cd ~/boost_1_66_0 ./bootstrap.sh cd libs/units/doc ~/boost_1_66_0/b2 used to work (not sure how long ago). Now it says this: tzlaine@linux-desk:~/boost_1_66_0/libs/units/doc$ ~/boost_1_66_0/b2 Performing configuration checks - 32-bit : no (cached) - 64-bit : yes (cached) - arm : no (cached) - mips1 : no (cached) - power : no (cached) - sparc : no (cached) - x86 : yes (cached) - symlinks supported : yes (cached) BoostBook warning: no DocBook XSL directory specified. If you have the DocBook XSL stylesheets installed, please set DOCBOOK_XSL_DIR to the stylesheet directory on either the command line (via -sDOCBOOK_XSL_DIR=...) or in a Boost.Jam configuration file. The DocBook XSL stylesheets are available here: http://docbook.sourceforge.net/ Stylesheets will be downloaded on-the-fly (very slow!) ...patience... ...patience... ...patience... ...found 2671 targets... ...updating 2 targets... xslt-xsltproc ../../../bin.v2/libs/units/doc/gcc-gnu-7/debug/threadapi-pthread/units.docbook http://docbook.sourceforge.net/release/xsl/current/common/common.xsl:1: parser error : Start ta g expected, '<' not found Project web is currently offline pending the final migration of its data to our ^ compilation error: file /home/tzlaine/boost_1_66_0/tools/boostbook/xsl/docbook.xsl line 12 elem ent import xsl:import : unable to load http://docbook.sourceforge.net/release/xsl/current/common/common.xs l XML_CATALOG_FILES="../../../bin.v2/boostbook_catalog.xml" export XML_CATALOG_FILES "xsltproc" --stringparam boost.defaults "Boost" --stringparam boost.root "../../../.." --strin gparam chunk.section.depth "8" --stringparam toc.max.depth "1" --stringparam toc.section.depth "8" --xinclude -o "../../../bin.v2/libs/units/doc/gcc-gnu-7/debug/threadapi-pthread/units.docbo ok" "/home/tzlaine/boost_1_66_0/tools/boostbook/xsl/docbook.xsl" "../../../bin.v2/libs/units/do c/gcc-gnu-7/debug/threadapi-pthread/units.xml" ...failed xslt-xsltproc ../../../bin.v2/libs/units/doc/gcc-gnu-7/debug/threadapi-pthread/units. docbook... ...skipped <phtml>standalone_HTML.manifest for lack of <p../../../bin.v2/libs/units/doc/gcc-gnu -7/debug/threadapi-pthread>units.docbook... ...failed updating 1 target... ...skipped 1 target... That's the full output from doing the build a second time, FWIW. Some of the steps the first time said the same thing, but it seemed too much to post. Anyone know what's doing on? Zach

2 2

New developer interested in working on the Project 1 of Boost.ublas for GSoC18
by pranay gupta 14 Feb '18

14 Feb '18

Hello everyone, My name is Pranay Gupta I am a second year computer science undergrad at IIIT Hyderabad, Im new here at Boost. I was very much interested in doing the first project of Boot.uBLAS which was about adding statistical and machine learning functions to Boost.uBLAS and have started with the competency test. Can someone please guide me as to how should I share my competency test with the mentors and improve it further. Thank You, Yours Sincerely, Pranay Gupta

2 1

Re: [boost] [yap] Review
by P F 14 Feb '18

14 Feb '18

> On Feb 14, 2018, at 1:38 PM, Zach Laine <whatwasthataddress(a)gmail.com> wrote: > > On Tue, Feb 13, 2018 at 8:24 PM, P F <pfultz2(a)yahoo.com <mailto:pfultz2@yahoo.com>> wrote: > >> On Feb 12, 2018, at 7:57 PM, Zach Laine via Boost <boost(a)lists.boost.org <mailto:boost@lists.boost.org>> wrote: >> >> On Mon, Feb 12, 2018 at 4:15 PM, P F via Boost <boost(a)lists.boost.org <mailto:boost@lists.boost.org>> >> wrote: >> >> I actually experimented with trying to remove the Hana bits for this exact >> reason. The conclusion I came to was that writing the library was quite a >> bit harder in a couple of places, but that's not too bad. The bigger >> problem is that the lack of algorithms over std::tuple for users of the >> library when they write transforms. Maybe we should talk offline about how >> to do things that are done now with Hana, with Fit instead. > > Actually, the main algorithms you use are transform, for_each, and unpack, which is trivial to do with Fit. Doing a `zip` or `filter` is a little more complicated, but grepping the source code, I did not see that. I discuss how thats done here: > > http://pfultz2.com/blog/2015/09/12/power-of-unpack/ <http://pfultz2.com/blog/2015/09/12/power-of-unpack/> > > Which we can discuss more offline. > > I also use Hana constants all over the place. Yes, but it should be simple to move from `0_c` to `c<0>{}`. Ultimately, it really should be moved to a separate library, because even Boost.TypeTraits could use these “enhanced” integral constants(but that is another discussion). >>> by just taking it as a type and using something similiar to `mp_transform` >>> to change the parameters. Or even change `Kind` to be a type of >>> `std::integral_constant<boost::yap::expr_kind, Kind>` so `mp_transform` >>> could be used directly: >>> >>> template <typename Kind, typename Tuple> >>> struct user_expr : logical_not<user_expr> >>> { >>> static const boost::yap::expr_kind kind = Kind{}; >>> >>> Tuple elements; >>> }; >>> >> >> You certainly could. What does this buy, though? > > Being able to use `mp_assign` to change the parameters to `user_expr`. Although, you could write your own version which allows the first parameter to be an integral. > > Ok, but all of the above is still the "what". I want the "why". Why is it better to be able to use mp_assign? >> I'm not getting that >> part yet. One thing this give up is the inability to write functions in >> terms of chained >> >> constexpr if (kind == expr_kind::foo) >> >> statements, which I quite like. You can do this with is_same<> of course, >> but at the cost of 45 extra template instantiations and a lot more noise. > > That should still work. I dont see why it wouldn’t. In fact, you should be able to do all of these: > > template<boost::yap::expr_kind Kind> > using expr_kind_c = std::integral_constant<boost::yap::expr_kind, Kind>; > > constexpr if (kind == expr_kind_c<foo>{}) > constexpr if (Kind{} == expr_kind_c<foo>{}) > constexpr if (kind{} == expr_kind::foo) > > What may not work is doing something like `fit::if_(Kind{} == expr_kind_c<foo>{})`(due to lack of operator overloading for integral_constant), but using `fit::if_c<Kind{} == expr_kind_c<foo>{}>` still does work. > > Right, but all of that is noisier than what I currently have. Not really because `constexpr if (kind == expr_kind::foo)` will still work. > If there are advantages to using mp_assign, maybe this extra noise in a few places is worth it. I still have no idea what the mp_assign advantages are though. The point is to be able to get rid of `::` at the beginning in `BOOST_YAP_USER_UNARY_OPERATOR_MEMBER(logical_not, ::user_expr)`. If the user forgets those, you need to have a clear way to tell the user they need to add them, because it may not be obvious from the compiler error without understanding the implementation details. One way to solve this is to avoid it altogether by not passing a template, which you can try to utilize something like mp_assign. Another possible solution may be to add a static_assert with a message like “you are passing a type instead of template, you may need to prepend :: to the parameter to this macro". I think you can use function overloading to distinguish between a type and a template, but I am not sure. Paul

4 3

We need more mentors for GSoC
by David Bellot 14 Feb '18

14 Feb '18

Hi Boost community, we have already a few mentors, but we need more. If you're interested working with top-level C++ students from all around the world, please contact me and I'll add you to the list of mentors. We need more mentors now ! Best regards, David

2 2

[gsoc-18] enhancing boost.intrusive library
by Anurag Tangri 14 Feb '18

14 Feb '18

Hello Boost Community. My name is Anurag Tangri. I am a 3rd year student at Thapar university patiala. I have good knowledge of C++ programming knowledge because of my competitive programming background. I am interested in “Enhancing Boost.Intrusive Library” project so i am a looking for mentor to guide me.

2 1

Yap review extended until Feb 19th
by Louis Dionne 14 Feb '18

14 Feb '18

Dear Boost community, The review of Zach Laine's Yap library was supposed to conclude today, Wednesday February 14th. To give more people the chance to review the library, and since there's no review scheduled directly after Yap, the review period will be extended until (and including) Monday February 19th. Thanks, Louis Dionne

1 0

[gsoc-18]
by Anurag Tangri 14 Feb '18

14 Feb '18

Hello Boost community ! My name is Anurag Tangri. I am a 3rd year undergrad at Thapar University. I am very much familiar with C++14 because of my competitive programming background.I have decent knowledge of Data structures and algorithms and eagerly want to contribute in open source. I am new to open source and stuff. So it would be very helpful if someone could guide me.

1 0

[release] 1.67.0 deadline for new libraries approaching
by Daniel James 14 Feb '18

14 Feb '18

One week from today master will closed for new libraries and breaking changes. Thanks, -- The Boost Release Team

2 1

[release notes] Linking to github issues/pull requests
by Daniel James 14 Feb '18

14 Feb '18

Hi, I've added templates for linking to github issues and pull requests from the release notes. There are two templates: [github module number] which expands to '#number' [github_pr module number] which expands to 'PR#number'. Both will be linked, they need the name of the module to link to the right place. We only really need the issue template as github redirects to the pull request if appropriate, but existing release notes have been using the PR#3 format, so I thought it should support that. You can see an example in the unordered release notes for 1.67.0: https://github.com/boostorg/website/blob/master/feed/history/boost_1_67_0.q… http://www.boost.org/users/history/in_progress.html Does that look okay? Daniel

5 17

[yap] Review
by P F 14 Feb '18

14 Feb '18

- Whether you believe the library should be accepted into Boost I think it should be Accepted. - Your name Paul Fultz II - What is your evaluation of the library's: The design is very nice and simple to follow. I have found Proto to be a little hard for me to grep, but this seems fairly simple to follow. I think the transform -> evalute workflow is great. Also, with transforms being just function objects, it makes transformations very composable. I think this library is very useful. I would love to use this for some projects at work, but the dependency on Hana prevents that(I need to support gcc 5 and MSVC). Looking at the codebase, it could easily be replaced with Boost.Fit(once its included in the release) in the future. Of course, I dont expect a reimplementation without Hana as a condition for acceptance. However, I think Hana at least can be removed from the "interface". The expression elements could be expressed as a `std::tuple` and the placeholders could be a `std::integral_constant`. This should make it easier to use another backend without breaking API compatibility. Some other notes: - Couldn't the operator macros be provided as base classes? So instead of writing: template <boost::yap::expr_kind Kind, typename Tuple> struct user_expr { static const boost::yap::expr_kind kind = Kind; Tuple elements; // Member operator overloads for operator!(). BOOST_YAP_USER_UNARY_OPERATOR_MEMBER(logical_not, ::user_expr) }; The user could write: template <boost::yap::expr_kind Kind, typename Tuple> struct user_expr : logical_not<::user_expr> { static const boost::yap::expr_kind kind = Kind; Tuple elements; }; You could also get rid of the need for `::user_expr` by just taking it as a type and using something similiar to `mp_transform` to change the parameters. Or even change `Kind` to be a type of `std::integral_constant<boost::yap::expr_kind, Kind>` so `mp_transform` could be used directly: template <typename Kind, typename Tuple> struct user_expr : logical_not<user_expr> { static const boost::yap::expr_kind kind = Kind{}; Tuple elements; }; - The customization points seem unnecessary. Why wouldn't the user just use `transform`? Using `transform` also keeps the customizations local. Also, implicit transformations seems like it would lead to suprises(and not good suprises). Are those on the cutting block? - It would be interesting to provide common transformations, like common subexpression elimination, or dead code elimination, but I guess that is beyond the scope of this library. - The `op_string` function is missing the case for `expr_ref` and `terminal`. Also, the tests only check for plus. - The `make_expr_from_tuple` does a move here: auto make_expr_from_tuple (ExprTemplate<Kind, OldTuple> const & expr, NewTuple && tuple) { return ExprTemplate<Kind, NewTuple>{std::move(tuple)}; } But maybe this should be using `std::forward`? - Did you attempt to use the library? If so: Yes, I ran it on clang 3.8 and gcc 7. - How much effort did you put into your evaluation of the review? Several hours

3 8

Regarding how to get selected for gsoc boost
by Syed Souban 13 Feb '18

13 Feb '18

Hi! I am Syed Souban. I am new to the world of open source and I want to contribute to it. I am a Computer Science And Engineering Undergraduate and I know C, C++, Java, Android App Development, HTML, CSS, JavaScript, PHP. I want some guidance on how should I start preparing to get selected for GSoC in your organisation.

2 1

[system] virtual ~error_category
by Peter Dimov 12 Feb '18

12 Feb '18

The virtual destructor of error_category creates problems for constexpr-ification because it makes the class non-literal. I can't think of a scenario in which we need the destructor to be virtual. It's probably virtual for "guideline" reasons - the class has virtual functions. But does it really need to be? Error categories aren't destroyed via a pointer to base. They are, in fact, static instances, not destroyed at all, except on program exit. Can anyone think of a case in which error_category needs the virtual destructor?

7 16

Boost C++ is a mentoring organization for GSoC'18 !
by David Bellot 12 Feb '18

12 Feb '18

We just received this message from Google. It says it all ! *Congratulations! Boost C++ Libraries has been selected as a Google Summer of Code 2018 mentor organization.* This year again, we will be a mentoring organization for the Google Summer of Code. If you want to be a mentor, please contact me right now and register on the Google Summer of Code website too. Best regards, David

1 0

[yap] Review
by Fletcher, John P 12 Feb '18

12 Feb '18

I have quite a lot to say and I may not get it all down in one go. > - Whether you believe the library should be accepted into Boost Accept. > - Your name John Fletcher > - Your knowledge of the problem domain I have been working on codes doing similar things for a long time. I started with FC++ and have worked with Phoenix (I did some maintenance) and a lot of other codes. I have also worked with Hana around the time of that review. I tend to work by trying things out and extending the examples given, which is what I have been doing with YAP. I suppose you can categorize me as someone working at an intermediate level, attempting to make use of libraries to make results available to users at a higher level in a way which is intuitive. As I have worked in the past with the old C++ I particularly appreciate new codes which take advantage of C++14 to make this work easier. > You are strongly encouraged to also provide additional information: > - What is your evaluation of the library's: > * Design I like the design and have found this grow on me as I worked with the examples and saw how the pieces work together. I have found some of the recent discussion about why things are how they are very helpful. > * Implementation I have encountered quite a lot of the implementation as I have worked on the examples. I appreciate that this library makes extensive use of Boost Hana. There are some places in the examples where the user needs to have an understanding of Boost Hana to work. For example the transform example for arity uses Boost Hana maximum and transform. I will except boost::hana::tuple from the comment as it is used so much and is similar to std::tuple. One issue I have had is with the namespace. I am not clear why some code needs the full name e.g. boost::yap::evaluate and in other places evaluate will do without using being defined. It would be good if that was consistent. > * Documentation I don't think that the documentation at present does full justice to the code. There are several things which I found very useful which are not much mentioned in the code. When I saw that the examples were taken from work with proto I set out to make one which was missing, the mini_lambda example. I have had a lot of success with that while having to dig quite hard to find information. make_expression_function I have found this very useful in moveing to a functional approach. It is not much mentioned. I think what is needed is more examples and some contributions from users as to what help is needed to understand how to get the best use out of YAP. > * Tests I have already mentioned working on a version of the proto mini lambda. I have also built and example of the member call operator as the only example was in a more complicated example. I have also extended the vector example to add some cases which are missing e.g. 3. * v3 and v3 * v . I have made it use v3*v3 to return a scalar product. > * Usefulness I have found this to be useful from the examples. > - Did you attempt to use the library? If so: Yes > * Which compiler(s)? Mainly clang 4.0 C++14 with corresponding libc++. I have run some examples with gcc 7.1 C++14. This work is on ubuntu linux. > * What was the experience? Any problems? Problems encountered have been with my own understanding and wanting to explore the boundaries. > - How much effort did you put into your evaluation of the review? I have spent many hours spread over several weeks. I started before the start of the review. I hope this is helpful. Zach, thank you for your work and please ask if anything is not clear. Best wishes John Fletcher

2 1

[build] msvc-14 linker step failing?
by John Maddock 12 Feb '18

12 Feb '18

I have, and have had for some time: using msvc : 14.0 : "C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/bin/cl.exe" ; In my user-config.jam However, with current develop this leads to the linker step always failing: msvc.manifest ..\..\..\bin.v2\libs\config\test\config_info.test\msvc-14.0s11\debug\address-model-64\link-static\runtime-link-static\config_info.exe 'mt' is not recognized as an internal or external command, operable program or batch file. if exist "..\..\..\bin.v2\libs\config\test\config_info.test\msvc-14.0s11\debug\address-model-64\link-static\runtime-link-static\config_info.exe.manifest" ( call "..\..\..\bin.v2\standalone\msvc\msvc-14.0s11\address-model-64\architecture-x86\msvc-setup.bat" amd64 >nul mt -nologo -manifest "..\..\..\bin.v2\libs\config\test\config_info.test\msvc-14.0s11\debug\address-model-64\link-static\runtime-link-static\config_info.exe.manifest" "-outputresource:..\..\..\bin.v2\libs\config\test\config_info.test\msvc-14.0s11\debug\address-model-64\link-static\runtime-link-static\config_info.exe;1" ) As you can see no tool name is set on the start of the command line. Anyone any ideas? Thanks! John. --- This email has been checked for viruses by AVG. http://www.avg.com

5 14

[Heads up] PR adding guidelines for breaking changes on the website
by Louis Dionne 11 Feb '18

11 Feb '18

Folks, In early December 2017, there was a thread asking for guidelines regarding breaking changes: [1]. The conclusion reached in that thread seemed to be agreed upon [2] and I suggested making it part of the library guidelines. I have finally submitted a PR [3] to add it to the library _guidelines_ (not _requirements_). Feel free to take a look at the PR and chime in as this concerns everyone. Cheers, Louis [1]: https://lists.boost.org/Archives/boost/2017/12/240071.php [2]: https://lists.boost.org/Archives/boost/2017/12/240108.php [3]: https://github.com/boostorg/website/pull/300

4 3

Boost Python library suffix change
by Stefan Seefeld 09 Feb '18

09 Feb '18

Hello, I'm proposing a naming change that affects all libraries that use the `python.jam` build logic, i.e. Boost.Python, as well as libraries providing Python bindings (as far as I can tell, this is only Boost.MPI, but perhaps I'm missing some). At present, the Boost.Python build logic produces a library named "boost_python", if built with Python2, and "boost_python3", if built with Python3. I'd like to change that so the actual Python version suffix (e.g. "27" for Python 2.7) is being used. Not only would this simplify / unify naming conventions, it also allows users to collocate libraries compiled against multiple Python versions more easily. While I could apply this change to Boost.Python only, it seems more natural to patch Boost.Build itself, in which case any library whose build logic uses `python.jam` would also be concerned. Again, as far as I can tell, this only concerns the Boost.MPI Python bindings, but perhaps I'm missing some. So if you are concerned, please speak up, so we can discuss any necessary changes. Thanks, Stefan -- ...ich hab' noch einen Koffer in Berlin...

3 3

[review] Review of Outcome v2 (Fri-19-Jan to Sun-28-Jan, 2018)
by charleyb123 . 09 Feb '18

09 Feb '18

Hi, Everyone, The formal review of Niall Douglas' Outcome (v2) library begins Fri-19-Jan and continues until Sun-28-Jan, 2018. Your participation is encouraged, as the proposed library is uncoupled and focused, and reviewers do not need to be domain experts to appreciate the potential usefulness of the library and to propose improvements. Everyone needs (and has suffered) error handling, and can compose an opinion on that topic. Outcome is a header-only C++14 library providing expressive and very lightweight 'outcome<T>' and 'result<T>' error handling, suitable for low-latency code bases. The library further provides mechanisms for wrapping '<success|error|exception>' state to safely wrap throwing APIs; and poses an idiom of, "islands of exception in a sea of noexcept". Key features: *- Makes using 'std::error_code' from C++11's <system_error> more convenient and safe *- Good focus on low-latency (with tests and benchmarks) *- Error-handling algorithmic composition with-or-without C++ exceptions enabled *- Dependency only on Boost Recall a previous Outcome (v1) Boost Review occurred 19-May to 02-June 2017: *- Outcome (v1) Review Report: *- https://lists.boost.org/Archives/boost/2017/06/235783.php This review for Outcome (v2) includes significant changes as a result of feedback from the Outcome (v1) review. For a list of changes (v1==>v2), see: *- https://github.com/ned14/outcome#changes-since-v1 Reference API docs: *- https://ned14.github.io/outcome/reference/ GitHub: *- https://github.com/ned14/boost-outcome Tarball: *- https://github.com/ned14/boost-outcome/releases/tag/v2. 0-boost-peer-review Online "play-pen" (try it out!): *- https://wandbox.org/permlink/Ji1khzyxoAR0LJQC YOUR REVIEW --------------------- Please post your comments and review to the boost mailing list (preferably), or privately to the Review Manager (to me ;-). Here are some questions you might want to answer in your review: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? And most importantly: - Do you think the library should be accepted as a Boost library? For more information about Boost Formal Review Process, see: http://www.boost.org/community/reviews.html Thank you very much for your time and efforts. --charley Outcome (v2) Review Manager

24 122

Mailman upgrade
by Sys Admin - Boost 08 Feb '18

08 Feb '18

All, Per https://bugs.launchpad.net/mailman/+bug/1747209, Ciere staff will install 2.1.26 beginning 9-Feb-2018 04:00 UTC. While the maintenance is performed, incoming messages to the mailing lists for Boost will be temporarily blocked. This may result in “temporarily unable to deliver” messages received by senders if a message is delivered during the upgrade. The upgrade is expected to finish by 9-Feb-2018 05:00 UTC. Thanks, Brad Johnson Your Friendly Mailing List Admin

1 0

[review] Boost.Outcome.v2 Review Report
by charleyb123 . 08 Feb '18

08 Feb '18

# Boost.Outcome.v2 REVIEW REPORT In conclusion to the review for Boost.Outcome(v2) (19-Jan to 28-Jan, 2018): The library is ACCEPTED (conditions below). Acceptance is principally based on: (1) Reviewers found the library useful to address a current recognized need (2) New idioms are enabled that reviewers found compelling (3) The submission satisfies all Boost Library Requirements Concerns over accepting the library raised in the review discussion include: (a) New idioms proposed are not compelling (b) Requires C++14 (prefer compatibility with C++11) (c) Library may evolve beyond the current design (d) Library is unnecessarily complex Reviews submitted during the review period: *- Vinícius dos Santos Oliveira -- ACCEPT (Fri-26-Jan-2018) *- Andrzej Krzemienski -- ACCEPT (CONDITIONAL) (Fri-26-Jan-2018) *- Bjorn Reese -- ACCEPT (CONDITIONAL) (Sun-28-Jan-2018) *- Daniela Engart -- ACCEPT (Sun-28-Jan-2018) *- John P Fletcher -- ACCEPT (CONDITIONAL) (Sun-28-Jan-2018) In addition, after the review period concluded (but within the duration had the review period been extended) further reviews were submitted: *- Vinnie Falco -- REJECT (Tue-30-Jan-2018) *- Emil Dotchevski -- REJECT (Tue-30-Jan-2018) *- Glen Fernandes -- REJECT (Tue-30-Jan-2018) *- Paul A Bristow -- WOULD ACCEPT (?not a review?) (Wed-31-Jan-2018) *- Rob Stewart -- NOT ACCEPT (Sat-03-Feb-2018) Conditions for acceptance: It is expected: *- Changes are made to use Boost-standard names for macros and namespaces *- Docs are updated to be clear regarding: *- how library treats default-constructed values *- salient attributes of objects, and how “spare_storage” is treated *- Documentation is integrated into Boost framework and release process *- Library is distributed under the Boost Software License (BSL) The remainder of this report contains context and analysis contributing to this decision, including basis for why acceptance purports to be constructive and beneficial to the Boost community, and broader C++ community. # MOTIVATION: REAL-WORLD USE TODAY The prime motivation for acceptance is: *- Reviewers have real-world use cases _today_ for which they found Outcome to be an effective and best available alternative; and which is consistent with current-need and expectations; and which is consistent with ongoing C++ Standard evolution efforts. >From the Library Author: > <quote> > “Outcome is really an abstraction layer for setting per-namespace > rules for when to throw exceptions. Exception throwing is absolutely at > the heart of Outcome. That's why Outcome != Expected, and why it ICEs > older compilers, and why C++ 14 is needed.” Exhibited behavior is two-fold: (1) Expected errors are handled locally with low overhead (e.g., deterministic / predictable with low-latency) (2) Unexpected errors are type-erased into an 'exception_ptr' and pushed up the call stack (e.g., exception-throw stack-unwind) For example, server-side code that is expected to handle a lot of failures, where “stop-the-world” is never suitable, may always handle errors locally. In contrast, most other system-wide code may 'throw' an error, which should be handled within some caller-context. # AT ISSUE: DESIGN AND IDIOMS What appears to be debated in this review are the Outcome library design and idioms; and not the quality of implementation (although the implementation is criticized as complex -- see below). For example, even reviewers that voted to reject commented that the library seems sound, and seems useful for some cases. This merits repeating: This review has the highly positive characteristic (despite the accompanying discomfort) of debating the idioms that challenge what already exists, and which forces re-evaluation of our historical approaches. Many of these discussions might otherwise be summarized (and which has a fair chance of being agreed upon by all parties) as: *- Error handling can be done with exceptions, or with branch-testing on error instances; and some algorithms or constraints may favor one over the other for technical or compositional reasons. It is this highly pragmatic observation that is at the core of the Outcome library submission. Outcome enables a new idiom consistent with other pattern explorations deemed by the C++ community as useful, as demonstrated through acceptance into the C++ standard for 'std::optional<>' and the pending 'std::expected<>'. Outcome enables value-transport of a multi-modal data object '<T|error|exception>' across API boundaries that provides the benefit of static compile-time type-checking, but places the explicit burden upon the user for 'visit / interrogation' of that multi-modal data object. Outcome is intended for use in program areas with harsh resource constraints, where many inconveniences are expected, and tradeoffs are part of the design decision for creating and handling explicit 'out' values that include failure information. These constraints may include: interaction among one-or-more modules compiled without exception-handling enabled; deterministic or low-latency execution requirements; and use of custom 'error' and/or 'exception' objects that are expected to be populated and tested within the local context (such as to perform explicit conditional branching for error handling or recovery). During the review there was some confusion regarding evaluating Outcome in the context of “generalized use” across an entire codebase, versus “localized use” where the algorithm intends to machine specific cases for statically-bound stateful handling of errors. For example, it is not expected that Outcome might be used across all APIs across all modules within a system. (Recall that current C++ community guidance might otherwise suggest 'std::error_code' or 'exception-throw' might be used across all APIs for all modules within a system, if such consistency is permitted.) Rather, Outcome intends to address that nexus where an algorithm interacts with several modules, each with differing 'error' and 'exception' practices, where the library consistently transfers '<T|error|exception>' with compile-time type enforcement and runtime behavior and performance guarantees. Design decisions within Outcome v2 are well-considered, and faithfully reflect feedback raised during the (quite extensive) v1 review. Indeed, none of the issues raised during the v1 review were again raised within the v2 review. And, it is noted that two reviewers previously voting REJECT on v1 now vote ACCEPT on v2. Further, it should be noted that Outcome v2 has evolved into a collaborative effort with assistance from several contributors, with validation and feedback in multiple real-world codebases with specific engineering constraints. In this review, reviewers found the idioms specifically useful (beyond alternatively available tools / idioms), and consistent with practices in existing codebases and in other languages. Further, the proposed direction appears to be consistent with evolving idiomatic practice within the C++ Standard enabling new idiomatic algorithm expression, as evidenced by multi-mode types such as 'std::optional<>' and the (proposed and evolving) 'std::expected<>'. Idioms provided through Outcome are also demonstrated to be useful / successful in other languages. As noted in the review, Outcome enables handling of failure with idioms similar to those found in Rust, a language which also supports RAII but which does not support exceptions (and reviewers commented that these idioms are sufficiently successful that exceptions are not viewed as an interesting nor desired mechanism in Rust). One reviewer commented that it is not compelling to attempt to replicate Rust error handling idioms, which (as a different language) naturally offers different idioms. And instead, offered that the natural idiom in C++ is to throw (and catch) exceptions. However, it can be noted that the Outcome design approach is somewhat agnostic to the use of 'exceptions', but rather relies upon a multi-modal data object that the user must explicitly unpack (similar to 'std::optional<>' or 'std::expected<>'), and which makes explicit guarantees about unified transport and handling of '<error|exception>'. The core of the dispute seems to be over the value of localized reasoning for handling errors: Exceptions are good for “distant” handling (to seamlessly transfer handling to a parent context), while explicit error/result instances (possibly customized) encourage local reasoning for discrete handling within the local algorithm context. Complicating the issue is that (of course) both are accepted practice in differing environments and with differing engineering constraints: Throwing exceptions may be most expressive to avoid algorithmic edge cases or ensure errors are actually handled; but alternatively it may be more expressive to explicitly handle errors locally when it is not desirable to delegate the failure to an upper level. # DISAGREEMENT: ERROR / EXCEPTION HANDLING Even prior to considering the Outcome library submission, error handling idioms and practices remain contentious and confusing within the C++ community (as well as within the Boost community). Recent threads on the Boost email-list continue to highlight the ongoing confusion and disagreement even over the proper or idiomatic use of 'std::error_code', which boasts a decade of real-world experience and approaches a decade in the C++standard. One might think such discussions should by now be resolved; but no, we observe that even semantic agreement of proper-or-intended behavior for 'std::error_code' was not reached on these recent Boost email discussions. We also observe that discussion regarding 'error' or 'exception' handling can at times be clouded within the evolving C++ Standard itself, with discussions of 'throw'/'no-throw' (e.g., “dual”) APIs, semantics for 'wide' or 'narrow' contracts, and even the occasional (and “over-simplified”) discussion of “for vs. against” exception handling (a topic that alone is worthy of consuming a surprising number of evenings and libations). The Library Author can be congratulated (or scolded) for exploring work or attempting Boost community review in such a contentious space. However, these topics are also fundamental motivations in the creation of Outcome itself: It provides a mechanism to unify 'error' _and_ 'exception' handling to enable unified localized reasoning across third-party modules; and directly exposes the resulting issues for cross-module error handling by charging the user with explicit unpacking of the '<T|error|exception>' object, but with the benefit of static binding (e.g., compile-time type checking). The implication is that in such a library review attempting to address a portion of the C++ landscape already marked with disagreement regarding current-and-alternative approaches, we cannot expect but to see charged commentary where issues of “global reasoning” over a “generalized use case” were inevitably raised to sometimes overshadow the discussion of a library that specifically intends to address “localized reasoning” with specific performance constraints and behavior guarantees. (Although compared to the v1 review, we might consider some threads to have missed opportunity to be yet more colorful.) The beclouded discussion appeared at times to exhibit violent agreement: Quoting reviewer (voting to reject): > However it looks like Outcome provides a solution for most of the practical > cases, while leaving the general case unsolved. Boost.Outcome is a set of > tools (rather than just one) and you are expected to choose one that best > solves your particular problem. Quoting response by library author: > I was just about to say the same thing, but more pointed. <...> Knowing that > a piece of code will never, ever see stack unwinding lets you skip handling > stack unwinding. Hence `noexcept`. > > Furthermore, unlike with exception specifications which were unhelpfully checked > at runtime, Outcome fails at compile time. .... You can't successfully compile code > if your E types don't have interop specified for them. > > Outcome is of particular use in a lower-level layer of code (closer to bare metal, > or in server contexts), where explicit deterministic error handling warrants > increased tedium or inconvenience in explicit checks for success/failure. An observer might note that the reviewer (voting to reject) and library author have a shared view of what the library proposes to do; but the reviewer desires a generalized solution, rather than an interop-solution that provides specific performance constraints and behavioral guarantees. They agree on what it does. They disagree regarding the value and likelihood of a future possible generalized solution to perform a similar function, which is not currently proposed for review. The (perhaps unstated) concept is that no generalized solution may be possible with today's language, or perhaps ever: Both 'error' objects and 'exception' throws fundamentally serve different use cases: (a) 'error / status' instance (i.e., “opt-in”): A discrete object that can be inspected (or ignored), such as to perform conditional processing (b) 'exception' throw (i.e., “opt-out”): A control transfer-to-caller that avoids accidental instruction execution (e.g., stack-unwind) and which cannot be ignored Proponents of (a) talk of contract and execution simplicity, and of determinism / efficiency. Proponents of (b) talk of composition simplicity, and avoidance of edge cases due to liberation from local tedium. A further complication is due to how arbitrary (implementation-specific) data is returned for failure handling: It can be encoded into the type system (increasing coupling across APIs), or may be type-erased (such as done by 'std::error_code'). Noted in the review is that 'exception' throws are a special case of type erasure, as the C++ runtime performs the type erasure without impacting the declared API (thus providing a very large part of the convenience for using exceptions). The Outcome library attempts to unify '<error|exception>' handling for localized reasoning, and (re-)throw only in specific well-defined contexts. It is not a generalized pattern, but a unified mechanism for discrete handling of those scenarios where the design choice is explicitly made to perform localized reasoning of failure from dependence upon heterogeneous modules that may perform surprising (and evolving) behavioral changes for failure-notification. A generalized solution intends to provide uniformly simpler code, or generalized idioms. This might not (ever) be possible when we explicitly talk about localized reasoning of error handling within the local context: By definition, we want to enumerate and handle discrete failure cases specific to the local algorithm; so the best we can do is to utilize (compile-time) type-checks that verify our unwrapping-and-interrogation of our '<T|error|exception>' instance that bubbles up from within some far-away dependency that chooses the most inopportune time to exhibit surprising changes in behavior. Also by definition, localized reasoning requires localized tedium to _handle_ specific error cases, which are also enumerated locally. In such cases, a generalized solution does not apply. Much of the concern over Outcome acceptance appears to be based on concerns of the effects of the library on the ecosystem. It is true that users might wrongly apply localized reasoning tools to (widespread) generalized use. However, that same issue already exists with the C++ community's dichotomous split between 'error' or 'exception' handling, and with our Groundhog-Day revisiting of the same irreconcilable patterns that bring us the “dual-APIs” for “throw/no-throw” in the C++ Networking TS and Filesystem TS (and presumedly, many more Standard libraries to come). Of particular note is the assertion raised during the review that: *- The error being exceptional or not depends upon context, and not the algorithm. For example, connection failure on a game client and a game server are both backed by the same function; but Outcome permits the context to convert an 'error' into an 'exception', or not (based on caller-context). To quote one reviewer (voting to accept): > Boost.Outcome is not to “replace exception handling in your programs”: It is > used to cover those isolated places where exception handling proves inferior > to manual control flows. We might now expand our Matrix Of Confusion for preferring 'error' or 'exception' to include: (a) “Generalized-pattern” vs. “Localized-reasoning” (b) Expected vs. Non-Expected failure (c) Dependency upon subsystem providing 'error' vs. subsystem providing 'exception' While technically a “matrix”, commonly this is (quite) multi-dimensional: Frequently we depend upon many subsystems, each of which make very different decisions for how they relay disappointment, and where each individual subsystem will *change* that decision in surprising ways merely when we perform a version update. This is the brittleness that Outcome intends to address. Outcome is merely a mechanism to enable 3rd party module inter-operation. It does not make the decision for whether 'error' or 'exception' instances are provided by some subsystem, nor does it care. Rather, it is a unification mechanism that enables an algorithm to be _authored_ with specific performance and behavioral guarantees when reliance is upon one-or-more modules that _made_ that 'error' vs. 'exception' decision in a manner your specific use case finds unfortunate. Lastly, reviewers most critical of Outcome point to 'exceptions' as the C++ language mechanism to be leveraged in design, such as to enforce strong guarantees of object invariants (e.g., RAII permits ctors to throw to ensure invariants are not violated), and thus the Outcome library is not needed. However, despite this language feature, alternative idioms such as private ctors and 'make_xxx()' factory functions are not uncommon to also enable successful instantiation with internal state upholding invariant values; and we again must concede that modules employ differing decisions to compile with exception handling enabled. Thus, it seems reasonable that a library such as Outcome might exist to present a unifying interface across 3rd party code with differing design decisions, rather than hope for a simpler world where a single (exception-based) approach is mandated system-wide across modules. # CONCERN: CUSTOMIZATION POINTS (COMPLEXITY) Outcome attempts to bridge vocabulary types for '<error|exception>' handling among subsystems, including: C++ with or without exceptions enabled, C subsystems, and modules providing customized errors and/or customized exceptions. These goals necessarily complicate the design beyond a simple 'variant<>' value-type with no such customization points. This complexity was commented on by reviewers that voted to reject, suggesting: (1) Complexity is too high for the features provided; (2) Additional complexity to support C compatibility is unnecessary; and (3) Complexity is unnecessary if the library required subsystems not using exceptions to be wrapped behind a C-style API and to compile only those wrapped-subsystems with exception handling disabled. Further, other indirect comments suggested: (4) Complexity is lessened if Outcome assumed use of only 'std::error_code' (not user-customized error instances), and the type-erased payload provided through an exception (e.g., 'throw'). In response, the Outcome library premise is that a simpler world does not exist (where such customization is unnecessary): Despite nearly a decade of experience, the C++ community has yet to adopt 'std::error_code' as the ubiquitous mechanism to identify error (where instead bespoke error types remain in widespread use); and even in modern C++ codebases, it is not uncommon to compile with exceptions disabled. A heterogeneous landscape exists, and likely will continue to exist. For both practical and technical reasons, it is expected that domain-specific customization for error and exception handling will continue to be required, such as to address engineering constraints and needs for 'constexpr'; for small-embedded environments with severe restrictions on memory allocation; and for context-specific payload transferred or accumulated into journals / logs as a part of error handling. It is even expected that the C++ Standard itself will adapt to its own evolving idioms exposed through new language features, and (future) standard types that we might assume will be consistently applied across standard library APIs. This underscores the need for such customization points, where proposals such as Outcome attempt to provide an effective mechanism within a rather bleak current landscape with guaranteed future changes. In the face of this (currently-seen and continually expected) evolution, we have today's practical real-world issues: Commonly today's systems are composed of 3rd party modules that must interoperate in a well-behaved and deterministic manner, where '<error|exception>' customization becomes a system requirement. Of particular note is that in large codebase environments, current practice is to adopt customization policies to impose consistent and bespoke rules across the entire codebase, and across modules. Prior to Outcome, this customization is often done with preprocessor macros. In these environments, Outcome is viewed as a positive evolution. Today's Outcome customization points exist “out-of-the-box” to be compatible with existing module-specific 'error' or 'exception' needs, and to provide API/source-compatibility with a possible future-compatible 'std2::error_code'. Reviewers critical of the provided customization points want type-erased error state, but the library author asserts that this is hard to do in a manner that is (1) efficient, and (2) permits evolution (such as to support user-specific error values, or a possible future 'std2::error_code'). Further, the library author asserts that the library is not in fact complex; but that it can be overwhelming to the uninitiated merely because it enables customization of '<E>', and customization enables possibilities (which by definition implies complexity); and that such customization is characteristic of most (all?) vocabulary libraries. Despite concerns over complexity, v2 is greatly simplified over v1 where changes were directed through v1 review feedback; and provides a single-header version with reasonable compile-time overhead. Using (integrating) the library should not be difficult, and explicit efforts to establish ABI stability should make extended use over evolving codebases possible, and not-hard. Because enabling cross-module '<error|exception>' handling is fundamental to the library, it is conceivable that the library offers the minimal interface with the minimal possible complexity to do this job. And, this is a job that is (1) needed by real-world users; and (2) unavailable through alternative mechanisms (and which would not be provided through a simplified value-type composed of 'variant<T,error,exception>'). >From the library author: > As the last section of the tutorial covers, there is a non-source-intrusive mechanism > for externally specifying interoperation rules to handle libraries using one policy > interoperating with libraries with different policies. This lets Eve stitch together the > Alice and Bob libraries without having to modify their source code, and without > affecting any other libraries. I personally think this Outcome's coup de grace and > why it's the only scalable choice for large programs considering using this sort of > error handling. In this context where Outcome may possibly exhibit minimal sufficient complexity to address its intended target of cross-module '<error|exception>' transport, one might recall the Fred Brooks quote: > “The complexity of software is an essential property, not an accidental one. > Hence, descriptions of a software entity that abstract away its complexity > often abstracts away its essence.” -- Fred Brooks, “No Silver Bullet” (1986) # DISAGREEMENT: REQUIRES C++14 (versus C++11) Outcome requires C++14 and is identified as failing on some toolchains exhibiting non-conforming C++ Standard behavior. The review raised concerns that requiring C++14 (rather than C++11) would limit the library's suitability for Boost inclusion. In this context, it might be suggested that an error variant is needed by everyone, so we might reject a C++14 implementation in the hope that a future C++11 compatible library will be proposed. It is noted that Outcome v1 supported old compilers back to clang 3.1 and gcc 4.9, and had many workarounds to suppress non-conforming compiler behavior; and used preprocessor metaprogramming to work around compile-time selected CRTP (because of compile-time costs, and issues on older compilers). However, these approaches were rejected in the v1 review as too complex; and reviewers were not persuaded by concerns raised by the library author that their removal would demand dropping compatibility with older toolchains. Outcome v2 removed these workarounds based on v1 feedback, resulting in a requirement for newer toolchains. Similar discussions have been raised in other contexts regarding Boost distribution packaging, and the possibility of forking “pre/post” C++11 (e.g., “modern C++”) libraries into separate Boost distributions. This is an unfortunately complex issue, as Boost already contains libraries supporting varying levels of “minimum” requirements including varying support for compilers exhibiting non-conforming behavior for C++98, C++03, C++11, C++14, and C++17 (and others). Some libraries such as Boost.Hana or those reliant upon heavy 'constexpr' behavior demand the very-latest C++17 toolchains. Further, it is recognized that in some cases backward-compatibility can be undesirable, or fundamentally limiting to the library's usefulness. For example, at a recent 'BoostCon' / 'C++Now' conference an attempt was made to evolve the 'Boost.Date_Time' API to use the seemingly highly suitable C++17 'structured binding' declaration to decompose 'date / time' objects. Unfortunately, this work was abandoned: Due to use by other Boost libraries restricted to a previous C++ Standard, and the discovery that 'Boost.Date_Time' library semantics fundamentally changed when using this new language feature, it was concluded to not be feasible to support both the legacy API and new API using structured bindings. It appears in this case a new library must be authored without consideration of backward-compatibility to enable this evolution for what appears to be an otherwise obvious or natural expressiveness to decompose 'date / time' objects using 'structured binding' declarations. It is noted that C++11 is already eclipsed by C++14 and C++17, and that current Boost library requirements merely require C++ Standard conforming behavior, whereby the library must clearly document those platforms that are supported. Further, it is noted that a v1 implementation supporting older tool chains was rejected (so v2 now requires C++14). As this is a complex issue that demands consideration of many tradeoffs (including feasibility and behavior fundamental to the library itself), it is expected that the Library Maintainer constantly review and evolve these decisions as the C++ language evolves; toolchains are updated; and users raise issues or provide contributions. # CONCERN: LIBRARY FUTURE EVOLUTION A concern is raised that upon acceptance into Boost, Outcome may evolve beyond the design reviewed for acceptance. Further, a specific concern was raised regarding Outcome exploring evolution of an 'std::error_code' (which we might call a proposed 'std2::error_code'). Within the context of Outcome, the 'error' type exists as a mere customization point by which the user may supply a bespoke definition, or incidentally use the 'std::error_code' provided by the C++11 Standard. Both of these are seen today in common practice. It is expected that users (and perhaps the library author) will continue to explore possible 'error' implementations for specific purposes (such as exploration of an 'error' for small-embedded that does not rely upon allocation machinery). This is viewed as a necessary and healthy advancement of the science, for which the library (by design) conveniently empowers the end-user to parameterize domain-specific 'error' types into 'result<>' or 'outcome<>'. Indeed, it is hoped (and expected) that a greater amount of user-experimentation or flirtation with 'error' value transfer will be performed (not less) in the context of user-specific needs or engineering constraints: This is a fundamental benefit from having Outcome as a design option for authoring interfaces across module boundaries. Regarding a possible future “drift” from its clearly-stated mission, this review considers the library as submitted; and defers to the Boost community regarding policies and procedures for handling libraries included in the Boost distribution (which exist in varying states of evolution and maintenance). # FINAL THOUGHTS The Boost community is stronger for enabling and exploring idioms, and for not shying away from the difficult (and sometimes contentious) effort to discover new approaches that address the dark corners that stress our real-world systems. These are (perhaps) the only noble efforts that someday may lead to new best practices. If experience (otherwise known as, “painful memory of limitation”) is a prime driver for the design and implementation choices made by developers, then it is unreasonable in a review such as this to expect agreement on all fronts. Indeed, our systems have differing constraints and evolutionary / scaling prospects, and we fear different things. However, it seems important to keep in mind that this disagreement continues to be necessary and expected: Rather than pretending to hide within an echo chamber, the Boost Community does the “hard work” of challenging perspectives, pushing the envelope, and questioning assertions in the face of a constantly shifting technological landscape and evolving C++ language. Dissenting or critical reviews are essential, and desired. The long Boost history includes many examples of speculative and risky approaches, which in hindsight are now considered common and "best" practice. Few C++ developers today can practice professionally without at least passing knowledge of template-metaprogramming, which used to be an esoteric ritual only within the confines of Boost. Outcome was designed under the proposition that cross-module 'error' / 'exception' handling in today's systems is unnecessarily brittle and problematic. Reviewers found Outcome to effectively address a serious concern of transporting different '<error|exception>' instances across modules. It attempts to solve a hard problem, which spans 3rd-party module composition, while adhering to specific performance constraints and behavioral guarantees. Its use is demonstrated to be effective in some environments exhibiting severe engineering restrictions. As such, it is not expected that all users everywhere will have direct need for Outcome. However, it is hoped that evolution of similar idioms will eventually permit the broader C++ community to consider this domain of cross-module stateful control transfer to be a “solved problem” (or certainly “less-brittle” or “less-problematic”). Great thanks to the Boost Community for their tremendous efforts, disciplined review, and detailed exploration of topics in considering this library submission. Sincerest appreciation to Niall Douglas (Author of the Outcome Library) and other contributors for pushing the boundary for '<error|exception>' handling and for submitting this work to the Boost Review process. --charley Boost.Outcome (v2) Review Manager

8 8

Fwd: Changes to __PRETTY_FUNCTION__ in clang
by Mikhail Ramalho 05 Feb '18

05 Feb '18

Hi all, I recently send an email to the clang mailing list, to change how clang prints __PRETTY_FUNCTION__ [0], and one person raised a question if it would break boost. Honestly, I don't know boost's code and I could only find a few places where it's used, mainly for diagnostics, but also in CTTI and hanna; that's why I'm sending this email to ask for some help. Does boost relies on the format of these macros? The main idea is to just change how templates are printed, from: X<void>::X() [T = void] to a gcc-like style: X<T>::X() [with T = void] Thank you, [0] http://lists.llvm.org/pipermail/cfe-dev/2018-February/056766.html -- Mikhail Ramalho.

2 1

[gsoc18][boost.intrusive]
by Rishabh Arora 05 Feb '18

05 Feb '18

Hello Boost Community, I have proposed a project as a mentor for Google Summer of Code '18, as a new addition to the Boost.Intrusive library. The details about the project proposal and the competency test can be found here: https://github.com/ boostorg/boost/wiki/Boost-Google-Summer-of-Code-2018 (Project-5). All the interested candidates can contact me and send me their competency test on the following e-mail: rishabharora1997(a)gmail.com Best Regards, Rishabh

2 1

Re: [boost] [CppCMS] What can be contributed to Boost?
by Bjorn Reese 04 Feb '18

04 Feb '18

On 02/02/18 19:30, Artyom Beilis via Boost wrote: > Once I can think of is cppcms::json > > http://cppcms.com/wikipp/en/page/cppcms_1x_json > http://cppcms.com/cppcms_ref/latest/classcppcms_1_1json_1_1value.html > > Also it should be updated to C++11 and probably do some small features > updates. it is one of the fastest JSON parsers around (and yes it is > way faster and convenient than one in property tree) > > What do you think? If the Boost community wants a JSON library, then I would like to suggest another, more versatile ibrary: https://github.com/breese/trial.protocol Documentation can be found here: http://breese.github.io/trial/protocol/ This library consists of two (well, three) parts: 1. A dynamic variable which is a variant type that can contain fundamental types, arrays, and associative arrays. This can be used as a parse tree for JSON and similar binary formats like MsgPack, UBJSON, BinToken, and CBOR. But it can also be used as a data container for, say, configuration data. The dynamic variable has iterators so it works with std algorithms. It also comes with a visitor. 2. A JSON parser/generator framework. This contains an incremental pull parser (json::reader) as the basic building-block. The incremental parser is used by a Boost.Serialization archive to enable serialization directly between JSON and C++ data structures. The incremental parser is also used by a tree parser that converts JSON into the before-mentioned dynamic variable. 3. A BinToken parser/generator framework. Like the JSON framework, but for the binary BinToken format. Currently undocumented.

1 0

[CppCMS] What can be contributed to Boost?
by Artyom Beilis 02 Feb '18

02 Feb '18

Hello Dear Boost Developers, Recently I had released CppCMS - C++ Web Framework 1.2 under MIT license instead of LGPLv3 See: http://cppcms.com Since CppCMS project had already contributed some of its parts for Boost: Boost.Locale - in Boost for long time Boost.Nowide (passed review still need some my time to integrate to release) I wanted to renew the discussions of what parts may interest the community Boost outside CppCMS. Some samples I thought of: -------------------------------------------- Once I can think of is cppcms::json http://cppcms.com/wikipp/en/page/cppcms_1x_json http://cppcms.com/cppcms_ref/latest/classcppcms_1_1json_1_1value.html Also it should be updated to C++11 and probably do some small features updates. it is one of the fastest JSON parsers around (and yes it is way faster and convenient than one in property tree) What do you think? -------------------------------------- Another one that was already discussed once is CppDB: http://cppcms.com/sql/cppdb/ It also needs C++11 updates in general and is already under dual Boost/MIT License. It was discussed before but nothing moved further. ---------------------------------- Some smart pointers I find very useful especially for Pimpl implementation: hold_ptr -> similar to scope ptr but object constness is same as the pointer copy_ptr-> copies underlying object upon copy (very useful for pimpl) clone_ptr->clones objects. Regards, Artyom Beilis

2 1

[serialization] uuid test_serialization ubsan error
by James E. King, III 01 Feb '18

01 Feb '18

I'm getting a ubsan test error in uuid/test/test_serialization - is the code in that test using archive the right way? testing.capture-output ../../../bin.v2/libs/uuid/test/test_serialization.test/gcc-7/debug/link-static/threadapi-pthread/test_serialization.run ====== BEGIN OUTPUT ====== ../../../boost/archive/detail/interface_oarchive.hpp:47:16: runtime error: downcast of address 0x7ffca0c6fe30 which does not point to an object of type 'text_oarchive' 0x7ffca0c6fe30: note: object is of type 'boost::archive::text_oarchive_impl<boost::archive::text_oarchive>' 00 00 00 00 e0 2f 78 8f 48 56 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ^~~~~~~~~~~~~~~~~~~~~~~ vptr for 'boost::archive::text_oarchive_impl<boost::archive::text_oarchive>' EXIT STATUS: 1 ====== END OUTPUT ====== Thanks, Jim

3 3

Re: [boost] [review] Review of Outcome v2 (Fri-19-Jan to Sun-28-Jan, 2018)
by Andrzej Krzemienski 01 Feb '18

01 Feb '18

2018-02-01 19:13 GMT+01:00 Emil Dotchevski <emildotchevski(a)gmail.com>: > On Thu, Feb 1, 2018 at 2:51 AM, Andrzej Krzemienski <akrzemi1(a)gmail.com> > wrote: > >> Boost.Outcome solves the problem decently: you get a compiler error or a >> compiler warning >> > > Do you? What if you have: > > result<void> foo(); > > void bar() > { > foo(); > } > > What compile error will that generate? > "ignoring returned value of type 'outcome_v2_f1696316::result<void>', declared with attribute nodiscard [-Werror=unused-result]" online example: https://wandbox.org/permlink/5vICxckvVG6QO0n1 > Now, in Boost.Noexcept, if the programmer forgets to test for the failure >> (with `try_`), the subsequent function is still executed with the default >> value of type `T` returned from the funciton that failed. Because in >> Boost.Noexcept when function fails it returns a default-constructed `T`. >> > > The idea in Noexcept is that since the function _must_ return something if > there is an error, it returns throw_return<T>() but that is not automatic; > the user still has to say e.g. return throw_(error()). > I understand the constraints you are under. I also acknowledge that this is the best one can do. Nonetheless, I still see the limitation of the solution. If a third party function is returning a type representing a resource, and this type does not provide a default constructor, there is no way to "throw_". You cannot even customize `throw_return<T>()` because what value would you return? You are reporting failure because you cannot acquire the resource. And because it is a third-party interface, you cannot adapt the type. So, in the end, there will be functions where you cannot apply Boost.Noexcept. > > >> And when you check it systematically it is all ok, but then you forget >> (and this is a tedious task), you violate the contracts. No compile-time >> check, no run-time check. >> > > In Noexcept there _is_ run-time check: if noexcept_::has_current_error() > is true at the time a thread terminates, it invokes std::terminate(). Not > ideal, and won't take action if the thread never terminates -- and it may > never terminate because, like in Outcome, if the caller doesn't check at > every function call, the program keeps going. > I was imprecise. you do have a run-time check, but it comes too late: it does not prevent functions to be called with failed preconditions. > > >> I consider this a serious issue. >> > > It is, programmers forget to check for errors all the time. > And Boost.Outcome helps detect these situations at compile-time (of course, at the expense of controlling the return type). > >> And taking into consideration the advantages of Boost.Noexcept you >> mention, I can only conclude that Boost.Noexcept is superior to >> Boost.Outcome in one aspect but inferior in another. >> > > The two libraries solve different problems. > Indeed. > Outcome helps you avoiding exception handling, so it assumes you can > freely use result<T,E> throughout your interfaces. > Well, it can help you avoid exceptions. But it also helps you deal with the lack of exception handling. As you say, the trade-off is that you use `result` in return type. > Noexcept helps you deal with a lack of exception handling, so it assumes > that at least some of the interfaces are beyond your control, and doesn't > impose a return type. > Yes, here the trade-off is, no altering of the return type, but unsafe consequences when you forget to check for "thrown" exceptions. And there must exist a "spare" value in the returned type. There are benefits to using a special return type (to protect against using > an invalid value), but Noexcept leaves that to the user because return > values don't transport errors, just the T; you could e.g. use > std::optional<T>. > And user may not be able to make this decision because he may not be in control of the return type. Regards, &rzej;

1 0

[GSOC18] Boost.Geometry Project 1 : Similarity between geometries
by sagarvijaygupta 31 Jan '18

31 Jan '18

I am Sagar Gupta, a student of IIT Mandi, pursuing my Bachelors in Computer Science. I want to work on the Project 1 of Similarity between Geometries. I read the source code of geometry and regarding the Frechet distance and its different variations and tried to work with it. Also I tried the competency test. Its my first time for GSOC but I have some good experience in C++ (from different projects and competitive programming). I wish to know where should I send the competency test? I wish to work on this project as it is a great learning experience which I realized while working on the implementation of Frechet Distance between linestrings. Thanks and Regards Sagar Gupta -- Sent from: http://boost.2283326.n4.nabble.com/Boost-Dev-f2600599.html

2 2

International Conference on Information Society (i-Society 2018): Call for Submissions!
by International Conference on Information Society 30 Jan '18

30 Jan '18

Apologies for cross-postings. Please send it to interested colleagues and students. Thanks! Call for Submissions! ********************************************************************************** International Conference on Information Society (i-Society 2018) 15-18 July, 2018 Venue: Ballsbridge Hotel Dublin, Ireland www.i-society.eu ********************************************************************************* The i-Society is a global knowledge-enriched collaborative effort that has its roots from both academia and industry. The conference covers a wide spectrum of topics that relate to information society, which includes technical and non-technical research areas. The mission of i-Society 2018 conference is to provide opportunities for collaboration of professionals and researchers to share existing and generate new knowledge in the field of information society. The conference encapsulates the concept of interdisciplinary science that studies the societal and technological dimensions of knowledge evolution in digital society. The i-Society bridges the gap between academia and industry with regards to research collaboration and awareness of current development in secure information management in the digital society. The topics in i-Society 2018 include but are not confined to the following areas: *New enabling technologies - Internet technologies - Internet of Things (IoT) - Wireless applications - Mobile Applications - Cloud and iCloud - Multimedia Applications - Protocols and Standards - Ubiquitous Computing - Virtual Reality - Human Computer Interaction - Geographic information systems - e-Manufacturing - Electronic Discovery (eDiscovery) - Software Applications - Disruptive Technology *Intelligent data management - Intelligent Agents - Intelligent Systems - Intelligent Organisations - Content Development - Data Mining - Data Management Software - e-Publishing and Digital Libraries - Information Search and Retrieval - Knowledge Management - e-Intelligence - Compliance and Recovery from Data Loss - Knowledge networks - Risk Mitigation - Cost Efficiency - Quality Assurance - Information Management - Support Litigation - Complex Investigations *Secure Technologies - Internet security - Web services and performance - Secure transactions - Cryptography - Payment systems - Secure Protocols - e-Privacy - e-Trust - e-Risk - Cyber Security Investigations and Defence - Cyber law - Forensics - Information assurance - Mobile social networks - Peer-to-peer social networks - Sensor networks and social sensing - Information Security Compliance *e-Learning - Collaborative Learning - Curriculum Content Design and Development - Delivery Systems and Environments - Educational Systems Design - e-Learning Organisational Issues - Evaluation and Assessment - Virtual Learning Environments and Issues - Web-based Learning Communities - e-Learning Tools - e-Education *e-Society - Global Trends - Social Inclusion - Intellectual Property Rights - Social Infonomics - Computer-Mediated Communication - Social and Organisational Aspects - Globalisation and developmental IT - Social Software - Smart City *e-Health - Data Security Issues - e-Health Policy and Practice - e-Healthcare Strategies and Provision - Medical Research Ethics - Patient Privacy and Confidentiality - e-Medicine *e-Governance - Democracy and the Citizen - e-Administration - Policy Issues - Virtual Communities *e-Business - Digital Economies - Knowledge economy - eProcurement - National and International Economies - e-Business Ontologies and Models - Digital Goods and Services - e-Commerce Application Fields - e-Commerce Economics - e-Commerce Services - Electronic Service Delivery - e-Marketing - Gig Economy - Online Auctions and Technologies - Virtual Organisations - Teleworking - Applied e-Business - Electronic Data Interchange (EDI) - Innovative Strategies - Business Intelligence - Information Intelligence - Forensic Accounting *e-Art - Legal Issues - Patents - Enabling technologies and tools *e-Science - Natural sciences in digital society - Biometrics - Bioinformatics - Collaborative research *Industrial developments - Trends in learning - Applied research - Cutting-edge technologies - Industrial Control Systems - Communications Compliance * Research in progress - Ongoing research from undergraduates, graduates/postgraduates and professionals SUBMISSION INSTRUCTIONS: * You can submit your abstract, extended abstract or paper online at http://www.i-society.eu/paper-submission/ or email it to papers(a)i-society.eu * You can submit your speaker's proposal via email at speakers(a)i-society.eu or online at http://www.i-society.eu/format/speakers-participation/ * You can submit your poster via email at posters(a)i-society.eu * You can submit your workshop or tutorial proposal via email at workshop(a)i-society.eu or tutorial(a)i-society.eu * You can submit your panel discussion via email at pandis(a)i-society.eu IMPORTANT DATES: *Abstract Submission Date: February 10, 2018 *Notification of Abstract Acceptance / Rejection: February 17, 2018 *Extended Abstract (Work in Progress) Submission Date: February 20, 2018 *Notification of Extended Abstract Acceptance / Rejection: February 27, 2018 *Research Paper Submission Date: March 01, 2018 *Notification of Research Paper Acceptance / Rejection: March 12, 2018 *Camera Ready Paper Due: May 01, 2018 *Proposal for Workshops / Tutorials: February 25, 2018 *Notification of Workshop/Tutorials Acceptance / Rejection: March 01, 2018 *Poster / Demo Proposal Submission: March 01, 2018 *Notification of Poster / Demo Acceptance: March 12, 2018 *Early Bird Registration Deadline (Authors and Participants): April 15, 2018 *Late Bird Registration Deadline (Authors only): May 15, 2018 *Late Bird Registration Deadline (Participants only): May 30, 2018 *Conference Dates: July 15-18, 2018 For more details, please visit www.i-society.euIf you wish to unsubscribe from our newsletter, click http://r.confinfosoc.org/scyaulavbnjg.html

1 0

Interested in applying to the google summer of code
by Laouen Belloli 30 Jan '18

30 Jan '18

Hi, My name is Laouen Belloli, I'm a Computer Science student at Universidad de Buenos Aires currently doing my final thesis in Discrete Events Simulation, this is my 7th and last year on it. In the past I contributed to the cadmium project. This year, I want to join the google summer of code to contribute to Boost. In particular, I would like to work on the Boost.Real project proposed. Best regards, -- Laouen Mayal Louan Belloli. LIAA - DC - FCEyN - UBA. C.A.B.A. - Buenos Aires - Argentina. https://liaa.dc.uba.ar +54 9 11 38675694

2 2

[atomic] (op)_and_test naming
by Andrey Semashev 30 Jan '18

30 Jan '18

Hi, I would like to ask for the community opinion on the naming of the (op)_and_test functions that appeared in Boost.Atomic 1.66. As you probably know, 1.66 included a few new atomic operations, some of which have the name (op)_and_test (e.g. add_and_test, sub_and_test, etc.) These operations perform the (op) on the atomic value and test if the result is zero, so that instead of this: if (a.fetch_sub(1) - 1 == 0) one could write this: if (a.sub_and_test(1)) Also, the generated code for these operations can potentially be more efficient. Recently I received this request: https://github.com/boostorg/atomic/issues/11 which basically asks to change the result of the functions to the opposite. I can see that the current naming could be confusing, especially given that other operations like bit_test_and_set return the previous bit value (i.e. true if the bit was 1). That would be a breaking change, but the new operations were announced as experimental in the release notes, so if there is consensus that the result should indeed be changed, I'm ready to comply. Another solution is change (op)_and_test naming to something else that is more clear. In that case I could deprecate the (op)_and_test variants and provide the functionality under the new names. I would welcome suggestions for a better naming scheme, if you feel this is the right way. My only ask is that the new names be concise, if possible. Lastly, if you think the current naming is fine or there is another way to resolve the confusion, please comment as well. I would appreciate your opinion in any case. Thanks.

5 29

[review] Outcome v2: Review Period Concluded (Fri-19-Jan through Sun-28-Jan, 2018)
by charleyb123 . 29 Jan '18

29 Jan '18

Hi, Everyone-- The Boost Review Period for the formal review of Niall Douglas' Outcome (v2) library is concluded (having run Fri-19-Jan through Sun-28-Jan, 2018). Reviews were posted from: - Vinícius dos Santos Oliveira (Fri-26-Jan-2018) - Andrzej Krzemienski (Fri-26-Jan-2018) - Bjorn Reese (Sun-28-Jan-2018) - Daniela Engart (Sun-28-Jan-2018) - John P Fletcher (Sun-28-Jan-2018) In addition, online discussions included comments, observations, and critiques from a number of other community participants. It will take some time to review the discussion, make a final determination, and prepare the Review Report. Please: - Contact me (directly or on-list) if I missed identification of your review during the review period; - Contact me (directly or on-list) if you have any concerns; or to raise any salient observations or "final thoughts" Thank you! --charley Boost.Outcome(v2) Review Manager

1 0

[gsoc18] Interested in adding statistics and machine learning functions to Boost.uBLAS and Seeking for mentors
by Kanch 29 Jan '18

29 Jan '18

Dear community: My name is Long Zhang,currently in my third year of college. As subject suggests, I'm interested in adding statistics and machine learning functions to Boost.uBLAS library. I've basic knowledge of statistics (which I have been thought in school) and Machine Learning, I learned Machine Learning by Andrew Ng on Coursera, and I have tried to implement algorithms like PCA,LDA,K-means in Python, therefore, I think it won't be a problem if I have to implements it in C++. BTW, I have use C++ since my Senior High. Except components mentioned in wiki, I think I can also implement algorithms like KNN,Logistic Regression, even SVM during the summer. I also understand the efficiency of these algorithms is what matters, I will try hard to implement it as fast as it can. I know I have do some kind of programming competency test. When should I start? I mean I haven't find a mentor, don't know who should I contact if I finish the test. Can someone mentoring me? We can then talk about the test and code I used written in C++(open source code in C++) to check if I'm qualified to this project. Thank you. Best, Long -- Best regards, *Long Zhang (Kanch) <http://akakanch.com> *＠ Chengdu University of Information Technology 2015 Computer Science Major Mail:kanchisme@gmail.com No.24 Block 1, Xuefu Road, Chengdu, Sichuan, China

2 2

[outcome] Formal review
by Bjorn Reese 29 Jan '18

29 Jan '18

I. DESIGN --------- Boost.Outcome provides a useful alternative / complement to exceptions, and its design is clean. I like naming of functions with wide and narrow contracts. I suggest that result<> is renamed to basic_result<>, which will then be the customizable template class, and result<> then becomes as specialzation (template alias) that does the same as the current default result<>. This makes result<> an uncustomizable companion to std::error_code, which is useful when defining interoperable APIs. One design decision that I disagree with is the choice of sum types rather than product types for internal storage. I would rather have a lower run-time footprint at the expense of increased compile times. II. IMPLEMENTATION ------------------ Looks readable and solid. There may be an overemphasis on constexpr; I would rather have had support for C++11. BOOST_OUTCOME_TRY_UNIQUE_NAME generates identifiers starting with __t but according to the C++ standard [lex.name/3.1] "each identifier that contains a double underscore __ [...] is reserved to the implementation for any use", where implementation means the C++ compiler. III. DOCUMENTATION ------------------ The documentation is well-written, with a tutorial that is easy to understand. The API Reference could be improved though. 1. What are the requirements for ValueOrError? Looking up ValueOrError brings us to convert::value_or_error, which only states that it "matches the ValueOrError concept." The rather convoluted enable_if uses ValueOrError<U> which uses detail::ValueOrError<U> and here the trail disappears. The convert.hpp header file does contain the missing explanations though. 2. What are the requirements for EC and EP? EC and EP are used informally throughout the documentation, but are described in the Custom Payloads tutorial. In the API Reference they are suddenly called S and P instead. Please use a consistent naming throughout the documentation; preferably using more descriptive names, such as OutcomeErrorCode and OutcomeExceptionPtr. It would furthermore be helpful if they were described as concepts outside the tutorial. 3. The descriptions of value_type_if_enabled and error_type_if_enabled are obscure, and it is still not clear to me if they have any relevance for the library user. If they do, then their descriptions should be more clear; if they do not, then they should not be included in the documentation. 4. The documentation of OUTCOME_TRYX contains the full macro implementation which is not really helpful to users. This macro could possibly be expressed in terms of other macros. 5. noexcept('hidden') is used in several places. Does this mean that the noexcept condition is unspecified? If so, then it is more customary to use "unspecified" in italic. IV. MISC -------- I spent 4-5 hours reading the documentation and looking at the code. I did not compile it. V. VERDIC --------- I vote for the conditional acceptance of Boost.Outcome. The conditions are: 1. The documentation should be integratable into the Boost infrastructure. 2. People must be able to submit patches to the Boost version of the library without having to convert those patches to the standalone version.

2 1

Fwd: Fwd: [review] Review of Outcome v2 (Fri-19-Jan to Sun-28-Jan, 2018)
by degski 28 Jan '18

28 Jan '18

---------- Forwarded message ---------- From: degski <degski(a)gmail.com> Date: 28 January 2018 at 17:11 Subject: Re: [boost] Fwd: [review] Review of Outcome v2 (Fri-19-Jan to Sun-28-Jan, 2018) To: Vinícius dos Santos Oliveira <vini.ipsmaker(a)gmail.com> On 28 January 2018 at 16:44, Vinícius dos Santos Oliveira < vini.ipsmaker(a)gmail.com> wrote: > Can you elaborate on your point? If I'm left alone I'll miss your point. > I was mostly just responding to your example (which you asked me to do), and how I would do that, without having to deal with exceptions and/or outcomes. But, the more general point is, which Spirit in this case does very well, is to deal with potential problems at the source, in an explicit (comprehensive) way, without propagation of errors or exceptions. > It's becoming confusing the more you go. > It's probably because I'm rowing against the tide here. degski

2 1

Fwd: [review] Review of Outcome v2 (Fri-19-Jan to Sun-28-Jan, 2018)
by degski 28 Jan '18

28 Jan '18

Accidentally sent privately, forwarded below: ---------- Forwarded message ---------- From: degski <degski(a)gmail.com> Date: 28 January 2018 at 15:46 Subject: Re: [boost] [review] Review of Outcome v2 (Fri-19-Jan to Sun-28-Jan, 2018) To: Vinícius dos Santos Oliveira <vini.ipsmaker(a)gmail.com> On 28 January 2018 at 14:10, Vinícius dos Santos Oliveira < vini.ipsmaker(a)gmail.com> wrote: > 2018-01-28 12:12 GMT-03:00 degski via Boost <boost(a)lists.boost.org>: > >> 1. Use of outcome is more manual and cumbersome, i.e. more error-prone. >> > > What is complex about the following? > <snipped the code> I'd just use boost::cnv::spirit and specify explicitly what happens when conversion didn't work... much shorter, very well optimized (the best) when it does work (the conversion)... > Server side code... > There's more than servers in life. Handling f.e. O-O-M-situations is not gonna help me on my lap-top... a re-think and re-write of my app is in this case in order, though... or a trip to the shop and buy a bigger stick (both the "slow path"). > If the error is exceptional or not, it depends on context, not on the > algorithm (e.g. connection failure on game client code and game server code > and both of them being backed up by the same functions). Boost.Outcome > let's you do just that by converting an error into an exception. > Yeah, that's another discussion, isn't it? errors vs. exceptions. Should exceptions be exceptional, or getting back to your conversion example, should we use exceptions to indicate failure as this is the case in Boost::Lexical_cast? I know the answer I like best, and moved on to Boost.Spirit. degski

2 3

[spirit-x3]What's use case for x3::variant<OnlyOneComponent>?
by Larry Evans 28 Jan '18

28 Jan '18

Since: http://www.boost.org/doc/libs/1_65_0/libs/spirit/doc/html/spirit/qi/quick_r… doesn't mention a unary variant: variant<A> and the comments in: https://github.com/boostorg/spirit/blob/develop/include/boost/spirit/home/q… indicates variant<T> is collapsed to T, why isn't the x3::variant here: https://github.com/boostorg/spirit/blob/develop/include/boost/spirit/home/x… declared as: template <typename L, typename R, typename ...Types> struct variant instead of: template <typename ...Types> struct variant which allows sizeof...(Types)==0 instead of the minimum size of 2? That would disallow the primary and factor using's here: https://stackoverflow.com/questions/43791079/x3-linker-error-with-separate-… which make no sense because, for example, primary_def is *not* an alternative parser. -regards. Larry

1 0

Google Summer of Code with Boost
by David Bellot 28 Jan '18

28 Jan '18

Hi everyone, still a few days before we submit our proposal to Google. Don't loose the chance to become a mentor for Boost. It shines on your CV, it is a great opportunity to work with brilliant students around the world, it makes you an official C++ world-wide expert. So far, we have a nice but little list of proposals here: https://github.com/boostorg/boost/wiki/Boost-Google-Summer-of-Code-2018 It would be good to have a bit more before I go and submit to Google. This will increase our chances to be selected again this year. For Boost it's a great funding worth several thousand of dollars every year. We just don't want to miss it. Best regards, David

2 7

[gsoc18] New Astronomy Library
by Pranam Lashkari 28 Jan '18

28 Jan '18

Boost has developed many libraries which is useful in the field of science. I would like to propose a library for "Astronomy" as a student. I have been an amateur astronomer since last 8 years and being a Computer Engineering student I will be able to develop this library with little mentoring. I have some ideas about what can be integrated into it, which I can propose if the proposal seems promising. If so are there anyone who can help me out with this and mentor me? Thank you, Pranam Lashkari

4 18

[gsoc18] ublas project 3
by Aperjump 28 Jan '18

28 Jan '18

I'm Wei Wang, a CS master student focusing on high-performance computing field. `boost::ublas` project 3 adding GPU computation interests me a lot and I'd like to help add this feature to ublas. I find this project was also on last years' list and I'm curious if anyone did this before or on which stage he/she has finished. I've already read the initial source code of `ublas` in `boost 1.29`(I also read 1.66 API, and found it add one concept `container`, which used to be `bounded_array` and `unbounded_array`). I wrote a passage describing its template parameter deduction relationships. Besides, I wrote a series blogs teaching how to use openCL efficiently with proper data partition and memory usage. This is my first time participating in GSOC, and I'm a bit of confused on following question: 1. Integrating openCL requires preparing for context, command_queue, event and other "environment objects", should they also be included in this lib? 2. Take matrix matrix multiplication A*B for example. The last stage before matrix copy assignment is in `matrix_matrix_prob` class and its evaluation requires loop through all items on both matrix. If I want to add GPU compute features, I need to launch kernel for each computation expression at this step, but it seems to be contradictory to `ublas`'s lazy evaluation rationale. How to reconcile that? 3. What should I implement in the competency matrix class? Just integer matrix or template matrix class?Should I support current `ublas` interface(those typedefs and traits)? Best regards, Wei Wang -- Sent from: http://boost.2283326.n4.nabble.com/Boost-Dev-f2600599.html

2 1

Re: [boost] [review] outcome broken on clang/libstdc++ (Linux) and Apple clang/libc++ and gcc 7.2
by Glen Fernandes 28 Jan '18

28 Jan '18

I wrote a .travis.yml for your boost-outcome submission to run your unit tests against a few compilers: The output is at: https://travis-ci.org/glenfe/ned14.outcome/builds/334222400 I updated it to make sure the clang++-libstdc++ uses a more recent libstdc++. It looks like: - clang++-libc++ fails because of forgetting to #include a header. - GCC 7.2 with -std=c++17 is the one with the Internal Compiler Errors (I didn't investigate further) - clang++5-libstdc++ fails because it cannot find a type in std Is there a reason why you don't have travis and appveyor for boost-outcome? I remember your "Best Practices" document strongly advocating that every Boost library submission should have them. Glen

3 13

Re: [boost] [review] outcome broken on clang/libstdc++ (Linux) and Apple clang/libc++ and gcc 7.2
by Glen Fernandes 27 Jan '18

27 Jan '18

On Sat, Jan 27, 2018 at 4:55 PM, Glen Fernandes wrote: > I just tried boost-outcome unit tests with clang 4.0, 5.0 on Linux > with libstdc++ with -std=c++14 and -std=c++1z which fails with many > errors: > > e.g. [snip] > In file included from > libs/outcome/test/tests/../../include/boost/outcome/detail/result_storage.hpp:34: > libs/outcome/test/tests/../../include/boost/outcome/detail/../success_failure.hpp:54:42: > error: no template named 'conditional_t' in namespace 'std'; did you > mean 'conditional'? > template <class T> using devoid = > std::conditional_t<std::is_void<T>::value, void_type, T>; > ~~~~~^~~~~~~~~~~~~ > conditional > /usr/bin/../lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/type_traits:1780:12: > note: 'conditional' declared here > struct conditional > ^ > > > Then I also tried the boost-outcome unit tests with Apple clang 8.1.0 > with libc++ with -std=c++14 and -std=c++1z which fails with errors > like: > I pasted the wrong error output here; the right error output is: clang-darwin.compile.c++ bin.v2/libs/outcome/test/core-outcome.test/clang-darwin-4.2.1/debug/cxxstd-14-iso/tests/core-outcome.o In file included from libs/outcome/test/tests/core-outcome.cpp:30: In file included from libs/outcome/test/tests/../../include/boost/outcome/outcome.hpp:34: In file included from libs/outcome/test/tests/../../include/boost/outcome/detail/outcome_exception_observers.hpp:34: In file included from libs/outcome/test/tests/../../include/boost/outcome/detail/result_storage.hpp:35: libs/outcome/test/tests/../../include/boost/outcome/detail/value_storage.hpp:181:22: error: no matching constructor for initialization of 'value_type' (aka 'boost::outcome_v2::outcome<int, std::__1::error_code, std::exception_ptr, boost::outcome_v2::policy::error_code_throw_as_system_error<int, std::__1::error_code, std::exception_ptr> >') new(&_value) value_type; // NOLINT ^ libs/outcome/test/tests/../../include/boost/outcome/detail/result_storage.hpp:270:11: note: in instantiation of member function 'boost::outcome_v2::detail::value_storage_nontrivial<boost::outcome_v2::outcome<int, std::__1::error_code, std::exception_ptr, boost::outcome_v2::policy::error_code_throw_as_system_error<int, std::__1::error_code, std::exception_ptr> > >::value_storage_nontrivial' requested here : _state(std::move(o._state)) ^ > Is this also a known issue? Only gcc 6 and gcc 7 with lisbtdc++ on > Linux seem to pass. The other combinations I tried (clang + lisbtdc++ > on Linux, Apple clang + libc++) do not. > I spoke too soon, here gcc 7 does not pass. It ICEs: libs/outcome/test/tests/../../include/boost/outcome/detail/result_value_observers.hpp:45:17: in constexpr expansion of ‘((boost::outcome_v2::detail::result_value_observers<boost::outcome_v2::detail::result_storage<int, std::errc, boost::outcome_v2::policy::error_code_throw_as_system_error<int, std::errc, void> >, int, boost::outcome_v2::policy::error_code_throw_as_system_error<int, std::errc, void> >*)this)->boost::outcome_v2::detail::result_value_observers<boost::outcome_v2::detail::result_storage<int, std::errc, boost::outcome_v2::policy::error_code_throw_as_system_error<int, std::errc, void> >, int, boost::outcome_v2::policy::error_code_throw_as_system_error<int, std::errc, void> >::<anonymous>.boost::outcome_v2::detail::result_storage<int, std::errc, boost::outcome_v2::policy::error_code_throw_as_system_error<int, std::errc, void> >::result_storage<int>(boost::outcome_v2::in_place_type_t<int>(), <anonymous>)’ libs/outcome/test/tests/core-result.cpp:330:41: internal compiler error: in adjust_temp_type, at cp/constexpr.c:1206 constexpr result<int, std::errc> a(5), b(std::errc::invalid_argument); [...] 0x6db788 cxx_eval_constant_expression ../../src/gcc/cp/constexpr.c:4034 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <file:///usr/share/doc/gcc-7/README.Bugs> for instructions. Let me know if you need more context, but it appears boost-outcome is also broken on gcc 7.2. Glen

2 1

Re: [boost] [review] outcome broken on clang with libstdc++ (Linux) and Apple clang with libc++
by Glen Fernandes 27 Jan '18

27 Jan '18

On Sat, Jan 27, 2018 at 3:07 PM, Niall Douglas wrote: > b2 libs/afio/test works fine with VS2017. So it would seem that that ICE > Vinnie encountered is some weird corner case nobody could have > anticipated. As I mentioned, almost all of the development of Outcome > was done on MSVC. It's very well tested on MSVC, and I've never seen > anything like that ICE before. I just tried boost-outcome unit tests with clang 4.0, 5.0 on Linux with libstdc++ with -std=c++14 and -std=c++1z which fails with many errors: e.g. In file included from libs/outcome/test/tests/comparison.cpp:35: In file included from libs/outcome/test/tests/../../include/boost/outcome/outcome.hpp:34: In file included from libs/outcome/test/tests/../../include/boost/outcome/detail/outcome_exception_observers.hpp:34: In file included from libs/outcome/test/tests/../../include/boost/outcome/detail/result_storage.hpp:34: libs/outcome/test/tests/../../include/boost/outcome/detail/../success_failure.hpp:54:42: error: no template named 'conditional_t' in namespace 'std'; did you mean 'conditional'? template <class T> using devoid = std::conditional_t<std::is_void<T>::value, void_type, T>; ~~~~~^~~~~~~~~~~~~ conditional /usr/bin/../lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/type_traits:1780:12: note: 'conditional' declared here struct conditional ^ Then I also tried the boost-outcome unit tests with Apple clang 8.1.0 with libc++ with -std=c++14 and -std=c++1z which fails with errors like: clang-darwin.compile.c++ bin.v2/libs/outcome/test/outcome-int-int-1.test/clang-darwin-4.2.1/debug/cxxstd-14-iso/outcome-int-int-1.o libs/outcome/test/compile-fail/outcome-int-int-1.cpp:12:26: error: no matching constructor for initialization of 'outcome<int, int, int>' outcome<int, int, int> m(5); ^ ~ libs/outcome/test/compile-fail/../../include/boost/outcome/outcome.hpp:222:31: note: candidate constructor (the implicit copy constructor) not viable: no known conversion from 'int' to 'const boost::outcome_v2::outcome<int, int, int, boost::outcome_v2::policy::all_narrow>' for 1st argument class BOOST_OUTCOME_NODISCARD outcome ^ Is this also a known issue? Only gcc 6 and gcc 7 with lisbtdc++ on Linux seem to pass. The other combinations I tried (clang + lisbtdc++ on Linux, Apple clang + libc++) do not. Glen

1 0

Re: [boost] [review] outcome broken on MSVC, plus questions
by Glen Fernandes 27 Jan '18

27 Jan '18

Hi Niall, Still working on the review; I had the following questions while reading the threads: 1. Which versions of MSVC 2017 does boost-outcome not work on, right now? 2. According to the documentation, outcome and boost-outcome both require MSVC 2017, right? i.e. They do not support MSVC 2015 or lower? 3. Is standalone outcome fine with MSVC2017, only boost-outcome that is broken? 3.1. If so, is it right that the boost-outcome repository is "generated" from the outcome repository? And is that the reason that boost-outcome is broken on MSVC 2017? 4. Would you happen to know how does your outcome/result compare to Peter's outcome/result in variant2? (I saw you point out that Peter implemented expected, and then I saw he also had an outcome/result implementation in variant2). 4.1. What different compilers and standards does his support compared to yours? 4.2. What kind of code is generated from his implementation compared to yours? Thanks, Glen

3 2

[outcome] Purpose of value_type_if_enabled?
by Bjorn Reese 27 Jan '18

27 Jan '18

Are value_type_if_enabled and error_type_if_enabled supposed to be used by the library users? If so, how?

2 1

[spirit]why x3::alternative::parse not short-circuited?
by Larry Evans 27 Jan '18

27 Jan '18

https://github.com/boostorg/spirit/blob/develop/include/boost/spirit/home/x… shows both left.parse *and* right.parse are called. Shouldn't right.parse be skipped if left.parse succeeds?

1 1

[outcome] Andrzej's review
by Andrzej Krzemienski 27 Jan '18

27 Jan '18

Hi Everyone, This is my review of Boost.Outcome v2. The library should be *accepted* subject to conditions that I list down below. What is your evaluation of the design? Clean and logically divided. What is your evaluation of the implementation? > Some bugs aside, it is clean and well structured. I was able to read it and understand how things work. I will be filing bugs in GitHub. What is your evaluation of the documentation? > Good. You can get the idea what the library is doing and how you can use it. But I should mention that I wrote some pieces thereof, so my opinion is likely biased. The docs need some modifications before they can get into Boost. I mean macro names, and the technology required to build it. What is your evaluation of the potential usefulness of the library? > I find the library very useful in certain domains. I myself have found two applications in my job project, and they are not really related to light-speed efficiency: 1. We have a task scheduling framework built atop ASIO, and signalling failures through exceptions makes the code really difficult to read because try-catch blocks need to work as control statements. Also, we cannot pass them by exception_ptr as sometimes we need to classify the kind of failure to determine if we want to deal with it in the framework, or if we want to forward them to the user. 2. I have a validation routine that validates (and parses) the input data written using some syntax. I wan the syntax-errors in input files to be forwarded as failed `result`s (no exceptional about these), but other errors like memory shortage during the file parsing to be signaled via exceptions (and I will probably kill the module in response). Why accepting this library when we have `expected` being standardized? I do not really mind having two in Boost. First, it is ready, being proposed, and applied in a number of non-trivial code-bases. Niall claims that his trade-offs are better tailored to predictable-latency applications. I do not have enough knowledge to asses it. They look convincing. The only way to test it is to give this library the Boost blessing and have the user test it. I am bought by the TRY operations, and the upgrade to `outcome` looks really convincing. Did you try to use the library? With what compiler? Did you have any > problems? > Yes. A lot of compilers. For instance GCC 6.4.0, also different GCC and Clang versions in WandBox. No problems encountered. How much effort did you put into your evaluation? A glance? A quick > reading? In-depth study? > I have read most of the final implementation. I have read many versions of the documentation. I have spent a lot of time (prior to the review) asking Niall lots of questions about the details. I have also built lots of small examples to test the library and some corner cases. Are you knowledgeable about the problem domain? > I do report failures (by different means) in my programs. I have given it quite some thought. I am well familiar with implementation and formal specification of `boost::optional` and `std::optional` which had to address some similar implementation problems. Do you think the library should be accepted as a Boost library? > Yes, conditionally. Here are three conditions: 1. Documentation is adjusted to use boost-standard names of macros and namespaces. Also, it is not clear if Boost release process is capable of handling the technology that Niall has chosen. If not, the contents of documentation should be migrated to another format, manageable by Boost release process. 2. Because there has been some confusion around the meaning of storing default-constructed `std::error_code` (is it an error or lack thereof?) and `std::exception_ptr` (e.g., see this issue: https://github.com/ned14/outcome/issues/115) I request that you state in the docs, before the API Reference how library treats default-constructed values of `EC` and `EP`. For instance, you can say "default-constructed error_code is considered an error, and treated as such by the library", or "the library sometimes may make use of the fact that a default-constructed EC/EP is not an error, so make sure not to pass us such values": I am fine with any answer, but I need you to spell it out, so that I know what to expect. 3. Similarly, I request that you put in the docs what is the "value" of an object of type `outcome<>` or `result<>` in the sense in which John Lakos talks about "salient attributes". I know that T, EC, and EP constitute the value. But in the middle of the tutorial we learn that apart from these you also store "spare_storage" -- is it also included in copying and comparisons? API reference on `operator==` only says "compares if two objects are equal", but it is not that clear what it means. Also, what does it mean that result is equal to optional. Define it somewhere and paste links to it. Finally, I wan to thank Niall for his now many-year effort to deliver this really cool library to the community. Regards, &rzej;

4 7

Re: [boost] [review] Outcome: internal compiler error
by Vinnie Falco 27 Jan '18

27 Jan '18

On Thu, Jan 18, 2018 at 2:07 PM, charleyb123 . via Boost <boost(a)lists.boost.org> wrote: > GitHub: > *- https://github.com/ned14/boost-outcome > > Please post your comments and review to the boost mailing list > (preferably), or privately to the Review Manager (to me ;-). Here are some > questions you might want to answer in your review: I have put together the following sample program to test integration of Outcome into Boost.Beast: #include <boost/outcome.hpp> int main(int argc, char** argv) { } The result of compilation for this translation unit is shown here: 1>c:\users\vinnie\src\boost\boost\outcome\detail\value_storage.hpp(141): 1>fatal error C1001: An internal error has occurred in the compiler. 1>(compiler file 'msc1.cpp', line 1507) Compiler used: MSVC Part of: Microsoft Visual Studio Community 2017 Version 15.5.1 Upon investigation, I discovered a newer version of the compiler and IDE. Updating to "Version 15.5.5" produced the following results when compiling the same translation unit: 1>c:\users\vinnie\src\boost\boost\outcome\detail\value_storage.hpp(141): 1>fatal error C1001: An internal error has occurred in the compiler. 1>(compiler file 'msc1.cpp', line 1507) Is this a supported configuration? Thanks

3 4

[review] outcome
by Vinícius dos Santos Oliveira 27 Jan '18

27 Jan '18

That is my review of Boost.Outcome. What is your evaluation of the design? Niall did an excellent job weighting trade-offs and coming up with such an pleasant and convenient interface that not only is convenient, but it has customization points in the appropriate layers to fit not-close-to-trivial use cases. I've read the changes between v1 and v2 and I agree with the rejection reasons of previous version (the v1's null state specially made little sense at all). Version 2 is a very realistic and solid project. It might seem teasing to just port abstractions from functional languages to C++ (e.g. Expected), but C++ is its own beast and we cannot just ignore some features that we have been dragging all along like exceptions if we expect to have any realistic usage in the real world. Niall's intuition on how to weigh trade-offs was outstanding and just proves his C++ familiarity and expertise. In special, default actions/behaviours could only be defined by intuition of some experienced programmer and not "mathematically". What is your evaluation of the implementation? I did not check the implementation. What is your evaluation of the documentation? Very well written. The tutorials are excellent-quality. The use cases and examples were chosen in such a way that it was intuitive to understand why/when Boost.Outcome and not Expected. I noted a few small problems, but they were reported already. The comments on the example codes were seemingly foreseeing ahead enough about "pumping doubts" so that my mind would calm down and actually pay attention to the documentation instead doing mind exercises trying to guess the non-point of the example. I wish I had this skill. What is your evaluation of the potential usefulness of the library? Very useful. Error handling is a core constant in any programming activity. Introduction of Boost.Outcome could potentially remove duplication of throwing and non-throwing APIs. I personally prefer Expected with its monadic operations, but it is unrealistic to ignore exceptions in many code bases and I'd certainly go for Boost.Outcome in these cases. Did you try to use the library? With what compiler? Did you have any problems? Yes. The one-header version of the library made testing incredibly easy. No problems. Clang 5.0.1. How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? A few hours over a span of a few days. I've tried to examine documentation carefully and end up sending a pull request and a few comments to ask for further changes. I've read all threads that came up during review. I also tested the library when in doubt. Are you knowledgeable about the problem domain? I worked for more than one year under contract using the Rust programming language and Boost.Outcome is pretty much the error system we have in Rust (with some C++-ification and an experienced C++ unique programmer "intuition" to also cover exceptions... and w/o monad ops, of course). Do you think the library should be accepted as a Boost library? Yes. -- Vinícius dos Santos Oliveira https://vinipsmaker.github.io/

2 1

[config] Positive feature macros, r2
by Peter Dimov 26 Jan '18

26 Jan '18

I'd like to revisit the topic of Boost.Config feature macros, specifically that in my opinion, positive feature macros (BOOST_CXX17_FEATURE) make more sense than negative macros (BOOST_NO_CXX17_FEATURE) in the current environment. Negative macros made sense in the past when they signified bugs and deficiencies in the compiler as measured against a static standard. Nowadays, the standard, such as it is, is in constant motion and macros indicate merely a current state of development for both the compiler and the standard. The arguments for positive macros are the same as last time: - adding a new negative macro requires changes to all legacy compilers that do not and will never implement the feature; a positive macro only requires changes to active compilers. - positive macros are a better match for the standard feature macros, which are positive. When we see a standard feature macro being set, we typically would set ours as well. This means that the amount of changes required to add a new macro is further reduced; we only need to touch compiler-specific config files if the compiler either does not implement feature macros, or sets them incorrectly (in our considered opinion.) TL;DR we should switch to positive feature macros in Boost.Config, and delaying this switch just accumulates more unnecessary code in Boost.Config.

7 13

[gsoc18][ublas] Proposal to add advanced matrix operations
by SHIKHAR SRIVASTAVA 26 Jan '18

26 Jan '18

Hi everyone, I am a 4th year undergraduate student pursuing a degree in Computer Science and Engineering. I have strong programming experience in C++ through internships, self projects and programming events. I wish to be a part of gsoc18 under boost and am particularly interested in the linear algebra library Boost.ublas. The ublas library can be made more useful for Machine Learning applications like recommendation systems, clustering and classification, pattern recognition by adding some operations required in those. I propose to add advanced matrix operations to ublas including - 1. Triangular Factorisation (LU and Cholesky) 2. Orthogonal Factorisation (QR and QL) 3. Operations to find Singular Value lists 4. Eigenvalue algorithms 5. Singular Value Decomposition (SVD) 6. Jordan Decomposition 7. Schur Decomposition 8. Hessenberg Decomposition This is a very brief description of what I would like to propose. Any suggestions that help in refining the requirements before making a draft proposal would be great. Regards Shikhar Srivastava Github: https://github.com/shikharsrivastava

7 12

[outcome] success-or-failure objects
by Vinícius dos Santos Oliveira 26 Jan '18

26 Jan '18

I'm liking what I saw so far. Just a small comment on the documentation. I'm curious what the following sentence does even mean? Is it supposed to confuse the user or something? It's a sign of bad taste really. >Outcome’s default is to not provide value-or-error objects. It provides success-or-failure objects. What does that even mean? value-or-error... well, if it is non-error, I assume it is success. Both sentences mean just the same. As do their API (encapsulate either A or B). The rest of the paragraph is okay. If you just remove this comment, confusion will go away. No other changes need to be done in this paragraph. Just remove this misleading means-nothing comment. -- Vinícius dos Santos Oliveira https://vinipsmaker.github.io/

7 27

[Root Pointer] Deterministic C++ memory manager (update)
by Phil Bouchard 26 Jan '18

26 Jan '18

Greetings, I wanted to give an update to the community regarding the memory manager I wrote called: Root Pointer. I now have a working template to solve all memory leaks in C++ and C but both requires some meta data generator. The code can be found here; it is working but not polished: https://github.com/philippeb8/root_ptr In this code we can find: - node_ptr: main class of the smart pointer / memory manager. - root_ptr: generic derived class that includes an "iterator" and a pointer to the name of the instance (for debugging purposes). Also I commented some code that logs the exact location of the memory leak. Furthermore I would like to bring some observations that I found in the C and the C++ language: - Pointers and iterators are not the same; i.e. pointers should point to allocated blocks only and shouldn't have arithmetic operators while iterators shouldn't be used to deallocate anything. - C pointers can only point to dynamic arrays (size known at run-time). - C++ pointers can point to both inherited objects and static arrays (size known at compile-time). This creates a problem (see attached: array_inherited_pointer.cpp). - std::array<T> should have constructors with T objects that have no default constructor. Lastly, before I submit anything, I will have to propose a way to apply a template function to all non-static member variables of a class. This will require implicit meta data generation. This idea is not new as other libraries such as Qt is based on meta data and they certainly could make us of this. For the moment I have a parser that does the job correctly by specializing a boost::proxy() template function but eventually this will have to be integrated into the standards. Hopefully this is an important milestone! Regards, Phil Bouchard www.fornux.com

2 5

clang-format file
by Damian Vicino 25 Jan '18

25 Jan '18

Hi, I was wondering if someone has a .clang-format file that works fine to check boost code. I looked into the github repositories, but I couldn't find any. Best regards, Damian

9 11

[outcome] Some documentation suggestions
by Vinícius dos Santos Oliveira 24 Jan '18

24 Jan '18

Maybe I could send some PRs later (I've already sent one a few moments ago). But, for now, I'll have to postpone. Notes: - You put too much focus in "open (error) type hierarchies" (e.g. `error_code`). Not a problem. Also, do not change anything just because this comment. Really, it is not a problem. - The beginning of the documentation gave me the impression that I could only use EC types that were convertible to `std::error_code`[1], “it need in fact to merely satisfy trait::has_error_code_v<EC>”. Later pages corrected my understanding. - “only works when the EC type is the same in the try expression as the calling function”[2] is misleading. `OUTCOME_TRYV(outcome::result<int, err>{err::success})` works inside a function returning `outcome::result<void>` given `err` is convertible to `std::error_code`. [1] https://ned14.github.io/outcome/tutorial/payload/ [2] https://ned14.github.io/outcome/tutorial/default-actions/error-codes/ -- Vinícius dos Santos Oliveira https://vinipsmaker.github.io/

2 3

[outcome] comments on Regular ops
by Andrzej Krzemienski 24 Jan '18

24 Jan '18

Hi Everyone, This is not my final review (yet), but I wanted to raise some issues with Regular ops: comparisons and swap. 1. Comparisons. Equality comparison for `result` makes a strange choice for `T`s without comparisons: two such `result<T>`s just compare unequal. This is somewhat contradictory to semantics of Regular types. For value-semantic types we expect that a copy of the original object `x` compares equal to `x`: ``` int i = 1; int j = i; assert (i == j); ``` For some types, copy-construction makes a copy with the same value, but there is no way to define operator==. In this case, in order not to confuse anyone operator== is simply not provided: ``` using transformation = std::function<int(int)>; transformation f = [](int i) { return i; }; transformation g = f; // assert (f == g); <-- does not compile ``` And now, when we wrap it into `result`, we get: ``` // continuing previous example: out::result<transformation> of = f, og = g; f == g; // <-- compiles fine, returns false. ``` Now you are just telling lies. Two objects have the same value, yet they compare unequal! Here is a live example: https://wandbox.org/permlink/I hqgXDfHW6WqAXHW My recommendation would be not to provide comparison operators if either `T` or `EC` does not provide them. 2. Swap For non-trivially-copyable types, it looks like (similarly to std::variant) `result` cannot provide the strong exception safety guarantee. You may need to both move-construct `T` and `EC` and both can fail. ``` void swap(result &o) noexcept(detail::is_nothrow_swappable<value_type>::value // &&detail::is_nothrow_ swappable<error_type>::value) { using std::swap; #ifndef BOOST_NO_EXCEPTIONS this->_state.swap(o._state); try { swap(this->_error, o._error); } catch(...) { swap(this->_state, o._state); throw; } #else swap(this->_state, o._state); swap(this->_error, o._error); #endif } ``` The trick with catch-reswap-rethrow assumes that `T` is more likely to throw while swapping/moving than `EC`, but it might be quite the opposite. Also, it is possible that while reswapping, another exception will be thrown. In general, you cannot guarantee the roll-back, so maybe it would be cleaner for everyone if you just declared that upon throw from swap, one cannot rely on the state of `result`: it should be reset or destroyed. Another problem is that in the noexcept() clause you are mentioning is_nothrow_swappable<value_type> and is_nothrow_swappable<error_type>, but in the implementation you might be using move constructors rather than swaps. This means that for types that do not throw in swap but throw in move constructor (like std::list), a throw from move constructor will cause a call to `std::terminate`. See live example here: https://wandbox.org/permlink/8jIyb0fx7U72cZSt The noexcept clause should be extended to include move-constructors. This is the case for `std::optional`. Regards, &rzej;

5 14

yomm2 - open methods
by Jean-Louis Leroy 24 Jan '18

24 Jan '18

Hi, in 2013 I posted a proposal for an "open multi-methods" library, see here: https://lists.boost.org/Archives/boost/2013/07/205383.php Due to insufficient interest, I did not go forward with a formal submission, and I published my work on github, under the name yomm11. I have now completely rewritten the library. The new version - yomm2 - is available here: https://github.com/jll63/yomm2 This iteration is much better because it does not require any modifications to classes involved in method dispatch, yet the speed of a method call with one virtual argument is within 15% of the equivalent virtual function call. Over the years I realized that the value of such a library resides more in the 'open' than in the 'multi' aspect. Open methods are virtual functions that live outside classes, like free functions. They solve several problems, notably the Expression Problem (http://wiki.c2.com/?ExpressionProblem) and Cross-Cutting Concerns (http://wiki.c2.com/?CrossCuttingConcern) They provide an elegant replacement for the Visitor pattern. yomm2 also implement multiple dispatch, which can come (occasionally) handy. Well I am just touching base to see if things have evolved and if there might now be an interest in seeing this in Boost. Jean-Louis Leroy

3 12

Contributing in the algorithm library
by Surayans Tiwari 24 Jan '18

24 Jan '18

Hello Boost Community! My name is Surayans Tiwari currently pursuing Bachelors of Engineering at BITS Pilani, India . I am an algorithms enthusiast and c++ programmer with 3 years of experience coding in the language. I want to get a head start on how to add new modules in algorithm library of boost. Please can someone help me with this. Thank you. ‌

4 10

[outcome] Whether to default EC = error_code for result?
by Niall Douglas 23 Jan '18

23 Jan '18

Just wondering what the reviewers' opinion is on the choice by Outcome to default `result<T, EC = std::error_code>`? That made sense back when Boost.System's error_code aliased `std::error_code` when being compiled under C++ 11 or better (i.e. always in the case of Outcome). But now that Boost.System's error code looks to be becoming a superset of `std::error_code`, I am now wondering whether to no longer default it at all to anything. Arguments in favour of this: 1. Expected no longer defaults E to anything, thus avoiding including <system_error> which drags in <string> and imposing compile time costs on those who don't use <system_error>. I did some more benchmarking, on a recent GCC on a 4Ghz CPU it's about 0.6 secs per compiland being added on Linux, and more like a second on Windows with MSVC. 2. As is pretty clear from the tutorial, we expect all non-trivial uses of Outcome to typedef `result` into the local namespace anyway. So defaulting `EC` only really benefits trivial use cases. 3. I think it now inevitable I need to go implement a much lighter weight <system_error2> without the problems with <system_error> (e.g. header only use problems, heavy includes, underspecified semantics, hardcoded use of `int`, memory allocation and so on). I'll send it to SG14 for them to get it into the standard if they like it (they will, it'll tick all their boxes, WG21 may be more challenging). Arguments against this: 1. Use of `std::error_code` ought to be encouraged rather than UDTs such that Outcome using code is not anti-social to other code. Defaulting the type sends a clear message on this. 2. Removing the defaulted `EC` on `result` is asymmetrical to defaulting `EC` and `EP` on `outcome`. I personally don't mind it, different typical use cases means different defaults, but others may find the asymmetry upsetting. 3. The relevant policies need to include `<system_error>`, otherwise they don't compile. So the include of `result.hpp` would need to be split into a `result.hpp` and a `error_code_support.hpp` with the latter containing the `<system_error>` stuff. Thoughts? Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

2 2

23 Jan '18

While refactoring the test Jamfile for Boost.System, I wrote this rule: rule system-run- ( sources + ) { local result ; result += [ run $(sources) : : : <link>static : $(sources[1]:B)_static ] ; result += [ run $(sources) : : : <link>shared : $(sources[1]:B)_shared ] ; result += [ run $(sources) : : : -<library>/boost/system//boost_system <define>BOOST_ERROR_CODE_HEADER_ONLY : $(sources[1]:B)_header ] ; return $(result) ; } to avoid repeating each test three times. The inconsistency is somewhat annoying. We could normalize the third line by introducing a third link type, <link>header, in response to which the library can switch to header-only mode. This is more or less the same suggestion as Niall's _hl targets from the CMake discussion, but it fits Boost.Build better, because the <link> property is automatically propagated to dependencies. Furthermore, after thinking about it a bit, I think that we might even have room for a fourth link type, <link>source, in response to which the library target would pass an appropriate <source> usage-requirement upwards. (<source>error_code.cpp in Boost.System's case.) <link>source is kind of best of both worlds, as it doesn't reparse the source code each time the library is used, and at the same time is not prone to the ODR violations introduced by inadvertently compiling the library and the executable with different, ABI-incompatible options. Comments?

2 4

[git][releases] removing beta tags
by Raffi Enficiaud 22 Jan '18

22 Jan '18

Hi all, I would like to know if it is allowed to delete the git tags that are associated to beta releases (such as "boost-1.45.0-beta1"). Thanks, Raffi

2 2

[trac] email notifications?
by Raffi Enficiaud 22 Jan '18

22 Jan '18

Hi, Is trac sending email notification on comments and changes regarding tickets? It used to do so, but I am not receiving anything. I am asking because I am waiting for ppl to comment on the tickets for some time. If people do not receive email notifications, I think I will wait for ever. Thanks, Raffi

2 2

[trac] new versions of boost
by Raffi Enficiaud 22 Jan '18

22 Jan '18

Hi there, Would it be possible to add the next versions of boost to trac/milestones ? Thanks! Raffi

7 12

[system] Would it be possible to trial a breaking change to Boost.System and see what happens?
by Niall Douglas 22 Jan '18

22 Jan '18

SG14 the low latency study has been looking into how to improve some design decisions in <system_error>. The relevant WG21 paper is https://wg21.link/P0824 and recent discussion can be found at https://groups.google.com/a/isocpp.org/forum/#!topic/sg14/j7tQybEjP5s. What we'd like to do is to test whether some very mildly breaking changes to <system_error> are so mild as to affect no users, and on that basis propose WG21 to make those mildly breaking changes to <system_error> in the next C++ standard. And to test this, we'd like to modify Boost.System with those mildly breaking changes, ship a release and see how many users complain. If it is zero, we have evidence for WG21 that this is not a consequential change. What we'd like to change is this: 1. Stop treating code zero as always meaning success irrespective of category. This remedies a defect where some custom error code domains cannot be represented by error_code due to using value 0 for an error. In actual code, I've never seen anyone ever use comparison to anything but a default constructed error code, so I think this will be safe. 2. Success becomes solely the default constructed error code, which is code zero and a new category of "null_category". This is internally represented by { 0, nullptr }, and thus makes the default constructor trivial which is highly desirable as it eliminates any compiler magic static fencing for the default constructor. Right now the default constructor uses system_category with value 0, and I suspect no code will notice this change either. 3, Make the default constructor constexpr, now possible. No code should notice a difference, except less runtime code will be generated. 4. error_code::message() returns a std::string_view instead of std::string if running C++ 17 or better. This lets us remove the <string> dependency, and thus stop dragging in half the STL with <system_error> which in turn makes <system_error> actually useful to the embedded systems crowd. The guess here is that std::string_view has such excellent interoperation with std::string that I think 99% of code will compile and work perfectly without anybody noticing a thing. I appreciate that this would undo Peter Dimov's excellent work at having Boost.System alias <system_error> under C++ 11 and later. I also appreciate that we are deliberately going to potentially break end user code. But my personal guess is that in practice, the breakage will not be noticed by 99% of code out there right now. It'll just compile against the improved Boost.System and everything will work as before. Boost was originally intended as an incubator for C++ standard changes. This ticks that box perfectly. Thoughts on feasibility? Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

15 76

Travis CI Resources
by James E. King, III 22 Jan '18

22 Jan '18

Last summer we had a discussion about Travis CI Resource Usage for boostorg. Originally the discussion was about purchasing more resources; however the discussion quickly focused on finding the root cause of the backlog. The desire is to ensure that pull requests submitted to repositories are processed in a timely manner. This is not happening, and there is at least a 12 hour backlog on pull request builds for boostorg right now. Summarizing the discussion back then, it was proposed that the backlog was caused by folks working on feature branches directly in their boostorg repository, with the Travis CI setting enabled to "build branch updates". The proposed solution was to encourage everybody to fork their repository and set up their own Travis CI and Appveyor under their account, and work feature branches on your fork. If working alone, this is efficient for everyone as we all end up with faster builds because your account will not contend with boostorg for resources. So please, use your personal account to build up features if you can. Additionally, tuning your Travis CI build script to do a little bit less work will help. If you have a script that builds with gcc, gcc-5, gcc-6, gcc-7, clang, and cxxstd of 03,11,14,1z - for most libraries that are at the c++03 language level this is going to be significant overkill for use as a pull request gate. In the example above, there are 20 builds to do; double that if you build debug and release variants. If each build takes just 2 minutes that's still an 80 minute CI cycle. Please spend some time reviewing your practices around the use of the free CI resources we all share. Thanks, Jim

5 11

[config] Supporting newer compilers: what does it take?
by Olaf van der Spek 22 Jan '18

22 Jan '18

Hi, What does it take to support new compilers, especially MSVC? 15.6 Preview 1 has been released now. Is some documentation or policy regarding test runners etc available? https://blogs.msdn.microsoft.com/vcblog/2017/12/19/c17-progress-in-vs-2017-… Gr, -- Olaf

1 1

[gsoc18] RSS
by Greger 22 Jan '18

22 Jan '18

Got some code/idea for RSS. possibly an GSoC18 topic?anyone? br g

2 3

[bjam] Can I disable a test based on an environment variable?
by James E. King, III 21 Jan '18

21 Jan '18

I'd like to disable some serialization tests if I am running a ubsan build on travis. Is there a way in the Jamfile I can make it conditional on an environment variable, or should I define something like BOOST_DATE_TIME_UBSAN and put "if !defined" in the appropriate tests?

2 2

[gsoc2018] Dynamic Shortest Path Tree
by a.i＠acm.org 21 Jan '18

21 Jan '18

Hi, I am Donghyuk Kim, a Ph.D. Student at Korea Advanced Institute of Science and Technology. I tried to contribute something last year but was not able to start the project for some reason. So I am about to re-try again this year. What I would like to contribute is a specific algorithm, "Dynamic Shortest Path Tree" which is simply, a dynamic version of Dijkstra's algorithm. It is a tree-based data structure to maintain single-source to all destination shortest paths and known to outperform Dijkstra or A* where the insertion and deletion of vertex/edge frequently occur. The concept of "Dynamic Shortest Path Computation" was originally introduced in [Fully Dynamic Algorithms for Maintaining Shortest Paths Trees] by D. Frigioni, et al. (http://dl.acm.org/citation.cfm?id=338900) I have already implemented a working prototype for my research, but unit test, coding style unification, and much more c++ style modifications are required for the general purpose. I hope someone finds it interesting and be a mentor on this journey. Thanks in advance. Best Regards, Donghyuk Kim a.i(a)acm.org _____________________________________ Sent from http://boost.2283326.n4.nabble.com

2 1

[gsoc18] SafeFloat proposal
by Damian Vicino 21 Jan '18

21 Jan '18

Hi, I added a proposal to get SafeFloat ready for review: https://github.com/boostorg/boost/wiki/Boost-Google-Summer-of-Code-2018#3-b… This was a project I started in gsoc2015 as student mentored by Robert Ramey. Please contact me if you are interested in further details. Best regards, Damian Vicino

2 1

Google Summer of Code 2018
by David Bellot 20 Jan '18

20 Jan '18

Dear Boost community, once again this year, we will apply to be a mentoring organization for the Google Summer of Code 2018. Our organization has been quite succesful for the last decade and this year we hope to be selected again. As part of filling in our application for 2018, we must supply to Google a list of potential GSoC mentors and potential GSoC projects for summer 2018 in order to be approved as an organisation this year. Therefore a lengthy page of awesome project ideas at https://svn.boost.org/trac/boost/wiki/SoC2018 before *January 23rd* would be an enormous help to getting us approved again this year and bringing to Boost another Google funding (worth dozens of thousands of dollars on average). If you think yourself able to mentor a student doing some work on Boost this summer, *please* consider adding a description of the proposed work item and your name to the list. If you want to have a better chance receiving funding for your project ideas, it is better to find good students early and that is best done by getting project ideas floated *early*. If you want to know more about mentoring a Google Summer of Code funded student work before you nominate yourself, please feel free to ask on the main Boost developers mailing list boost(a)lists.boost.org or via gsoc-admin(a)boost.org. Thank you in advance for your time. Finally, I would like to thank Niall Douglas, our previous Boost admnistrator for GSoC, who did an awesome work during many years and helped the Boost community grow thanks to all the funding we received years after years from Google. Best regards, David

4 9

Fwd: Re: [gsoc18][ublas] Proposal to add advanced matrix operations
by Mike Gresens 20 Jan '18

20 Jan '18

Hi Mike, Apart from the operations I was proposing, the idea of solving polynomials via QR reduction seems a great idea to me. I can add this module in the list of operations to be added to Boost.ublas in my proposal. I am looking for someone to mentor me on this project. Regards, Shikhar Srivastava On Sat, Jan 20, 2018 at 10:34 AM, SHIKHAR SRIVASTAVA <shikharsri1996(a)gmail.com <mailto:shikharsri1996@gmail.com>> wrote: Hi Mike, It looks like some of the operations that I suggested were already implemented as a part of GSOC15, though never got merged into the main branch. https://www.google-melange.com/archive/gsoc/2015/orgs/boostcpp/projects/raj… <https://www.google-melange.com/archive/gsoc/2015/orgs/boostcpp/projects/raj…> https://github.com/BoostGSoC15/ublas/ <https://github.com/BoostGSoC15/ublas/> My Idea was to add generalised modules for the operations (Now) - 1. LU and Cholesky 2. QR and QL 3. SVD On Fri, Jan 19, 2018 at 9:14 PM, Mike Gresens <mike.gresens(a)googlemail.com <mailto:mike.gresens@googlemail.com>> wrote: Hi Shikhar, does this include something for solving polynomials (via balanced-QR reduction of the companion matrix)? See https://www.gnu.org/software/gsl/doc/html/poly.html#general-polynomial-equa… <https://www.gnu.org/software/gsl/doc/html/poly.html#general-polynomial-equa…> Thanks! Best regards, Mike... Am 19.01.2018 um 07:37 schrieb SHIKHAR SRIVASTAVA via Boost: Hi everyone, I am a 4th year undergraduate student pursuing a degree in Computer Science and Engineering. I have strong programming experience in C++ through internships, self projects and programming events. I wish to be a part of gsoc18 under boost and am particularly interested in the linear algebra library Boost.ublas. The ublas library can be made more useful for Machine Learning applications like recommendation systems, clustering and classification, pattern recognition by adding some operations required in those. I propose to add advanced matrix operations to ublas including - 1. Triangular Factorisation (LU and Cholesky) 2. Orthogonal Factorisation (QR and QL) 3. Operations to find Singular Value lists 4. Eigenvalue algorithms 5. Singular Value Decomposition (SVD) 6. Jordan Decomposition 7. Schur Decomposition 8. Hessenberg Decomposition This is a very brief description of what I would like to propose. Any suggestions that help in refining the requirements before making a draft proposal would be great. Regards Shikhar Srivastava Github: https://github.com/shikharsrivastava <https://github.com/shikharsrivastava> _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost <http://lists.boost.org/mailman/listinfo.cgi/boost>

1 0

[geometry][gsoc2018] Similarity between geometries
by Xing GUO 20 Jan '18

20 Jan '18

Hello, My name is Guo Xing, I have sent a mail for some ideas on gsoc18 projects. David's uBLAS project on GPU computation is a little bit hard for me. Still thanks for his kind reply :) . These days, I found a project that I could possibly work on. So, I decide to take "Similarity between geometries". Below is my short self-introduction. Name: Guo Xing University: Southeast University Major: Electronic Engineering Email: higuoxing(a)gmail.com Github: https://github.com/higuoxing Homepage: https://higuoxing.com Availability: (Feb-Jun 4 hr/day) (Jun-Aug 6hr/day or more) As for my code competency, I will take the project 1 competency test after my final exam. Thank you! Regards, Guo Xing

1 0

[callable_traits] Incorrect newlines in git
by Andrey Semashev 20 Jan '18

20 Jan '18

Hi, I've created this PR to fix newlines and tabs in Boost.CallableTraits: https://github.com/boostorg/callable_traits/pull/170 Without it, I cannot update my local Boost tree because git treats the files are modified. Could someone, please, merge this PR? It's really annoying that the update process breaks every time. Thanks.

2 1

[gsoc18] Implement HTTP Library
by Xing GUO 19 Jan '18

19 Jan '18

Dear community: I'm Guo Xing, who is currently a student in his third year of college(bachelor's degree). I have interests in web development. I've done some projects with Python and node before. I want to do some work with C++ in GSoC18. So, is there any ideas for me? Or, someone could be my mentor? I love open source, but never contribute to them. I want to do some contribution. Regards, Guo Xing https://github.com/higuoxing

3 2

crypto hash library
by kerukuro 19 Jan '18

19 Jan '18

While boost::hash and the proposed additions and are good for generic hashing, its API is not very suitable for cryptographic hashes and XOFs. Would there be any interest in boostifying this library eg under name 'boost::digest' and putting cryptographic hashes in there? https://github.com/kerukuro/digestpp

1 0

[gsoc18] R-tree serialization
by Kirill Mishchenko 19 Jan '18

19 Jan '18

Hi, My name is Kirill. I’m interested in the contribution to the project “R-tree serialization”. The search through the mailing list archive has shown there was an interest in this project among students in 2017, but as the GSoC 2017 archive site displays there was no student that participated to accomplish this project. Is it possible to work on this project as a GSoC 2018 participant? It seems like last year Adam Wulkiewicz was ready to be a mentor for the project. Briefly about myself. I am a PhD student working on Computational Humor. More precisely I’m working on the problem of finding/generating a humorous response given a textual input. My C++ programming experience includes a summer internship at Yandex Search and my contribution to mlpack (a machine learning library written in C++) as a GSoC 2017 participant (https://summerofcode.withgoogle.com/archive/2017/projects/4812231682293760/ <https://summerofcode.withgoogle.com/archive/2017/projects/4812231682293760/>). For mlpack I designed and implemented cross-validation and hyper-parameter tuning modules with significant usage of C++ metaprogramming. Best regards, Kirill Mishchenko

2 1

mingw and windows.h
by Raffi Enficiaud 18 Jan '18

18 Jan '18

Hi all, I recently pushed something for boost.test on develop that is apparently breaking the builds on mingw: http://www.boost.org/development/tests/develop/developer/output/igaztanaga-… What I do in the code is this: ---------- #ifdef _WIN32 #include <Windows.h> #endif ---------- and then later ---------- #ifdef _WIN32 class setcolor { protected: void set_console_color(std::ostream& os, WORD *attributes = NULL) const { DWORD console_type; /// some additional windows specific code #endif ---------- I thought that this would be enough for having the windows specific code, but apparently mingw disagrees with the error that some windows specific define is not there. Is this an issue with the code, the SDK, the machine? I have no experience with mingw, but if we are able to include windows.h, then we have to have the defines there (the missing macro is there since Windows 2000). Thanks for the help, Raffi

3 4

Google Summer of Code 2018: submit your proposal
by David Bellot 17 Jan '18

17 Jan '18

Hi all, I migrated the GSoC'18 pages to our wiki on Github. Please contribute your proposals here now: https://github.com/boostorg/boost/wiki/Boost-Google-Summer-of-Code-2018 I would love to see plenty of nice proposals before the end of the week so that we are in good conditions to obtain it again this year. If you have problems with permission please contact me directly Best regards, David

1 0

Change Trac wiki permissions
by David Bellot 17 Jan '18

17 Jan '18

Hi, does anyone have access to the boost Trac wiki. I need to change permissions on a page to allow users to edit the page as well, but I can't find any option. There should be an Admin button next to the Search button but it doesn't appear. The page in question is the Google Summer of Code 2018: https://svn.boost.org/trac10/wiki/SoC2018 Thanks David

2 2

Reforming Boost.System and <system_error> round 2
by Niall Douglas 17 Jan '18

17 Jan '18

Many thanks to those who have contributed to the discussion in the other thread regarding making a breaking change to Boost.System in order to provide empirical test data to persuade WG21 to similarly break <system_error> in a future C++ standard for its own good. This fresh email is hopefully to start finishing the discussion. To summarise discussion to date, Peter has made Boost.System's error_code and error_category constexpr except for the virtual functions. A big win for codegen, and the choice of the default constructor of error_code to use system_category now no longer prevents constexpr, so the request for a new special null_category() can also be dropped. There is substantial opposition to making message() return string_view, so let's drop that request. That leaves the request to fix "if(ec) ..." which right now returns true if the value is 0, despite that much code writes "if(ec) ..." to mean "if error then ...". There is also the issue of error coding schemes not being able to have more than one success value, which usually must be 0. That's the remaining discussion point. Myself and Peter feel this is worth fixing despite the increased runtime overhead. Others, including one of its original inventors, feel it is too much overhead. To add some empirical evidence to the discussion, I have coded up a mock up of the improved error_code which can be viewed at https://godbolt.org/g/dDAWih. This demonstrates constexpr error_code and error_category in action as well. To summarise what the mock up demonstrates: 1. error_category() gains a new virtual function called `bool failure(int code)` which is now called by error_code's operator bool. 2. Thanks to the new constexpr construction, the compiler now completely elides from runtime the case where an inlined function returns an error code and the caller acts upon it. As in, **zero code is now generated**. Far better than before. No virtual functions are called, they are optimised out entirely. 3. For unknown error codes from extern sources where the linker is generating an executable, the "final" modifier removes a layer of indirection when calling `failure()` after the linker has run, and indeed clang seems to go ahead and inline the implementation entirely despite us not asking for LTO. Which is kinda cool. 4. Thus only in shared objects, and only for unknown error codes from extern sources, is a virtual function call actually performed. And given the frequency of doing `if(ec) ...`, it'll almost certainly be hot in the branch predictor i.e. no stalls. Question: is this still considered too much overhead? Note that there is no longer ANY proposed breaking change with existing code. This is now 100% enhancement only. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

17 57

[GSoC2018] About Summer Projects of Boost
by 郭兴 17 Jan '18

17 Jan '18

Hi, there, GSoC2018 is coming, I am in my third year of college(bachelor's degree) and want to be enrolled in this interesting program as student. I want to do some contribution for community. Are there some open projects? Maybe I could do some work? I am interested in [geometry], [ublas] and [asio]. I think I could prepare for it from now on. Cheers, Xing GUO

3 2

Re: [boost] Reforming Boost.System and <system_error> round 2
by Andrey Semashev 17 Jan '18

17 Jan '18

On Wed, Jan 17, 2018 at 2:44 AM, Andrzej Krzemienski <akrzemi1(a)gmail.com> wrote: > 2018-01-17 0:29 GMT+01:00 Andrey Semashev <andrey.semashev(a)gmail.com>: >> >> On Wed, Jan 17, 2018 at 1:16 AM, Andrzej Krzemienski via Boost >> <boost(a)lists.boost.org> wrote: >> > 2018-01-16 19:58 GMT+01:00 Andrey Semashev via Boost >> > <boost(a)lists.boost.org> >> > : >> >> >> >> There's nothing ambuguous about the conversion operator, as it is >> >> specified in the standard, and I find the syntax quite intuitive. >> > >> > You say you find the syntax quite intuitive. But do you also find the >> > semantics intuitive? When you type or read `if(ec)` do you interpret it >> > as >> > "if operation failed" or as "if operation returned code of numeric value >> > zero, regardless of the domain and regardless of whether in this domain >> > zero means success or failure"? >> >> The two interpretations are equivalent for me, because in my code >> error code of zero always means "success". Why? Because I pick the >> error values that way (or map them that way, if the values come from >> an external API) so that they play nicely with `error_code` design and >> the rest of the code. >> >> If we support multiple "success" values or non-zero success values, I >> would expect "if (err)" to mean "if some error happened". Why? Because >> that "if" controls error handling, not an arbitrary non-zero result >> handling. I've never seen or written code that does otherwise. >> >> If I want to test for a particular error code, I would write "if (err >> == x)" or "if (err != x)" - that's the syntax that communicates the >> intent to check for the particular value, including when `x` happens >> to be zero (which doesn't really matter, because `x` is always an enum >> value and never a magic number). You may ask the what is the >> difference between "if (err)" and "if (err != success)" and it is that >> the latter only tests for failure in the particular domain. Now, this >> difference may not be obvious, and that is why I generally avoid >> writing "if (err != success)". > > Yes, that would also be my expectation. So, if I understand your position > correctly, you oppose to introducing yet another function `failure(ec)`, but > you would be ok with fixing `if(ec)` so that it always means "failure" (of > course provided that you can be convinced that there is anything that needs > fixing). Yes. Not actively opposed, though. I just don't see the point in having this more verbose syntax for something that we already have and that is more succint. I'm not opposed to adding support for multiple success codes, quite the opposite. My only condition is that this enhancement doesn't penalize too much the existing usages with a single zero success code. > It has been always my understanding that `error_code` is intended to be used > so that the numeric value is always *exactly* the value returned by the > system call: you do not change it, do not adapt it. You keep it unchanged so > that when logged, the programmer can easily retrieve the original number say > from the log file to check what went wrong with the system call. Instead, > you use all this machinery with conditions to perform different queries, on > what kind/sort of failure it was. > > Now, if you adapt the error code so that 0 means success and non-0 means > failure, you are violating this idea that numeric value of `error_code` > should be delivered unchanged, un-adapted. Mapping foreign success codes to zero may be viewed as a hack, but in practice it rarely matters. When you present error codes to the user, you rarely want to present the numeric value. Most likely, you want to present the human-readable result of `message()`, and it will be produced using the mapped error code values. I agree that ideally you would not have to map error codes, but that is an acceptable compromise to have a decent performance and unified syntax with the existing `std::error_code`. Hopefully, if we settle on an efficient solution, we won't have to do this anymore.

1 0

Upcoming formal review of the [Boost.]Yap library
by Louis Dionne 16 Jan '18

16 Jan '18

Hi everyone, The formal review of Zach Laine's 'yap' expression template library will be starting in 3 weeks, from Feb 05 to Feb 14. yap is a C++14-and-later library to build expression templates, much like Boost.Proto currently does. yap uses new features introduced in C++14/17 to make the library simpler to use and compile faster than existing solutions. The documentation is available here: https://tzlaine.github.io/yap The official repository is here: https://github.com/tzlaine/yap We encourage folks to become familiar with the library and submit feedback to the author even before the review starts. Thanks! Louis Dionne (review manager for this submission)

1 0

[convert][align][coroutine2][dll][endian][fiber][metaparse][check_build][qvm] Missing .gitattributes
by Steven Watanabe 15 Jan '18

15 Jan '18

AMDG I noticed that the following submodules have no .gitattributes: convert align coroutine2 dll endian fiber metaparse tools/check_build Also, qvm forces Windows line endings in its .gitattributes In Christ, Steven Watanabe

1 0

Bug report rejected as conformant
by Edward Diener 13 Jan '18

13 Jan '18

I recently reported a preprocessor bug in Oracle C++ 12.6 on their online forum when compiling a C program example. I even cited the C11 standard in showing that Oracle C++ 12.6's actions were non-conformant. The answer I was given, from an Oracle C++ developer who said he was a member of the C++ standard committee, is that since Oracle C++ 12.6 gives a warning message rather than a compiler error the compiler was compliant with the C standard, since the standard only requires a diagnostic message to be considered standard compliant when it does not implement the compiler according to the standard, and that a warning was a diagnostic message. Furthermore since there was a way to force the particular warning to be considered an error, Oracle was not going to change their compiler. At that point I "lost it" so to speak. I cannot conceive that any C/C++ standard would specify that giving a warning rather than an error, when not complying with the C/C++ standard, would then make the compiler compliant. Comments ?

5 11

[git] Git problem with Boost
by Edward Diener 13 Jan '18

13 Jan '18

git checkout develop git pull git submodule update --init from my local main Boost repository gives me: error: no such remote ref 0ce9138ce86095eab9c09d171fecb5f72c4457f7 Fetched in submodule path 'libs/callable_traits', but it did not contain 0ce9138ce86095eab9c09d171fecb5f72c4457f7. Direct fetching of that commit failed.

3 4

Re: [boost] Potential Boost SAX library
by Bjorn Reese 13 Jan '18

13 Jan '18

On 01/09/18 18:36, Oliver Adams via Boost wrote: > I was wondering if a library I'm developing would be of value to the > Boost community. It is basically an event-driven parsing/serialization > library for common formats using a standard internal representation or > simple pass-through conversions. Would anyone be interested in something > like this being added to Boost? There are two kinds of incremental parsers: push parsers (SAX) and pull parsers (approximately StAX.) Briefly put, push parsers traverses the input automatically and generates events for each token it finds, whereas pull parsers traverses the input manually like an iterator and the current token can be queried. Pull parsers have some significant advantages over push parser: * It is straight-forward to implement a push parser on top of a pull parser. This involves a loop and a switch statement (see [1] for a complete example.) Going in the other direction involves the use of coroutines; most likely stateful coroutines. * Contextual parsing can be done directly, unlike push parsers where you have to maintain contextual state in the event handler. * Push parsers can be used directly in Boost.Serialization archives. * Pull parsers are composable. For instance, you could insert a URL pull parser directly into an HTTP pull parser. For a pull parser framework see: https://github.com/breese/trial.protocol The documentation is a bit old though. [1] http://breese.github.io/trial/protocol/trial_protocol/json/tutorial/push_pa…

3 2

Re: [boost] [system] Would it be possible to trial a breaking change to Boost.System and see what happens?
by Bjorn Reese 13 Jan '18

13 Jan '18

On 01/12/18 18:43, Niall Douglas via Boost wrote: > 2. Success becomes solely the default constructed error code, which is > code zero and a new category of "null_category". This is internally > represented by { 0, nullptr }, and thus makes the default constructor > trivial which is highly desirable as it eliminates any compiler magic > static fencing for the default constructor. Right now the default > constructor uses system_category with value 0, and I suspect no code > will notice this change either. Does this mean that custom error categories have to change their make_error_code(e) function to either return a default constructed error_code in case the error value indicates success, or a custom error_code otherwise? In other words, today we do this: namespace my { std::error_code make_error_code(my::errc e) { return std::error(e, my::category()); } } Should that be changed to this? namespace my { std::error_code make_error_code(my::errc e) { if (e == my::success) return std::error_code(); return std::error_code(e, my::category); } }

1 0

[date_time] building documentation?
by James E. King, III 12 Jan '18

12 Jan '18

I cannot build the documentation for Boot.DateTime on the develop tip - I get an error - am I doing something wrong in the command line or is it just broken? jking@ubuntu:~/boost/libs/date_time/doc$ ../../../b2 boostdoc Performing configuration checks - default address-model : 64-bit - default architecture : x86 ../xmldoc/Jamfile.v2:54: in modules.load *** argument error * rule doxygen ( target : sources + : requirements * : default-build * : usage-requirements * ) * called with: ( date_time_autodoc : : <doxygen:param>ENABLE_PREPROCESSING=NO <xsl:param>boost.doxygen.reftitle=Date Time Reference <doxygen.doxproc.title>Date Time Reference <doxygen.doxproc.id>date_time_reference ) * missing argument sources /home/jking/boost/tools/build/src/tools/doxygen.jam:622:see definition of rule 'doxygen' being called /home/jking/boost/tools/build/src/build/project.jam:325: in load-jamfile /home/jking/boost/tools/build/src/build/project.jam:64: in load /home/jking/boost/tools/build/src/build/project.jam:145: in project.find /home/jking/boost/tools/build/src/build/targets.jam:401: in find-really /home/jking/boost/tools/build/src/build/targets.jam:474: in class(a)project-target.find /home/jking/boost/tools/build/src/build/targets.jam:858: in resolve-reference /home/jking/boost/tools/build/src/build/targets.jam:875: in targets.generate-from-reference /home/jking/boost/tools/build/src/build/targets.jam:1226: in generate-dependencies /home/jking/boost/tools/build/src/build/targets.jam:1280: in class(a)basic-target.generate /home/jking/boost/tools/build/src/build/targets.jam:770: in generate-really /home/jking/boost/tools/build/src/build/targets.jam:742: in class(a)main-target.generate /home/jking/boost/tools/build/src/build-system.jam:796: in load /home/jking/boost/tools/build/src/kernel/modules.jam:295: in import /home/jking/boost/tools/build/src/kernel/bootstrap.jam:139: in boost-build /home/jking/boost/boost-build.jam:17: in module scope

3 10

[date_time] [build] new windows class of build error?
by James E. King, III 12 Jan '18

12 Jan '18

I enabled appveyor for Boost.DateTime pull requests and they are failing miserably when <cxxstd> is specified more than once. I don't remember this occurring in the past. This happens on Visual Studio, cygwin, mingw builds. Is this new Boost.Build behavior? https://ci.appveyor.com/project/jeking3/date-time-1evbf/build/1.0.3-develop error: Name clash for '<pstage\lib>libboost_atomic-vc140-mt-x32-1_67.lib' error: error: Tried to build the target twice, with property sets having error: these incompatible properties: error: error: - <cxxstd>14 error: - <cxxstd>17 error: error: Please make sure to have consistent requirements for these error: properties everywhere in your project, especially for install error: targets. Command exited with code 1

2 1

Informal CMake meeting at CPPCon
by Robert Ramey 12 Jan '18

12 Jan '18

Thursday 28 Sept 8 AM at CPPCon a small group of us met to talk a little regarding the situation regarding support of CMake by Boost. I promoted this meeting as I've been concerned that the only discernible results of the recent Boost Steering Committee announcement on the subject was a certain level of antagonism among boost members regarding the subject. Participants ============ Robert Ramey (me) Rene Rivera Vinnie Falco Louis Dionne David Sankel Matt Calabrese This was a small but I think a representative group. After some preliminary back and forth, I think we agreed: a) Nothing was going change regarding the current build system until there was a real alternative in place. b) That we should support serious proposals to implement CMake support within boost. c) And that any such proposals should go through the Boost formal review process. Traditionally, the boost formal review process has never applied to boost tools so this would be a departure from traditional practice. d) Questions regarding the scope/implemention of such support for CMake can be handled within the formal review process. e) Other questions regarding support CMake and Boost, transition to new system, related requirements on boost libraries, etc. can be better addressed once we have some sort of consensus on the form that CMake support will take. I had contacted Paul Fultz who is the only one I know of that has proposed something specific to submit to formal review. He told me he couldn't do it at the time, but shortly there after posted such a request on the list. So I guess for now we're on our way. My motivation for posting this is to keep the boost community up to date on what's happening so that no one gets overly surprised when things start to happen. I'm not really soliciting feedback - though it wouldn't surprise me if I get some. Robert Ramey

9 18

[scope_exit] (Boost >= 1.65) VS 2015 internal compiler error in lambda
by Tobias Loew 12 Jan '18

12 Jan '18

Hi, starting from Boost version 1.65 and using VS 2015 Update 3 (MSVC 19.00) the following code raises an internal compiler error: fatal error C1001: An internal error has occurred in the compiler. (compiler file 'msc1.cpp', line 1468). With earlier Boost versions it compiles fine. Tobias -- Sent from: http://boost.2283326.n4.nabble.com/Boost-Dev-f2600599.html

3 8

Issue with bjam and building for NDK
by Robert Dailey 11 Jan '18

11 Jan '18

I filed an issue over at the Android NDK github page here: https://github.com/android-ndk/ndk/issues/616 When I invoke b2 to build boost using the standalone toolchain generated by the NDK, bjam seems to be wrapping the command in quotes, like "clang++". This throws off their logic in the clang++.cmd batch script. I was asked to test running b2 without quotes (e.g. clang++), but I am not sure how to do this. Could someone help me understand if this is a code change to b2? Or if there's a jam script somewhere I can modify? I'm not sure if this is a boost issue or an NDK issue at this point. I appreciate any help from the boost developers.

2 1

[contract] ready to release
by Lorenzo Caminiti 10 Jan '18

10 Jan '18

Hello release managers & all, Boost.Contract in master is ready to be added to the next Boost release (regression tests pass, docs are updated, etc.). What do I have to do to put https://github.com/boostorg/contract.git master into Boost release 1.67? Thank you. --Lorenzo

2 3

Potential Boost SAX library
by Oliver Adams 10 Jan '18

10 Jan '18

Hi all, I was wondering if a library I'm developing would be of value to the Boost community. It is basically an event-driven parsing/serialization library for common formats using a standard internal representation or simple pass-through conversions. Would anyone be interested in something like this being added to Boost? Thanks.

4 6

[outcome] Training video in post-Toronto std::expected<T, E>
by Niall Douglas 09 Jan '18

09 Jan '18

In preparation for the Outcome v2 review next week, reviewers may find the video of my Meeting C++ talk in Berlin last year useful to watch beforehand. The talk is a literature review covering all the WG21 papers related to the post-Toronto std::expected<T, E>, which is quite different to the Expected during the Outcome v1 review. https://www.youtube.com/watch?v=JfMBLx7qE0I My thanks to Jens for prioritising the release of this video, and for running a great C++ conference. I'm still building a list of errata for the video, once complete I'll post a list underneath it. Any mistakes that I made, please do let me know, ideally with a timestamp offset into the video. My thanks to all those who are currently reporting so many, many bugs in the reference docs. I'll try my best to fix them all before end of next week, but keep them coming! Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

1 0

Re: [boost] seeking endorsement for histogram library
by Bjorn Reese 09 Jan '18

09 Jan '18

I endorse boost.histogram.

6 11

[date_time] recommending upgrading the timezone database
by James E. King, III 07 Jan '18

07 Jan '18

The timezone database in Boost.DateTime doesn't have enough information in it to be accurate all the time. For example if a region changes time zone rules, when applying timezone only the current rule will be applied regardless of the date involved. If a region stops using daylight savings time, but a date/time falls before that rule change, it should still use daylight savings in printed output, correct? The IANA timezone database is more complete, and we could switch Boost.DateTime to use that instead. It is also maintained more frequently than the built-in one, which was last updated 7 years ago, and 4 years before that. Any thoughts on this? https://github.com/boostorg/date_time/issues/67 - Jim

2 1

Adding AppVeyor as a required check to a Boost repository on Github
by Edward Diener 07 Jan '18

07 Jan '18

I am trying to add AppVeyor as a required check to the boostorg/date_time repository on Github. I have gone through the step of adding 'develop' as a protected branch, checking "Require status checks to pass before merging", and checking "Require branches to be up to date before merging". The only thing that then appears in the settings for the protected 'develop' branch is: "Status checks found in the last week for this repository" is "continuous-integration/travis-ci" "required", which is checked. Nothing about AppVeyor whatsoever. Anyone know what the Github voodoo is for getting this to happen ? I see other Boost repository with both Travis-CI and Appveyor required checks but evidently the doc for doing this for AppVeyor is non-existent in Github.

1 0

[hash] Extract module from functional + std::hash_combine
by Daniel James 06 Jan '18

06 Jan '18

Hi, I'm planning to extract hash from functional into its own module, as that will apparently break the circular dependencies that functional is part of. Any objections? Also, any opinions on what the module should be called? 'hash' might suggest a more general purpose hash function, so maybe it should be called something more specific. Daniel

10 29

[date_time] Eliminate pre-1.33.0 io facet code?
by James E. King, III 06 Jan '18

06 Jan '18

There was a bug change around the 1.33.0 release timeframe that added new io facet handling for date_time. It is conditionally disabled using the definition USE_DATE_TIME_PRE_1_33_FACET_IO. I suggested in a github issue that the pre-1.33 mode be removed at this point. Any thoughts on that? https://github.com/boostorg/date_time/issues/61 - Jim

2 1

[outcome v2] Pre-review feedback
by Niall Douglas 05 Jan '18

05 Jan '18

Outcome v2's review starts on Friday 19th January, after which I can't fix even obvious problems. The documentation is by far the newest and most experimental part using bleeding edge tooling, so getting a few rounds of fixes in now before locking everything down for the review would be great. Can those who are super keen have a look at the reference API docs and find problems that me and Jonathan can fix before the review begins? You can find the reference API docs at: https://ned14.github.io/outcome/reference/ And issues can be logged to https://github.com/ned14/outcome/issues or https://github.com/foonathan/standardese/issues if you're sure of the source of the problem. Potential problems to look out for (not a complete list): - Lack of documentation summary string - Confusing or meaningless documentation - Incomplete or mangled documentation for some entity (e.g. sentences missing sections, lines reordered) - Leakage of "detail" namespace or of types or macros clearly of internal implementation detail - Stray or missing commas, angle brackets, brackets - Missing or insufficient requirements, effects or throws clauses - Appearance of any `std::enable_if`, these are supposed to be suppressed into requirements, but I know `outcome.hpp` is particularly bad on that (tracked by https://github.com/ned14/outcome/issues/76) - Lack of hyperlinking to other parts of the reference docs where that was clearly intended. To expand on the "bleeding edge tooling" part, these reference API docs are generated using https://github.com/foonathan/standardese which is based on clang libtooling. Some of the problems are caused by clang libtooling, some by standardese, some by me. I don't doubt that these reference API docs are an enormous improvement over those from doxygen - especially the ability to search semantically for stuff related to search term - but there are a lot of very small problems I'd love to clean up before the formal review begins. Thanks in advance. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

1 0

Changing the website (Was: Need help with bootstrap.bat)
by Andrzej Krzemienski 05 Jan '18

05 Jan '18

2018-01-03 13:54 GMT+01:00 Daniel James via Boost <boost(a)lists.boost.org>: > On 3 January 2018 at 10:04, Andrzej Krzemienski via Boost > <boost(a)lists.boost.org> wrote: > > > (n.b. It was very difficult to find this page as there is no direct link > > from www.boost.org) > > I'll add a link to the 'getting started' section. Maybe we should move > more content onto the github wiki? It's just a git repo with markdown > pages so it shouldn't be too hard to serve it from the website if > people would like it to be more integrated. > Let me share with you my recent experience. I was looking for something like "getting started for Boost developers" and could not find a place.In the front page there is section "INTRODUCTION", but it looks like content for potential users (rather than developers). There is section "DEVELOPMENT" but the content is more like "how to submit a new library", but no "getting started with developement" (on somebody else's library) There is a "WELCOME" -> "Getting started", but it looks like one for the users. (it recommends downloading a zip file). There is this non-obvious path: DEVELOPEMENT -> Reporting and Fixing Bugs. While there, click on "git repositories". It opens a stub page that says it has been superseded by another, and when you push on a link you get there. But this really should be simpler. Maybe in the front page we should have "DEVELOPMENT" -> "Getting Started" that links directly to https://github.com/boostorg/boost/wiki/Getting-Started Or maybe the topics should be divided differently: - Getting started with using Boost Libraries - Getting started with applying improvements to existing Libraries - Getting started with submitting a new library. I consider this more important than where actually the content is hosted. Regards, &rzej;

7 13

[test] Test cases parametrized by both type and value?
by Andrzej Krzemienski 05 Jan '18

05 Jan '18

Hi, Can anyone tell me if Boost.Test can solve the problem that I describe below. I have a function template inspect: ``` template <typename T> bool inspect(T const& v); ``` I want to test if it returns `true` for the following values: 1 (type int) 10 (type int) 1.0 (type double) "Y" (type const char *) Basically, different values of different types, but sometimes different values have the same type. I would like to write one test or "test template" with the following contents: ``` BOOST_TEST((inspect(v))); ``` Where `v` is name of the currently tested value. (But `v`s will have different types). I can emulate this behavior using template test cases and artificial types: ``` struct int_1 { static int value() { return 1; } }; struct int_10 { static int value() { return 10; } }; struct double_1 { static double value() { return 1.0; } }; struct cstr_Y { static const char * value() { return "Y"; } }; typedef boost::mpl::list<int_1, int_10, double_1, cstr_Y> test_types; BOOST_AUTO_TEST_CASE_TEMPLATE( my_test, T, test_types ) { BOOST_TEST(inspect(T::value())); } ``` (See working example in WandBox: https://wandbox.org/permlink/KcJqT8KvL3zIqAxL) But maybe there exists a direct solution in Boost.Test? Where I would just pass a list of values: `{1, 10, 1.0, "Y"}` It is easy to deduce types from values: ``` template <typename... T> mpl::liss<T...> Values(T... values); using test_types = decltype(Values(1, 10, 1.0, "Y")); ``` Does something like this exist, or ois it a reasonable extension? Regards, &rzej;

4 3

[regression] results pages not updating
by Joaquin M López Muñoz 04 Jan '18

04 Jan '18

Hi, Just a heads up, regression tests result pages: http://www.boost.org/development/tests/master/developer/summary.html http://www.boost.org/development/tests/develop/developer/summary.html aren't updating since Jan 1. Thank you, Joaquín M López Muñoz

3 5

Interest for a Fixed Point Arithmetics library
by Julien Vernay 03 Jan '18

03 Jan '18

Hello everybody. I am working on a project that needs and can use fixed point numbers, so I started searching for a library implementing fixed point numbers, but I didn't find anything. So I was wondering if people would need fixed point arithmetics, and here I am. The aim of this FixedPointNumber is to fix the point at compile-time using template, and having another template argument for the underlying type. So we have : template<typename T, size_t N> class FixedPointNumber { T value; public: //interface }; The N last bits of value is the decimal part : so to convert a FixedPointNumber to an int, we need only to use a bitshift operator (and same for construction from int). sizeof(FixedPointNumber<T,N>) == sizeof(T) , so there is no overhead in this implementation. Arithmetic and relational operators will be implemented. Multiplication needs one int multiplication and one bit shift. Division needs one int division and one bit shift. There is only one value for zero. Sign can be extracted with Most Significant Bit. I have already a basic implementation but if it interests more people I will do a proper implementation. Thank you for reading !

4 7

[multiprecision] Help needed with strange constexpr slowdown
by John Maddock 03 Jan '18

03 Jan '18

Folks I have a very strange issue that I need help with understanding, it comes from https://github.com/boostorg/multiprecision/issues/32 but in summary: Given: #include <iostream> #include <boost/multiprecision/cpp_int.hpp> using namespace std; using namespace boost::multiprecision; int main() { __int128_t i =0; __int128_t j =0; int256_t sum =0; for (; i <1e9; i +=19, j +=13) { int256_t diff = j; sum += i * diff; } std::cout <<"Result: " << sum << std::endl; return 0; } There is a 20-30% slowdown when compiled in C++11 or later compared to C++03 with gcc 5.x or 6.x. I've tracked this down to the constexpr default constructor for int256_t (which is called inside operator* to create a temporary for the result), if I make the default constructor non-constexpr by removing BOOST_CONSTEXPR from any of: number.hpp:44 (number()) cpp_int.hpp:1077 (cpp_int_backend()) cpp_int.hpp:501 (cpp_int_base()) cpp_int.hpp: 435 (cpp_int_base::data_type()) Then the slowdown disappears. All the line numbers refer to current develop BTW. gcc-7 is better, but I notice it still generates different code if the constructor is constexpr - that greatly surprises me to be frank - is there something I'm missing about constexpr-ness that could cause this? Confused yours, John. --- This email has been checked for viruses by AVG. http://www.avg.com

3 3

Need help with bootstrap.bat
by Andrzej Krzemienski 03 Jan '18

03 Jan '18

Hi Everyone, Maybe someone can help me with configuring bootstrap.bat. I am trying to set up the environment for developing boost libraries, and it is my understanding that the first step (after cloning a git repository) is to build b2 itself using the script bootstrap.bat. I got this from instructions at https://github.com/boostorg/boost/wiki/Getting-Started (n.b. It was very difficult to find this page as there is no direct link from www.boost.org) I am using MinGW on Windows, no Visual Studio installed. Nonetheless bootstrap.bat concludes that it should compile with cl.exe, and it does not work. I know that MinGWis not supported, but I have to take my chances. Maybe somebody knows how to instruct bootstrap.bat to select a GCC compiler and tools? Regards, &rzej;

5 6

help for contribution
by ashwin.pathak 03 Jan '18

03 Jan '18

Hi Developers, I am very interested in computer programming and I find boost c++ libraries really exciting. I would like to contribute to the organization, I am new to this organization. Can someone please help me to get started in contributing to the organization. Thank you, Best Regards, Ashwin Pathak

1 0

Re: [boost] Boost.HTTPKit, a new library from the makers of Beast!
by Vinnie Falco 01 Jan '18

01 Jan '18

On Sun, Oct 8, 2017 at 5:38 PM, Vinícius dos Santos Oliveira <vini.ipsmaker(a)gmail.com> wrote: > Now, moving on... given that you have __not__ answered how your parser's > design[1] compares to the parser I've developed I'll try to provide more clarity. `beast::basic_parser` is designed with standardization in mind, as I intent to eventually propose Beast for the standard library. Therefore, I have made the interface as simple as possible, exposing only the minimum required necessary to achieve these goals which the majority of users want: * Read the header first, if desired * Feed Asio style buffer sequences into the parser * Set independent limits on the number of header and body octets * Optional fine-grained receipt of chunked body data and metadata The design of basic_parser (the use of CRTP in particular) is meant to support the case where a user implements their own Fields container, or if they want a bit more custom handling of the fields (for example, to avoid storing them). Like all design choices, tradeoffs are made. The details of parsing are exposed only to the derived class. Complexities are hidden from the public-facing interface of `basic_parser`. Implementing a stream algorithm that operates on the parser is a straightforward process: template< class SyncReadStream, class DynamicBuffer, bool isRequest, class Derived> std::size_t read(SyncReadStream& stream, DynamicBuffer& buffer, basic_parser<isRequest, Derived>& parser, error_code& ec) { parser.eager(true); if(parser.is_done()) { ec.assign(0, ec.category()); return 0; } std::size_t bytes_transferred = 0; do { bytes_transferred += read_some( stream, buffer, parser, ec); if(ec) return bytes_transferred; } while(! parser.is_done()); return bytes_transferred; } > [1] at most it hides behind a “multiple people/stakeholders agree with me” > __shield__ There's no hiding going on here. One can only measure the relative success of designs based on the feedback from users. They opened issues, and I addressed their use-cases, sometimes with a considerable amount of iteration and back-and-forth as you have seen in the GitHub issues quoted in the previous message. Now, I don't know if the sampling of users that have participated in Beast's design are representative of the entire C++ community. However, I do know one thing - if GitHub stars are any measure of the sample size of the participants, then Beast is off to a good start. Here's a graph showing the number stars over time received by boostorg/beast, tufao, and Boost.Http (the last 2 libraries having you as the author I believe): <http://www.timqian.com/star-history/#boostorg/beast&BoostGSoC14/boost.http&…> (Note that the HTTP+WebSocket version of Beast was released in May 2016). We need to be careful interpreting results like this of course so perhaps we should look at different metrics. Here are the links to the number of closed issues for Beast, tufao, and Boost.Http: 502 Closed issues in Beast: <https://github.com/boostorg/beast/issues?q=is%3Aissue+is%3Aclosed> 38 Closed issues in tufao <https://github.com/vinipsmaker/tufao/issues?q=is%3Aissue+is%3Aclosed> 13 Closed issues in Boost.HTTP, from 6 unique users not including the author <https://github.com/BoostGSoC14/boost.http/issues?q=is%3Aissue+is%3Aclosed> Again we have to be careful interpreting results like this. But it sure looks like there is a lot of user participation in Beast. If approval from a large number of stakeholders is not a compelling design motivator then what is? > This tutorial is full of “design implications” blocks where I take the time > to dissect what it means to go with each choice. Thus far, no one has asked for more fine grained access to incoming HTTP tokens in the manner of `code::method` and `code::request_target`. If this becomes something that users consistently ask for, it can be done by changing the requirements for the derived class for `basic_parser`. This way, details about HTTP parsing which most people don't care about will not leak into the beast::http:: namespace. Such a change would not affect existing stream algorithms on parsers. Thanks

5 17

Re: [boost] What hash functions should be included in a hypothetical Boost hash-v2 library?
by Bjorn Reese 31 Dec '17

31 Dec '17

On 12/31/17 01:28, Peter Dimov via Boost wrote: > What (non-cryptographic) hash functions should a hypothetical future > Boost hash library contain? Have clear winners emerged by now? Which > ones do people prefer? I vote for FNV hashes: https://en.wikipedia.org/wiki/Fowler%E2%80%93Noll%E2%80%93Vo_hash_function

1 0

What hash functions should be included in a hypothetical Boost hash-v2 library?
by Peter Dimov 31 Dec '17

31 Dec '17

What (non-cryptographic) hash functions should a hypothetical future Boost hash library contain? Have clear winners emerged by now? Which ones do people prefer? SipHash is basically a given, but it's not optimized for speed.

5 6

Removing hash from Boost.Functional broke modules
by James E. King, III 28 Dec '17

28 Dec '17

See: https://github.com/boostorg/type_index/issues/18 There is no forwarding header to keep things compatible. - Jim

2 1

Maintenance of Boost.DateTime
by James E. King, III 28 Dec '17

28 Dec '17

The backlog for Boost.DateTime in trac has over 130 issues; the project is holding on to very old backwards compatibility code (pre-boost-1.33.0 i/o facets), and the CI builds do not currently have appveyor, codecov.io, or coverity scan integration. It needs a proper maintainer in order to resolve these issues, so I would like to ask for that privilege. Thanks, Jim

1 0

Appveyor and Travis CI notifications of Boost library tests
by Edward Diener 26 Dec '17

26 Dec '17

Is there a way to tell Appveyor or Travis CI to send notifications of its Build runs of Boost libraries to someone other than myself ?

4 7

Candidate for 1.66.1, if there is one
by James E. King, III 25 Dec '17

25 Dec '17

In Boost 1.66.0, there was a fix to date_time for the year 2038 problem: https://github.com/boostorg/date_time/pull/35 The serialization code in date_time had no static assertions enforcing the size of data values, and adding proper versioning support was missed in the release by myself and not picked up in the code reviews. As a result, serializing in anything written by earlier boost versions fails for date_time related structures, which might be considered serious enough to justify a 1.66.1 release. (We could also get the latest msvc compatibility in there I suppose...) I'm adding proper versioning right now, however Boost 1.66.0 will remain a problem since it serializes in/out as Version 0 with 64-bit values; and 1.65.1 serializes in/out Version 0 with 32-bit values so I'm not certain there will be a way to detect this issue. The issue is recorded in github here: https://github.com/boostorg/date_time/issues/56 Any additional thoughts are appreciated. I'm looking at adding a test to write out a version 0 and then read it in when the current version is 1, but I don't want to add test-only support code to the headers that get shipped, so if anyone can point me at a current example unit test that writes out a "n-1" version and then reads in a "n" version with boost::serialization I would appreciate it. Thanks, Jim

9 22