- Boost - lists.preview.boost.org

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