January 2019 - Boost - lists.boost.org

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

13 Aug '24

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

49 200

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

07 Aug '19

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

2 3

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

25 May '19

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

2 1

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

12 May '19

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

7 14

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

06 May '19

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

2 1

[test] unit test command-line handling
by Stefan Seefeld 22 Mar '19

22 Mar '19

Hello, this is a question concerning the Boost.Test framework. I'd like to pass command-line arguments to my tests, and I'm unsure of how to proceed. I have found https://www.boost.org/doc/libs/1_68_0/libs/test/doc/html/boost_test/adv_sce…, which shows how to access the command-line programmatically, but that's declared obsolete, and it's also lacking some important info, such as how I should handle the argv vector. Are there any examples that demonstrate this use case ? Specifically: * What (non-deprecated) API can I use to access command-line arguments during test initialization ? * How does my own handling of command-line arguments interact with Boost.Test's own command-line argument handling ? Thanks, Stefan -- ...ich hab' noch einen Koffer in Berlin...

3 8

Integer sorting
by Fenil Mehta 19 Feb '19

19 Feb '19

I have written a sorting algorithm which is way faster than std::sort for all array size. The link is as follows: https://github.com/fenilgmehta/Fastest-Integer-Sort Some guidance would be appreciated on how to improve the project structure and the steps to get it included in boost. Regards, Fenil Mehta

11 24

Feedback desired for reflective enum library
by Nir Friedman 08 Feb '19

08 Feb '19

Hey, I have a reflective enum library available here: https://github.com/quicknir/wise_enum. I've been working on this on and off for a couple of months. I've added features, dealt with various issues, added docs, expanded support through 11-17 and as idiomatically as possible. Overall I think the library is in nice shape (lacks unit tests though, though I do already have a boost license for the code). I feel like a reflective enum is just a very standard requirement in pretty much every codebase I've ever worked on. Simply to be able to reasonably log enums already makes it mandatory. It's also invaluable in configuration, error message alerting, and many other places. There is nothing for this in boost and actually there isn't really much of a standard, standalone solution anyway. The closest is Better Enums ( http://aantron.github.io/better-enums/) but this has some major issues (it doesn't actually create enums but rather enum-like classes, it targets 03). So I think a library like this is needed and my implementation ticks off the major requirements. Feedback on the overall design, any issues, any key features it fails to meet, would be very useful. The library itself is very small and simple so its easy to review. Once it seems like there's some consensus on the core design I'm willing to do the work involved getting it into boost (naming conventions/requirements, directory structure, tests, boost-style docs, etc). Note I'm not on the boost mailing list so please respond directly to this email so I can see! Cheers, Nir

3 4

GSoC 2019
by David Bellot 07 Feb '19

07 Feb '19

Hi Boost community, this year again we applied to the GSoC programm, Google Summer of Code. We hope to be as successfull as usual. I'm taking care of the admin work again this year. I completed an application for Boost on the Google website. It is somehow similar to our successfull applications from previous years. What we need from the community now is the following: 1) if you want to be a backup admin (I will need maybe one or two extra names at most), please let me know and I'll send you an invite. 2) if you wish to be a mentor, please let us know now and if possible on this mailing list so that students will be aware of it too. Don't forget to put the [gsoc2019] tag in the header of your email. You can write your proposals on this wiki: https://github.com/boostorg/boost/wiki/Google-Summer-of-Code:-2019 Ideally, we want to see many proposals before beginning of next week. 3) if you are a student and wants to participate, it's about time to speak loudly on the mailing list to pair with a potential mentor. The sooner the better. You can find ideas from previous years here: https://github.com/boostorg/boost/wiki/Google-Summer-of-Code%3A-Overview Happy coding. David

7 7

find_package(Boost) support
by Peter Dimov 04 Feb '19

04 Feb '19

