- Boost - lists.preview.boost.org

[GSOC 19] Boost.ublas project Idea
by Amit Singh 02 Feb '19

02 Feb '19

Hi, My name is Amit Singh and I’m a 2nd year student. 1. I have studied last years ublas stats project and before that ublas lacked any statistics features, I would like to take boost.ublas stats further with 1. Linear Regression 2. Logistic Regression 3. Rigid Regression 4. Kernels ( Exponential Kernel, Gaussian Kernel, etc) 5. Correlation (Pearson product-moment correlation, Linear correlation, etc) 2. In ublas there is no expression solver which can solve a expression and assign the value to variable for ex:- A. matrix<double> m = “A^2 * (B * A^-1) + (det(A) * I)”; B. matrix<double> m = “A + 3” ; =>[ m = A + 3*I ] 3. In ublas to modify matrix you have to iterate using for loop. I’m hoping to create a function similar to transform in c++ or map in javascript 1. This is my small machine learning library that I implemented in c++ https://github.com/amitsingh19975/ML Would anybody be interested in mentoring my project for gsoc 19? or help me to improve my project ideas.

1 0

[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 25 Jan '19

25 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

Tests: Runtime type_mismatch after upgrade to 1.69
by Florian Lindner 24 Jan '19

24 Jan '19

Hello, after my distribution rolled out the upgrade to Boost 1.69 I am unable to compile my application anymore. I try to get the log_level set. Minimal compiling example: #define BOOST_TEST_DYN_LINK #include <boost/test/unit_test.hpp> #include <boost/test/unit_test_parameters.hpp> bool init_unit_test() { using namespace boost::unit_test; auto logLevel = runtime_config::get<log_level>(runtime_config::btrt_log_level); return true; } int main(int argc, char* argv[]) { int retCode = boost::unit_test::unit_test_main( &init_unit_test, argc, argv ); return retCode; } which compiles fine g++ -std=c++11 -lboost_unit_test_framework boosttesting.cpp but gives an runtime error: % ./a.out Test setup error: boost::runtime::arg_type_mismatch: Access with invalid type for argument corresponding to parameter log_level Thanks! Florian

1 0

C++Now 2019 Registration is Open
by Jon Kalb 24 Jan '19

24 Jan '19

Boosters, Registration for C++Nows 2019 (aka BoostCon) is now open: http://cppnow.org/announcements/2019/01/2019-registration-is-open/ Please help us to spread the word about this announcement. Thanks. Note that the Aspen Meadows Resort online registration link is also up on the lodging page. Because there will be another group in the hotel, we’ve been allocated fewer rooms this year. Please either reserve a room very soon or plan to stay at the Lamplighter or another hotel in town. See you in Aspen in May. Jon

1 0

[gsoc19][GIL] Project proposal
by Miral Shah 23 Jan '19

23 Jan '19

Hello everyone, I am Miral Shah a computer engineering student from India. I have been talking with Boost.GIL community on GIL's Gitter channel since last few weeks to come up with the new idea for GSoC19. After many suggestions and a long discussion on various ideas with the contributors, we have come up with the idea to expand the GIL by introducing new image processing algorithms into it. I would also like to thank Stefan Seefeld and Mateusz Loskot for their guidance and support. Proposal idea can be found here: https://github.com/boostorg/gil/wiki/GSoC-2019 Thank you, Miral Shah

1 0

Boost log issues and workarounds
by hh h 21 Jan '19

21 Jan '19

Hi, I like the boost log, but there are many small issues, appreciate your kind help: I followed the following link to use a good macro LOG: https://stackoverflow.com/questions/35895199/boost-log-and-severity-local-a… But calling LOG(error) caused much trouble for the name space collision, alternative is to use full namespace boost::log::trivial::error, but that is too cumbersome,I tried to use an uppercase ERROR to replace it in an enum ERROR = boost::log::trivial::error, obviously that could not be complied, although it is defined as enum severity_level in trivial.hpp, it does not look like the boost::log::trivial::error is an enum value. Any workarounds? Another issue from that link is it has to call LOGGABLE prior to call LOG(error) in each function, that makes more clumsy, software developers in my team are not happy about it. Any workaround to have a fixed argument in BOOST_LOG_STREAM_WITH_PARAMS, without need to claim boost::log::sources::severity_logger<boost::log::trivial::severity_level> slg; in each function? You guys are genius that must be a way to do it, appreciate your advice. Thank you

4 22

[lockfree] wait-free multi-queue?
by Shawn Yarbrough 18 Jan '19

18 Jan '19

Is it practical to have a wait-free, multi-producer/multi-consumer queue? I ask because Boost's Lockfree multi-queue is only advertised as being "lock-free". (Boost does offer a wait-free single-queue.) https://www.boost.org/doc/libs/1_69_0/doc/html/lockfree.html Shawn Y.

2 1

Re: [boost] [parameter] Helping user libraries adjust to recent changes in GitHub develop branch
by Cromwell Enage 17 Jan '19

17 Jan '19

Happy New Year, everyone! > I've been contributing upgrades to Boost.Parameter functionality > and documentation in the GitHub develop branch for the past > couple of months. These upgrades include the addition of code > generation macros for Boost.Parameter-enabled function call > operators and support for perfect forwarding, and more upgrades > are yet to come. It's been an enjoyable experience so far, > but understandably there are some growing pains. I've taken > pains to ensure that as long as user libraries access only the > public interface of Boost.Parameter, they won't be affected by > the changes. However, there are several notable libraries that > currently use non-public portions of Boost.Parameter, so > whenever possible I've submitted PRs to those libraries that > either change the usage to access only public portions > (preferred) or make quick fixes (temporary). Update: As of this writing, I have active PRs for the following libraries: Boost.Accumulators Boost.Convert Boost.Graph Boost.Log AFAIK, these are the libraries most directly affected by the changes. To reiterate: I'm willing to help the library maintainers resolve these issues as quickly as possible. I should be able to answer any questions you have about the changes to Boost.Parameter. Cromwell D. Enage

3 2

[histogram] discussion of accessor interface design
by Hans Dembinski 15 Jan '19

15 Jan '19

Dear all, work on boost.histogram is progressing fast. I am still implementing feedback from the review, simplifying the interface, adding requested features, such as axes that can grow. STL compatibility was further improved, you can now also write to histograms via iterators. The normal iterators make sense when you iterate over a 1D histogram. When you iterate over a multi-dimensional histogram, you also want to know the current multi-dimensional index. After considering many options, and I really thought about this a lot, I went for the following design, which is a bit unusual. Therefore I would appreciate feedback. I think it is great, once you overcome an initial feeling of awkwardness. The accessor class is "polymorphic", it behaves like a pointer to the histogram value, and like an array for the multi-dimensional index. In code, this is how you use it: auto h = make_histogram(…) // make 2D histogram for (auto && x : indexed(h)) { // indexed produces a range of accessors // x is a special accessor type, combining two non-overlapping concepts // - it acts like a pointer to the histogram value // - it acts like an array to the current index std::cout << "current value " << *x << std::endl; // "dereference" to get value std::cout << "current index " << x[0] << " " << x[1] << std::endl; // use subscript operator to get index } This syntax is beautifully terse, e.g. see https://github.com/HDembinski/histogram/blob/develop/examples/guide_access_… for a full example, especially line 66. 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 - 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 The last point is, of course, where people have a problem. But if you take C++ concepts seriously then the accessor is a perfect model of a pointer and a perfect model of an array. These two roles are non-overlapping and they have non-overlapping sets of interfaces, which I exploit here. If you have the expectation that *x and x[0] should do the same thing, it is so because of C. C has no extensive type system like C++ and does not distinguish between arrays and pointers, although these are very different concepts. A pointer points to a value, and an array is a collection of values. "dereferencing" a collection of values makes no sense, we are just used to it because of our C heritage. C++ has a better type system, and better classes for pointers and arrays than raw pointers. The stdlib authors recognize that *x has no meaning when x is a sequence of values. *x fails when x is a std::vector, std::deque, std::list, or any kind of collection in the stdlib. Even for std::unique_ptr, they made sure that the interfaces for the pointer-to-object and pointer-to-array specializations behave differently: ``` #include <memory> int main() { std::unique_ptr<int> p(new int); // pointer version // p[0]; // fails *p; // OK std::unique_ptr<int[]> a(new int[3]); // array version // *a; // fails a[0]; // OK } ``` Once you accept that the two concepts of pointers and arrays have non-overlapping interfaces in C++, it becomes possible to make a combined object which has both interfaces, and uses these two sets to return different information. If you have read this far, I hope your initial reaction of "woah, this looks really inconsistent and confusing!" turned to "hmm, maybe it is not inconsistent after all". I am looking forward to hear your thoughts. Best regards, Hans PS: The alternative would be to return a std::pair<index_type, value_reference_type>, but this has disadvantages. Unpacking the pair is going be nice in C++17 with structured bindings, but not so much in C++14. Also, it prevents me from adding convenience methods, like the above-mentioned bin(N) and density() methods.

1 0

boost log to concatenate just one log file
by hh h 15 Jan '19

15 Jan '19

Hi, I added boost::log::keywords::open_mode = std::ios_base::app to the log configuration, but it did not stop log file proliferation, every time I started the program, it created a new log file mylog.log0000x, how can I stop creating new logs? Thank you.

2 2

Is it possiable to use a simple LOG(info) in boost log?
by hh h 15 Jan '19

15 Jan '19

Hi, After trying many days on boost log, still have many issues. Google log has a nice LOG(INFO) << "debug";, looks like that kind thing cannot do in boost log, the close online code in https://stackoverflow.com/questions/35895199/boost-log-and-severity-local-a… has to call LOGGABLE first then to use LOG(info) << "my log", it is really cumbersome, is it possible to call LOG(info) like glog? Thank you.

1 1