- Boost - lists.preview.boost.org

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