The current master and develop branches now install the necessary BoostConfig.cmake file (in $prefix/lib/cmake) such that f.ex. the CMake command find_package(Boost REQUIRED filesystem) will find Boost 1.70 using the config file, rather than via FindBoost.cmake (*) (if the Boost installation prefix is in CMake's prefix search path.) Interested parties are invited to test this support and share their experiences. Instead of a Git checkout, you can use the 1.70 release snapshots from https://dl.bintray.com/boostorg/master/ or https://dl.bintray.com/boostorg/develop/, as those better represent what the 1.70 release will contain. (*) Actually, the above command will invoke FindBoost.cmake, but FindBoost will look for a config file as a first step and use that, if found. To disable FindBoost completely, use find_package(Boost CONFIG REQUIRED filesystem) Or, on Windows, assuming the default C:\Boost installation, find_package(Boost REQUIRED filesystem PATHS C:/Boost)

4 4

[thread] Passing function with parameters to boost::barrier
by André Offringa 01 Feb '19

01 Feb '19

Hi Boost developers, I'm having a problem with passing a completion function to a boost::barrier, causing a segfault, and I suspect it is a bug in the barrier code. The following is a minimal example that shows the problem: #include <boost/thread/barrier.hpp> void func(int) { } int main() { boost::barrier b(1, std::bind(func, 42)); b.wait(); } Running inside gdb and doing a bt shows some infinite recursion happening, starting with: #0 0x000055555555e41a in boost::thread_detail::decay_copy<boost::detail::nullary_function<void ()>&>(boost::detail::nullary_function<void ()>&) ( t=<error reading variable: Cannot access memory at address 0x7fffff7feff0>) at /usr/include/boost/thread/detail/move.hpp:355 #1 0x000055555555d814 in boost::detail::nullary_function<void ()>::nullary_function<boost::detail::nullary_function<void ()>&>(boost::detail::nullary_function<void ()>&) ( this=0x7fffff7ff0c0, f=...) at /usr/include/boost/thread/detail/nullary_function.hpp:81 ... When I change "std::bind(func, 42)" to just "func" (and declare func without parameters), it does work and the program exits normally. Passing a lambda to barrier (e.g. barrier(1, [&]() { func(0); } ) ) causes the same segfault, and the same holds when I change std::bind to boost::bind. I'm using Boost 1.67 on Debian Linux, amd64, gcc 8.2.0. Is this a bug? Cheers, André

2 1

[asio]https significantly reduce performance
by lx 31 Jan '19

31 Jan '19

Hi Boost experts: I build a https server from asio example of server2, let it support ssl.we use the codes from: *https://www.boost.org/doc/libs/1_47_0/doc/html/boost_asio/example/http/server2/main.cpp <https://www.boost.org/doc/libs/1_47_0/doc/html/boost_asio/example/http/serv…>* *https://www.boost.org/doc/libs/1_39_0/doc/html/boost_asio/example/ssl/server.cpp <https://www.boost.org/doc/libs/1_39_0/doc/html/boost_asio/example/ssl/serve…>* I complie the codes with boost_1_64 and openssl-1.1.0j, the commed line of complie is: *g++ -g -Wall -o https_server2 *.cpp -I/usr/local/include/ -I/usr/local/openssl-1.1.0j/include -L/usr/local/openssl-1.1.0j/lib -I/usr/local/boost_1_64_0/include /usr/local/boost_1_64_0/lib/libboost_thread.a /usr/local/boost_1_64_0/lib/libboost_system.a -Wl,-Bstatic -lglog -lunwind -Wl,-Bdynamic -lpthread -lcrypto -lssl -ldl -lrt* I test the https_server2 by ngrinder, the TPS is just 400, If I test is just http request , the TPS is 36000. So https significantly reduce performance. The perf top result is: [image: 1.png] The top result is: [image: 2.png] When I test it by http request, the top result is: [image: 4.png] I have push the codes on github. https://github.com/lxlenovostar/Programming_language/tree/master/cpp/test/s… I test 2, 4, 8, 24, 32 threads,but this can't improve the TPS.I test the nginx with 32 worker process, The TPS is about 5000. So maybe lock in asio ? btw: cpu is 32 cores, and Intel(R) Xeon(R) CPU E5-2440 v2 @ 1.90GHz memory is 66GB. os is CentOS 6.5 kernel is 2.6.32 Thank you.

5 6

[gsoc19][astronomy]
by Pranam Lashkari 30 Jan '19

30 Jan '19

Hello everyone, Last year I worked on the new astronomy library[0] and successfully completed GSoC with the help of my mentor *Vinícius dos Santos Oliveira*. In last GSoC, I completed basic coordinate systems and FITS file reading. *Current State of the Library:* Currently, this library has 7 basic astronomical coordinate systems implemented (Alt-Az, CIRS, ICRS, Galactic, Geocentric, Heliocentric, Supergalactic) which as actually wrappers around Boost::Geometry. IO module provides support for FITS reading. Right now, It can read primary HDU and image extensions. Development during GSoC can be found on the master branch[1] To preserve all the development done during the period of GSoC a separate branch was created after completion of GSoC named "gsoc18"[2]. All the development done after the period of GSoC can be found on develop branch[3]. No changes were merged to master after GSoC 18. *Idea for Boost GSoC19:* After communicating with the Boost::geometry community, integration of Boost::geometry and Boost::units is not supported and without using units scientific calculations are not error proof. As a result current coordinate systems can not be used with large projects as there are high possibilities of error. So this year I would like to implement Boost::unit with Boost::astronomy::coordinate to provide a robust astronomical coordinate system. Apart form this I would also complete the remaining parser for the FITS to read complete file including all types of extensions. I am targeting to complete the first coordinate system and FITS reader at the end of this GSoC and making this library ready for its first release. [0]: https://summerofcode.withgoogle.com/projects/5503102778605568 [1]: https://github.com/BoostGSoC18/astronomy/tree/master [2]: https://github.com/BoostGSoC18/astronomy/tree/gsoc18 [3]: https://github.com/BoostGSoC18/astronomy/tree/develop Thank you, Pranam Lashkari

2 2

explicit-failures-markup.xml
by Niall Douglas 30 Jan '19

30 Jan '19

I'm trying to tell the Boost regression matrix that GCC 8 failures are to be expected using explicit-failures-markup.xml, but it seems to not be working: https://www.boost.org/development/tests/master/developer/outcome.html Here is my explicit-failures-markup.xml: <?xml version="1.0" encoding="utf-8"?> <explicit-failures-markup>  <library name="outcome"> <mark-unusable> <toolset name="clang-linux-3*"/> <toolset name="gcc-3*"/> <toolset name="gcc-4*"/> <toolset name="gcc-5*"/> <toolset name="gcc-mngw-3*"/> <toolset name="gcc-mngw-4*"/> <toolset name="gcc-mngw-5*"/> <toolset name="msvc-7*"/> <toolset name="msvc-8*"/> <toolset name="msvc-9*"/> <toolset name="msvc-10*"/> <toolset name="msvc-11*"/> <toolset name="msvc-12*"/> <toolset name="msvc-13*"/> <toolset name="msvc-14.0.*"/> <note author="Niall Douglas">Complete C++14 support is the minimum requirement.</note> </mark-unusable> <mark-expected-failures> <toolset name="gcc-8*"/> <note author="Niall Douglas">GCC 8 currently ICEs with Outcome's unit tests in C++ 17 or later.</note> </mark-expected-failures> </library> </explicit-failures-markup> What am I doing wrong? Thanks, Niall

2 2

[lexical_cast] Assumed internal double conversion of float?
by Brian Kuhl 30 Jan '19

30 Jan '19

Hi Boost experts, We are chasing down some test failures with floats on VxWorks using the Dinkum clib and c++lib. We are testing with clang on Intel and Arm targets and GCC on PowerPC targets. An example failure at the bottom of this email. We have determined that boost::detail::lcast_get_precision<float>() is returning 9, well in access of the defined FLT_DIG of 6, or the practical float limit of 6.92. Specifically this code here: bool shl_real_type(float val, char* begin) { using namespace std; const double val_as_double = val; finish = start + #if defined(_MSC_VER) && (_MSC_VER >= 1400) && !defined(__SGI_STL_PORT) && !defined(_STLPORT_VERSION) sprintf_s(begin, CharacterBufferSize, #else sprintf(begin, #endif "%.*g", static_cast<int>(boost::detail::lcast_get_precision<float>()), val_as_double); return finish > start; } Where does boost::detail::lcast_get_precision<float>() come from, and why is it 9 ? Is it perhaps assuming some intermediate double conversion internally? In Dinkum's C library, Plager conservatively does not promote to a double, when converting to a string. Many thanks, Brian Wind River ->cmd "LD_LIBRARY_PATH=/opt/TestTriggerLocalPath/Workspace/vx7-boost/2019-01-13/vsb/app/boost/fsl_imx6_llvm_up_32_vxWorks/usr/root/llvm/bin;/opt/TestTriggerLocalPath/Workspace/vx7-boost/2019-01-13/vsb/app/boost/fsl_imx6_llvm_up_32_vxWorks/usr/lib/common" [vxWorks *]# cd /opt/TestTriggerLocalPath/Workspace/vx7-boost/2019-01-13/vsb/app/boost/fsl_imx6_llvm_up_32_vxWorks/3pp/BOOST/boost_1_68_0/status [vxWorks *]# run -x -t 0x01000000 -u 100000 -- ../bin.v2/libs/lexical_cast/test/lexical_cast_float_types_test.test/clang-vxworks/debug/cross-compile-vxworks/static-only-on/lexical_cast_float_types_test.vxe Launching process '../bin.v2/libs/lexical_cast/test/lexical_cast_float_types_test.test/clang-vxworks/debug/cross-compile-vxworks/static-only-on/lexical_cast_float_types_test.vxe' ... Process '../bin.v2/libs/lexical_cast/test/lexical_cast_float_types_test.test/clang-vxworks/debug/cross-compile-vxworks/static-only-on/lexical_cast_float_types_test.vxe' (process Id = 0x20482f10) launched. Running 3 test cases... unknown location(0): [4;31;49mfatal error: in "lexical_cast float types unit test/test_conversion_from_to_double": boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::bad_lexical_cast> >: bad lexical cast: source type value could not be interpreted as target [0;39;49m ../libs/lexical_cast/test/lexical_cast_float_types_test.cpp(299): [1;36;49mlast checkpoint [0;39;49m unknown location(0): [4;31;49mfatal error: in "lexical_cast float types unit test/test_conversion_from_to_long_double": boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::bad_lexical_cast> >: bad lexical cast: source type value could not be interpreted as target [0;39;49m ../libs/lexical_cast/test/lexical_cast_float_types_test.cpp(299): [1;36;49mlast checkpoint [0;39;49m

4 3

GSoC 19
by Sandesh Ghanta 30 Jan '19

30 Jan '19

Hey All, I am Sandesh Ghanta, a junior majoring in Computer Science and Engineering. I am interested in contributing to boost and would also like to work with boost in GSoC 19. I am good with C, C++, data structures, algorithms and am currently trying to fix some issues in boost. As I am a beginner to boost I am currently confused as to what project to contribute to, I have been looking at the various issues available to see what I am interested in, but it would be really helpful if someone could guide me. Yours Sincerely, Sandesh Ghanta, FOSS@Amrita <http://amfoss.in> GitHub <https://github.com/sandeshghanta> | Codechef | <http://www.codechef.com/users/sandeshghanta>Codeforces <http://www.codeforces.com/profile/sandeshghanta>

1 0

[gsoc2019] Searching for student
by Damian Vicino 30 Jan '19

30 Jan '19

Hi, I would like to mentor again this year. Some projects I'm particularly interested are getting safefloat or real ready for a formal review (both projects are from previous years and near completion). I'm also open to other projects too. Just ping me with an idea of what you would like to do. Best regards, Damian

1 0

LEAF has been refactored, it now has a much simplified error handling interface
by Emil Dotchevski 29 Jan '19

29 Jan '19

LEAF is a C++11 error handling library for use in low-latency environments. I'm looking for a Boost Review Manager. Any one of you good people willing to volunteer? :) https://zajo.github.io/leaf/ Features: -Header-only, no dependencies. - No dynamic memory allocations. - Any error-related object of any movable type is efficiently delivered to the correct error handler. - Compatible with std::error_code, errno and any other error code type. - Support for multi-thread programming. - Can be used with or without exception handling.

4 10

Wanted to contribute in your projects
by Jibran Zia 29 Jan '19

29 Jan '19

Hello I am Jibran Zia studying in National University of Information and Technology. I wanted to contribute in your projects for 2019 Google summer of Code. Please give me general overview about how I start working and from where I get code of your projects and how I will contribute in it... Thank you so much

2 1

GSOC 19
by Amit Singh 29 Jan '19

29 Jan '19

Hi Sir/Ma'am, My name is Amit Singh and I'm 2nd year CS student. 1. Extending GSoC 18 boost stats idea with regression model and tools for statistics. 2. Expression solver 3.Some features of functional programming similar to transform in c++ which could help programmer to apply functions to whole matrix or vector or transform the data.

1 0

Re: [boost] [histogram] discussion of accessor interface design
by Bjorn Reese 28 Jan '19

28 Jan '19

On 1/15/19 12:35 PM, Hans Dembinski via Boost wrote: > Pros: > - really terse > - you can access methods on the pointee with x->method() as well! (useful when histogram counters are not PODs) > - you can iterate over x to get the indices, for (auto i : x) { … } works Doesn't range-for use operator* so you will get the values? > - since x acts like an array to the indices, you can pass it to functions which accept ranges or iterators (it has .begin() and .end()) > - x can be (and is) enhanced with other useful methods > * x.bin(N) returns the current bin interval for the N-th axis, allowing you to access the central value, width, edges > * x.density() returns the current density (bin value divided by product of current bin widths) > Cons: > - *x and x[0] do completely different things: *x gives you the bin value, x[0] gives you the first index An alternative is to rename x[i] to x.index(i).

2 1

UBSan question
by Raffi Enficiaud 26 Jan '19

26 Jan '19

Hi, I am trying to correct for the errors reported by UBSAN in boost.test. A lot of them were false positive, as ... in boost.test, we check the capacity of the framework to catch various errors in the program. I compile/run the tests with the following: ../../../b2 \ --toolset=clang \ cxxflags=-std=c++11 \ cxxflags=-fno-omit-frame-pointer \ cxxflags=-fsanitize=undefined \ cxxflags=-fno-sanitize-recover=undefined \ cxxflags=-fsanitize-recover=integer-divide-by-zero \ cxxflags=-fsanitize-recover=float-divide-by-zero \ linkflags=-fsanitize=undefined \ linkflags=-fno-sanitize-recover=undefined \ linkflags=-fsanitize-recover=integer-divide-by-zero \ linkflags=-fsanitize-recover=float-divide-by-zero \ linkflags=-fuse-ld=gold \ variant=debug I have an exception that is failing the tests on clang-6/ubuntu18.04 (UBSAN exiting the process), but not on gcc-8/ubuntu18.04 (full log below). UndefinedBehaviorSanitizer:DEADLYSIGNAL ==8303==ERROR: UndefinedBehaviorSanitizer: FPE on unknown address This FPE is happening for instance after reading from a null pointer. I've searched on how to silence/blacklist this, but none of the approaches worked so far, and I am not sure what is provoking this FPE. Is there any UBsan specialist? Does anyone have an idea? Thanks, Raffi clang-linux.compile.c++.without-pch ../../../bin.v2/libs/test/test/system-exception-test.test/clang-linux-6.0.0/debug/threading-multi/visibility-hidden/prg_exec_monitor-ts/system-exception-test.o clang-linux.link ../../../bin.v2/libs/test/test/system-exception-test.test/clang-linux-6.0.0/debug/threading-multi/visibility-hidden/system-exception-test testing.capture-output ../../../bin.v2/libs/test/test/system-exception-test.test/clang-linux-6.0.0/debug/threading-multi/visibility-hidden/system-exception-test.run ====== BEGIN OUTPUT ====== prg_exec_monitor-ts/system-exception-test.cpp:38:15: runtime error: division by zero #0 0x42d03f (/home/bambooagent/bamboo-agent-home/xml-data/build-dir/RS-BCB187-CLAN/library/bin.v2/libs/test/test/system-exception-test.test/clang-linux-6.0.0/debug/threading-multi/visibility-hidden/system-exception-test+0x42d03f) #1 0x42f344 (/home/bambooagent/bamboo-agent-home/xml-data/build-dir/RS-BCB187-CLAN/library/bin.v2/libs/test/test/system-exception-test.test/clang-linux-6.0.0/debug/threading-multi/visibility-hidden/system-exception-test+0x42f344) #2 0x42e8b1 (/home/bambooagent/bamboo-agent-home/xml-data/build-dir/RS-BCB187-CLAN/library/bin.v2/libs/test/test/system-exception-test.test/clang-linux-6.0.0/debug/threading-multi/visibility-hidden/system-exception-test+0x42e8b1) #3 0x43dafa (/home/bambooagent/bamboo-agent-home/xml-data/build-dir/RS-BCB187-CLAN/library/bin.v2/libs/test/test/system-exception-test.test/clang-linux-6.0.0/debug/threading-multi/visibility-hidden/system-exception-test+0x43dafa) #4 0x43a6f2 (/home/bambooagent/bamboo-agent-home/xml-data/build-dir/RS-BCB187-CLAN/library/bin.v2/libs/test/test/system-exception-test.test/clang-linux-6.0.0/debug/threading-multi/visibility-hidden/system-exception-test+0x43a6f2) #5 0x436d13 (/home/bambooagent/bamboo-agent-home/xml-data/build-dir/RS-BCB187-CLAN/library/bin.v2/libs/test/test/system-exception-test.test/clang-linux-6.0.0/debug/threading-multi/visibility-hidden/system-exception-test+0x436d13) #6 0x43726f (/home/bambooagent/bamboo-agent-home/xml-data/build-dir/RS-BCB187-CLAN/library/bin.v2/libs/test/test/system-exception-test.test/clang-linux-6.0.0/debug/threading-multi/visibility-hidden/system-exception-test+0x43726f) #7 0x42d148 (/home/bambooagent/bamboo-agent-home/xml-data/build-dir/RS-BCB187-CLAN/library/bin.v2/libs/test/test/system-exception-test.test/clang-linux-6.0.0/debug/threading-multi/visibility-hidden/system-exception-test+0x42d148) #8 0x42e216 (/home/bambooagent/bamboo-agent-home/xml-data/build-dir/RS-BCB187-CLAN/library/bin.v2/libs/test/test/system-exception-test.test/clang-linux-6.0.0/debug/threading-multi/visibility-hidden/system-exception-test+0x42e216) #9 0x7f648e20fb96 (/lib/x86_64-linux-gnu/libc.so.6+0x21b96) #10 0x405859 (/home/bambooagent/bamboo-agent-home/xml-data/build-dir/RS-BCB187-CLAN/library/bin.v2/libs/test/test/system-exception-test.test/clang-linux-6.0.0/debug/threading-multi/visibility-hidden/system-exception-test+0x405859) UndefinedBehaviorSanitizer:DEADLYSIGNAL ==8303==ERROR: UndefinedBehaviorSanitizer: FPE on unknown address 0x00000042d049 (pc 0x00000042d049 bp 0x7ffe501ec660 sp 0x7ffe501ec630 T8303) #0 0x42d048 (/home/bambooagent/bamboo-agent-home/xml-data/build-dir/RS-BCB187-CLAN/library/bin.v2/libs/test/test/system-exception-test.test/clang-linux-6.0.0/debug/threading-multi/visibility-hidden/system-exception-test+0x42d048) #1 0x42f344 (/home/bambooagent/bamboo-agent-home/xml-data/build-dir/RS-BCB187-CLAN/library/bin.v2/libs/test/test/system-exception-test.test/clang-linux-6.0.0/debug/threading-multi/visibility-hidden/system-exception-test+0x42f344) #2 0x42e8b1 (/home/bambooagent/bamboo-agent-home/xml-data/build-dir/RS-BCB187-CLAN/library/bin.v2/libs/test/test/system-exception-test.test/clang-linux-6.0.0/debug/threading-multi/visibility-hidden/system-exception-test+0x42e8b1) #3 0x43dafa (/home/bambooagent/bamboo-agent-home/xml-data/build-dir/RS-BCB187-CLAN/library/bin.v2/libs/test/test/system-exception-test.test/clang-linux-6.0.0/debug/threading-multi/visibility-hidden/system-exception-test+0x43dafa) #4 0x43a6f2 (/home/bambooagent/bamboo-agent-home/xml-data/build-dir/RS-BCB187-CLAN/library/bin.v2/libs/test/test/system-exception-test.test/clang-linux-6.0.0/debug/threading-multi/visibility-hidden/system-exception-test+0x43a6f2) #5 0x436d13 (/home/bambooagent/bamboo-agent-home/xml-data/build-dir/RS-BCB187-CLAN/library/bin.v2/libs/test/test/system-exception-test.test/clang-linux-6.0.0/debug/threading-multi/visibility-hidden/system-exception-test+0x436d13) #6 0x43726f (/home/bambooagent/bamboo-agent-home/xml-data/build-dir/RS-BCB187-CLAN/library/bin.v2/libs/test/test/system-exception-test.test/clang-linux-6.0.0/debug/threading-multi/visibility-hidden/system-exception-test+0x43726f) #7 0x42d148 (/home/bambooagent/bamboo-agent-home/xml-data/build-dir/RS-BCB187-CLAN/library/bin.v2/libs/test/test/system-exception-test.test/clang-linux-6.0.0/debug/threading-multi/visibility-hidden/system-exception-test+0x42d148) #8 0x42e216 (/home/bambooagent/bamboo-agent-home/xml-data/build-dir/RS-BCB187-CLAN/library/bin.v2/libs/test/test/system-exception-test.test/clang-linux-6.0.0/debug/threading-multi/visibility-hidden/system-exception-test+0x42e216) #9 0x7f648e20fb96 (/lib/x86_64-linux-gnu/libc.so.6+0x21b96) #10 0x405859 (/home/bambooagent/bamboo-agent-home/xml-data/build-dir/RS-BCB187-CLAN/library/bin.v2/libs/test/test/system-exception-test.test/clang-linux-6.0.0/debug/threading-multi/visibility-hidden/system-exception-test+0x405859) UndefinedBehaviorSanitizer can not provide additional info. ==8303==ABORTING EXIT STATUS: 1 ====== END OUTPUT ====== (failed-as-expected) ../../../bin.v2/libs/test/test/system-exception-test.test/clang-linux-6.0.0/debug/threading-multi/visibility-hidden/system-exception-test.run

3 7

Any interest in Compile Time Hash Containers library?
by Ivan Matek 25 Jan '19

25 Jan '19

Hi everybody, my first message, I hope I do not mess this up. I was contemplating writing a Compile Time Hash Containers library and I wrote a test implementation for sets and benchmarked it against mostly ska:: sets since they are the best. Document is here: https://docs.google.com/document/d/1IsUiWl3K0h2pgttYgMt67CxgJ3zeXBKZEA7hvAQ… It is quite long, but it aims to provide a introduction to the problem for people unfamiliar with details of hashing, and also it goes into a lot of discussions, if you care just about the numbers you can skip the "boring parts". My interpretation of benchmarks is that it performs very well in some cases, decently in others, but I am biased. :) Code is not available online since I do not want to dump a test project online without extensive documentation, but if somebody has a problem that may be benefited by this test implementation feel free to let me know, I would be happy to get some real world feedback on prototype. Limitations is that test implementation only works for sets, so no maps and if your objects are not integers you will probably not get much speedup. Also if your set has more than 100ish items GCC will run out of memory and VC++ does not compile code at all, so clang is the only way for most use cases today. One more disclaimer is that I do not want this library to be some beast like ranges that takes years to implement, so if after reading the document you consider implementation quite basic I won't be offended :) In other words I feel that library like this although relatively simple compared to regular Boost libraries can provide quite a lot of benefit for some usecases where people really really care about performance of hash containers where values are known during compile time. I know you can not predict the future of an unimplemented library, but I would be happy with some general feedback, and if you think this library would be nice boost proposal I would be interested in some pointers wrt how to proceed. If somebody wonders how user code looks at the moment: #include "cxhash_set.h" // also could be a result of constexpr function, no need for initializer list static constexpr std::array<int, 20> ints{0,1,2,3,5,8,21,34,64,128,256,512,1024,1701,1729,2048,4096,12345,123456,1234567}; int main() { cxhash_set<ints> ints_set; // contains could(should be?) static, but for now it is "normal" member fn std::cout << std::boolalpha << ints_set.contains(21) << std::endl; std::cout << std::boolalpha << ints_set.contains(22) << std::endl; } P.S. feel free to comment in the google doc, I actually find mailing lists quite limited when it comes to prolonged and or detailed discussions. Maybe we can ping Alexandrescu for an instance of dlang forums, so we get a better discussion tools, and he gets a way to convert us to D. :)

5 7

Status of Boost GSoC 2019?
by Mateusz Loskot 24 Jan '19

24 Jan '19

Hi, (I've asked this David Bellot by email some time ago. No response arrived, so asking here again.) One student asked about GSoC recently [1] but w/o answer. An empty repo for this year has been created. And, the timeline [3] says organizations need to apply by Feb 6. I wonder, what is the status of the preparation for GSoC 2019? [1] https://lists.boost.org/Archives/boost/2019/01/244849.php [2] https://github.com/BoostGSoC19 [3] https://summerofcode.withgoogle.com/how-it-works/ Best regards, -- Mateusz Loskot, http://mateusz.loskot.net <http://mateusz.loskot.net>

1 0

[stacktrace] libbacktrace callback for backtrace_pcinfo invalid return value
by Muazin Mugadr 24 Jan '19

24 Jan '19

Hello all See also: https://stackoverflow.com/questions/54333608/boost-stacktrace-not-demanglin… I am cross compiling boost on Unix for Windows with MINGW. I am using libbacktrace compiled using the same toolchain from here: https://github.com/ianlancetaylor/libbacktrace Digging through the code of libbacktrace I was able to deduce that in a success case the return value of backtrace_pcinfo will be the return value of the callback supplied to that function (for DWARF search). The callback boost is giving looks like this: inline int libbacktrace_full_callback(void *data, uintptr_t /*pc*/, const char *filename, int lineno, const char *function) { pc_data& d = *static_cast<pc_data*>(data); if (d.filename && filename) { *d.filename = filename; } if (d.function && function) { *d.function = function; } d.line = lineno; return 0; } As you can see it will always return 0. This causes an issue with the way the function is called: ::backtrace_pcinfo:( state, reinterpret_cast<uintptr_t>(addr), boost::stacktrace::detail::libbacktrace_full_callback, boost::stacktrace::detail::libbacktrace_error_callback, &data ) || ::backtrace_syminfo:( state, reinterpret_cast<uintptr_t>(addr), boost::stacktrace::detail::libbacktrace_syminfo_callback, boost::stacktrace::detail::libbacktrace_error_callback, &data ); If the symbol is found using backtrace_pcinfo the return value will be 0. If its not found it will be 0. It will always use the value provided by backtrace_syminfo. Is this intended? BR Cromon

1 0