January 2018 - Boost - lists.preview.boost.org

Change Trac wiki permissions
by David Bellot 17 Jan '18

17 Jan '18

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

2 2

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

17 Jan '18

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

17 57

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

17 Jan '18

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

3 2

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

17 Jan '18

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

1 0

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

16 Jan '18

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

1 0

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

15 Jan '18

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

1 0

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

13 Jan '18

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

5 11

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

13 Jan '18

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

3 4

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

13 Jan '18

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

3 2

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

13 Jan '18

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

1 0