May 2017 - Boost - lists.preview.boost.org

[units] Compilation fails on quantity copy-construction
by Pavel Kretov 31 May '17

31 May '17

Hi all! I'm trying to make use of Boost.Units in a simple FDTD simulation program, but found a strange behavior of some kind. Consider the following demonstration example where I try to calculate time step from spatial steps according to the CFL condition [1]: #include <iostream> #include <boost/units/physical_dimensions.hpp> #include <boost/units/systems/si.hpp> #include <boost/units/cmath.hpp> #include <boost/units/io.hpp> int main() { namespace bu = boost::units; namespace si = boost::units::si; using dimless = bu::quantity<si::dimensionless, float>; bu::quantity<si::length, float> dx = 1.0f * si::meter, dy = 1.0f * si::meter; bu::quantity<si::velocity, float> v = 1.0f * si::meter_per_second; bu::quantity<si::time, float> dt = 0.5f / (v * bu::sqrt(1.0f/(dx*dx) + 1.0f/(dy*dy))); std::cout << dt << std::endl; } The code looks okay to me, but when I try to compile it, I get a scary error message: main.cpp:20:19: error: no match for ‘operator/’ (operand types are ‘float’ and ‘<THE_TERROR_THAT_FLAPS_IN_THE_NIGHT>’) dt = 0.5f / (v * bu::sqrt(1.0f/(dx*dx) + 1.0f/(dy*dy))); ~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ where the second operand type looks like boost::units::multiply_typeof_helper< boost::units::quantity< boost::units::unit< [{length_base_dimension, static_rational<1l>}, {time_base_dimension, static_rational<-1l, 1l>}], boost::units::si::system, float>, boost::units::quantity< boost::units::unit< [{length_base_dimension, static_rational<-1l, 1l>}], boost::units::si::system, double>>::type In the above expression [{}, {}, ...] is a pseudo-code for static head-tail list of boost::units::dim<Unit, Rat> pairs. Note the 'double' type materialized from barely nowhere: the code explicitly defines everything as 'float', it's the 'bu::sqrt' to blame for it to appear. Note that replacing 'bu::sqrt' with 'bu::pow<1, 2>()' does not help. As I didn't feel happy with the above error message, I mutated the code a bit and made it to work with: bu::quantity<si::time, float> dt; dt = dimless(0.5f) / (v * bu::sqrt(1.0f/(dx*dx) + 1.0f/(dy*dy))); I had to both (a) add 'dimless', and (b) separate variable declaration and definition. Doing only (a) didn't help. Mkay, but what if I need to have a const quantity? (I'm a big fan of making everything 'const'!). The only one thing I could do was to roll out my own 'sqrt' and 'pow' functions. Here they are: #include <boost/units/get_system.hpp> #include <boost/units/get_dimension.hpp> #include <boost/units/static_rational.hpp> #include <boost/units/quantity.hpp> #include <boost/units/dimension.hpp> template<typename Unit, int N, int M = 1> using static_power_helper = boost::units::unit< typename boost::units::static_power< typename boost::units::get_dimension<Unit>::type, typename boost::units::static_rational<N, M>::type>::type, typename boost::units::get_system<Unit>::type>; template<int N, typename Unit, typename Y> auto ratpow(boost::units::quantity<Unit, Y> const &x) -> boost::units::quantity<static_power_helper<Unit, N>, Y> { using std::pow; return decltype(ratpow<N>(x))::from_value(pow(x.value(), N)); } template<int N, int M, typename Unit, typename Y> auto ratpow(boost::units::quantity<Unit, Y> const &x) -> boost::units::quantity<static_power_helper<Unit, N, M>, Y> { using std::pow; return decltype(ratpow<N, M>(x))::from_value(pow(x.value(), (Y) N / M)); } template<typename Unit, typename Y> auto msqrt(boost::units::quantity<Unit, Y> const &x) -> decltype(ratpow<1, 2>(x)) { return ratpow<1, 2>(x); } Using them I was able to compile the original form of the expression (as seen in the very first listing): bu::quantity<si::time, float> const dt = 0.5f / (v * msqrt(1.0f/(dx*dx) + 1.0f/(dy*dy))); The questions: 1. Is it possible to work around the problem without custom 'sqrt'? 2. Is the described behavior intentional, -or- Is there an error in Boost.Units' implementation of 'sqrt'? 3. If the 'boost::unit::sqrt' is fine, is there something wrong with my implementation? ――― Pavel K. [1]: https://en.wikipedia.org/wiki/Courant-Friedrichs-Lewy_condition

2 1

[poly_collection] Questions about merging into Boost
by Joaquin M López Muñoz 31 May '17

31 May '17

Boost.PolyCollection was recently accepted into Boost and I'm planning to integrate it into https://github.com/boostorg/ asap to begin test cycling. I am not sure if the lib will be in a good enough shape for launching with Boost 1.65, though. Questions: 1. The current repository is https://github.com/joaquintides/poly_collection , which has branches master (code) and website (for the online docs). Is the following the right procedure for integration with Boost? a. Rename master to develop (https://gist.github.com/lttlrck/9628955 ) b. Transfer repo to boostorg (https://help.github.com/articles/about-repository-transfers/ ) c. Ask for write permission to github.com/boostorg/poly_collection 2. Can the repo not have a master branch until I decide the lib is ready for launch? Will this result in poly_collection simply not being in Boost releases while still develop tests are cycling? Thank you, Joaquín M López Muñoz

4 4

[outcome] Andrzej's review
by Andrzej Krzemienski 31 May '17

31 May '17

Hi Everyone, This is my review of Boost.Outcome library. First, I want to thank Niall for taking the effort to write the library, promoting it, sharing with the community, and submitting for Boost review. I think that the library has already proven useful regardless of this review's outcome (or should I say 'result'). I recommend to REJECT the library at this point, and encourage the author to re-submit it after the list of what I consider issues -- described below -- has been addressed. Why reject and not conditionally accept? It is possible to say that I accept the library if this "delta" is applied to the current submission's state. Niall has indicated a couple of times that he is willing to apply even big changes, if this is what reviewers wish. But the amount of change that would be required, plus the uncertainty what the "delta" actually is, plus a general confusion as to what library is for, as reported by others (the effect of the current shape of documentation), in total make the conditional acceptance too fragile. What are we reviewing? It would be fair to assume that we are reviewing the master branch, SHA 4851926c1c601c0e9391b2d0d07fb17f634b3ecb, but there is also a "delta" described by Niall in high-level in one of the messages: http://boost.2283326.n4.nabble.com/outcome-High-level-summar y-of-review-feedback-accepted-so-far-td4694767.html. So maybe the master + that delta. It describes that we will have like 10 types, like outcome_e, checked_outcome_e, etc.. Now in another thread I hear there will only be 5 types: optional_outcome and outcome. This makes me believe that the compromise solutions and promises are being made in a hurry, and this will likely result in (1) suboptimal design and (2) misunderstandings as to what we are actually agreeing to. Am I knowledgeable about the problem domain? If the domain is "reporting function failures in predictable-latency environments", then no, I have no experience with this domain. I also have no experience with `expected`, although having worked on formal specification of `std::optional` I am familiar with a number of issues that `expected` also needs to solve. Also, a number of controversies revolves around git sub-modules, dual licensing and Boost distribution process. I do not feel competent in this area either. How much effort did I put into the evaluation? I have read a number of versions of the documentation. Had a long email exchange with Niall in order to understand what the library does. I had a glimpse at the source code to figure out the pieces that were missing from documentation. I have tried running my own test examples on GCC 6.3.0 with MinGW w64 5.0.0 (doesn't work) and GCC 6.3.1 on Fedora (works fine). Is the library useful? Yes. Apparently it solves an important problem in predictable-latency environments. This is confirmed by the user base the library already has managed to acquire. It provides an implementation of the to-be standardized `exceptional`, which allows for experimentation. I believe Boost would benefit from including this library (after the issues have been resolved). I am confident Niall has knowledge about problem domain. Documentation. It has two serious deficiencies. It lacks an introductory part that would clearly and shortly describe what problem the library is solving an how, how can I use it and when should I use it. It is also missing a reference with documented semantics. One cannot tell what outocme's default constructor does, or what function error() does when you have an exception_ptr inside. I believe Niall when he says his users do not need this documentation: they immediately grasp what and how it is doing. But of the Boost library I expect a high-quality documentation. I think that these deficiencies in the documentation prevent a successful review of the library. I bet there are people who were put off by the docs and will not proceed to reviewing the library further, even though they could have given you many valuable insights, or point out defects. Some will stop at criticizing the docs. Any potential flaws in the library will not even be revealed. This may be the reason why things like ring buffer were not opposed: the potential critics may have not gotten that far. This is one of the reasons that I would recommend fixing the docs and staring the review again without the distraction. On the other hand, there is a lot of useful material in the documentation. For sure it is a way better that the original versions. For instance, the usage of ring buffer is documented clearly. Design. The idea to represent either a returned value or a reason for the lack thereof as `variant<T, error_code, exception_ptr>` is sound. Fixing the `E` to a single type is sound. using_error_code extended (along with ring buffer) for carrying payload is sound. I also like the fact that you only have three "monads": `outcome`, `result` and `expected`, and that they are maximally different: expected and result make the opposite decision on practically any aspect. This is a reasonable compromise between many possible combinations of micro-decisions, and the expectation to have a small number of types. `option` should go, I think. I can think of no use case for it. However, the design still changes throughout the review, and has not stabilized yet. The last message is that we may have varieties for narrow versus wide contract or we will have duplicated observers, and this has not been settled on yet. The consequence of using the ring buffer, where the error message can suddenly disappear is unfortunate, but then again, I know of no way to make it better. It might be the best choice of those available. I wish someone from low-latency users stepped in and commented on whether this is the right choice and whether the choice of these particular members (a short string, two unsigned ints) is the optimum in practice. Some aspects of design, to me seem unclear. E.g., what does it mean that `outcome` has value but I am calling `o.error()`? Is it a programmer error, which the function is trying to conceal, or does `o.error()` mean "convert `outcome` to `error_code`, whatever the state? Similarly, when `exception()` also recognizes error_codes, and `error()` does not recognize exception_ptrs looks quite random: I cannot see a mental model behind it. You could document detailed semantics of each function, but this would not be enough. I need a clear mental model, like "every error_code or exception_ptr is collectively called 'exception' in this library". If you do not support `outcome<T&>, I need a clear indication of it and a rationale. Implementation. These dual licensing, testing and git sub-module issues. I am not an expert in how Boost is organized, but a number of people I consider qualified have reported strong objections, and this has to be considered. A Boost library must be compliant with "the way things work in Boost" even if it is felt that things work wrong in Boost. I did not look much, at the implementation, but it looks acceptable on the surface. The assignment (most tricky part, I think) is implemented quite clearly. Sometimes static_assert's constrain too much. A non-default-constructible types should be allowed. Types that throw upon copy/move construction should be allowed provided I do not call the assignment on outcome/expected. I am told `outcome<error_code>` does not work. I am not sure if this is fortunate. It is no longer an `outcome<T>` that works for any Regular T. What if I have a function that optains an error_code and might potentially fail. How can I express this in the interface? (Or do I have to wrap in `outcome<unique<error_code>>`?) `outcome` has function swap overloaded in namespace std. I am not sure if it is legal, but even if so, I would recommend implementing it in `outcome`'s namespace, in order not to mess with `std`. Again, thanks Niall for this library, and for a very educational discussion. Regards, &rzej;

2 1

[units] Compilation fails on quantity copy-construction
by Pavel Kretov 31 May '17

31 May '17

Hi all! I'm trying to make use of Boost.Units in a simple FDTD simulation program, but found a strange behavior of some kind. Consider the following demonstration example where I try to calculate time step from spatial steps according to the CFL condition [1]: #include <iostream> #include <boost/units/physical_dimensions.hpp> #include <boost/units/systems/si.hpp> #include <boost/units/cmath.hpp> #include <boost/units/io.hpp> int main() { namespace bu = boost::units; namespace si = boost::units::si; using dimless = bu::quantity<si::dimensionless, float>; bu::quantity<si::length, float> dx = 1.0f * si::meter, dy = 1.0f * si::meter; bu::quantity<si::velocity, float> v = 1.0f * si::meter_per_second; bu::quantity<si::time, float> dt = 0.5f / (v * bu::sqrt(1.0f/(dx*dx) + 1.0f/(dy*dy))); std::cout << dt << std::endl; } The code looks okay to me, but when I try to compile it, I get a scary error message: main.cpp:20:19: error: no match for ‘operator/’ (operand types are ‘float’ and ‘<THE_TERROR_THAT_FLAPS_IN_THE_NIGHT>’) dt = 0.5f / (v * bu::sqrt(1.0f/(dx*dx) + 1.0f/(dy*dy))); ~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ where the second operand type looks like boost::units::multiply_typeof_helper< boost::units::quantity< boost::units::unit< [{length_base_dimension, static_rational<1l>}, {time_base_dimension, static_rational<-1l, 1l>}], boost::units::si::system, float>, boost::units::quantity< boost::units::unit< [{length_base_dimension, static_rational<-1l, 1l>}], boost::units::si::system, double>>::type In the above expression [{}, {}, ...] is a pseudo-code for static head-tail list of boost::units::dim<Unit, Rat> pairs. Note the 'double' type materialized from barely nowhere: the code explicitly defines everything as 'float', it's the 'bu::sqrt' to blame for it to appear. Note that replacing 'bu::sqrt' with 'bu::pow<1, 2>()' does not help. As I didn't feel happy with the above error message, I mutated the code a bit and made it to work with: bu::quantity<si::time, float> dt; dt = dimless(0.5f) / (v * bu::sqrt(1.0f/(dx*dx) + 1.0f/(dy*dy))); I had to both (a) add 'dimless', and (b) separate variable declaration and definition. Doing only (a) didn't help. Mkay, but what if I need to have a const quantity? (I'm a big fan of making everything 'const'!). The only one thing I could do was to roll out my own 'sqrt' and 'pow' functions. Here they are: #include <boost/units/get_system.hpp> #include <boost/units/get_dimension.hpp> #include <boost/units/static_rational.hpp> #include <boost/units/quantity.hpp> #include <boost/units/dimension.hpp> template<typename Unit, int N, int M = 1> using static_power_helper = boost::units::unit< typename boost::units::static_power< typename boost::units::get_dimension<Unit>::type, typename boost::units::static_rational<N, M>::type>::type, typename boost::units::get_system<Unit>::type>; template<int N, typename Unit, typename Y> auto ratpow(boost::units::quantity<Unit, Y> const &x) -> boost::units::quantity<static_power_helper<Unit, N>, Y> { using std::pow; return decltype(ratpow<N>(x))::from_value(pow(x.value(), N)); } template<int N, int M, typename Unit, typename Y> auto ratpow(boost::units::quantity<Unit, Y> const &x) -> boost::units::quantity<static_power_helper<Unit, N, M>, Y> { using std::pow; return decltype(ratpow<N, M>(x))::from_value(pow(x.value(), (Y) N / M)); } template<typename Unit, typename Y> auto msqrt(boost::units::quantity<Unit, Y> const &x) -> decltype(ratpow<1, 2>(x)) { return ratpow<1, 2>(x); } Using them I was able to compile the original form of the expression (as seen in the very first listing): bu::quantity<si::time, float> const dt = 0.5f / (v * msqrt(1.0f/(dx*dx) + 1.0f/(dy*dy))); The questions: 1. Is it possible to work around the problem without custom 'sqrt'? 2. Is the described behavior intentional, -or- Is there an error in Boost.Units' implementation of 'sqrt'? 3. If the 'boost::unit::sqrt' is fine, is there something wrong with my implementation? ――― Pavel K. [1]: https://en.wikipedia.org/wiki/Courant-Friedrichs-Lewy_condition

1 0

[config] C++17 macros wanted
by Tal Lancaster 31 May '17

31 May '17

I have been adding C++17 features to date_time. There are two config macros, I would like to have: Test for C++17’s constexpr inline feature. Maybe call it something like: BOOST_NO_CXX17_CONSTEXPR_INLINE Test for C++17’s structured binding feature. Maybe call it something like: BOOST_NO_CXX17_STRUCT_BIND

3 7

[outcome] How to drop the formal empty state
by Niall Douglas 31 May '17

31 May '17

There has been a fair bit of review feedback that people don't like the formal empty state in outcome<T> and result<T>. I still think this opinion daft, just because it's there doesn't mean you have to use it, but here are some options: 1. Like Expected, we could require the E types to provide a nothrow move constructor. This would allow us to guarantee no empty state, not ever. Default constructing an outcome<T> or result<T> would set a default constructed T state, just like Expected. The only remaining difference now between result<T> and expected<T> would be the wide vs narrow observer functions. outcome<T> still can also carry a std::exception_ptr. 2. We could do the above, but default constructor constructs to some constexpr undefined state that is not state T nor E. 3. We could only provide a guarantee of no empty state if the E types provide nothrow move construction, but if they do not we fall back to an empty state arising if throws occur during assignment. 4. The option for an empty state becomes a template parameter defaulted to false i.e. disabled. This can be combined with any of the above. Thoughts? Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

6 47

[review] Review of Outcome (ends Fri-June-2)
by charleyb123 . 31 May '17

31 May '17

Reminder -- On Fri-26-May the Review Wizards approved extending the Outcome review until Fri-02-June. (Notification was sent to the list, but considering the high traffic volume lately, one can be forgiven for having missed that message.) Thank you to everyone for your tremendous efforts in taking part in the review; for keeping up with high message traffic; and for the professional and deep exploration of the many (very broad!) topics touched on during this review. The review continues for several more days, ending Fri-02-June (it will not be extended further). Please consider posting a review to the boost mailing list, or privately to the Review Manager (to me). Here are some questions you might want to answer in your review: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? And most importantly: - Do you think the library should be accepted as a Boost library? For more information about Boost Formal Review Process, see: http://www.boost.org/community/reviews.html Thank you very much for your time and efforts. --charley

3 2

[gil] where is the mysterious boost::gil::read_image function?
by Frédéric Bron 31 May '17

31 May '17

I would like to read a jpeg image from a memory location, not from a file. According to this post http://boost.2283326.n4.nabble.com/gil-io-new-review-Reading-images-from-in… there is a boost::gil::read_image(input_stream, image, image_tag) function but I cannot find it in the header files. Thanks, Frédéric

1 0

[future.then] Should deferred continuation respect status of original future?
by Tomas Sturm 31 May '17

31 May '17

Hi, consider this code that wraps some library returning a future: // some async library boost::future<intermediate> DoLongAsyncTask() { return myPromise.get_future(); } // intermediate translation layer boost::future<result> GetResult() { return DoLongAsyncTask().then([] (boost::future<intermediate> f) { return TranslateToResult(f.get()); }); } // client event loop void RunInClientContext() { auto myFuture = GetResult(); while (stuffToDo()) { doStuff(); if (SafeToCallFutureGetWithoutBlocking(myFuture)) ProcessResult(myFuture.get()); } } What should the implementation of 'SafeToCallFutureGetWithoutBlocking' be? Normally, one would write something like: myFuture.is_ready() or myFuture.wait_for(chrono::seconds(0)) != future_status::timeout But this doesn't work in case the implementation of intermediate translation layer calls .then with launch::deferred! In Boost 1.63 the future returned from .then(launch::deferred, ...) is always deferred, so wait_for(...) always returns deferred no matter what (and is_ready() always returns false). In fact, there is no way to implement 'SafeToCallFutureGetWithoutBlocking' if the translation is to happen in the context of the client (launch::deferred). Wouldn't it be more natural to respect the status of the original future in this case? The documentation is already very clear that the continuation is executed only after the original future is ready. So in case a client asks whether the continuation future is ready, and the original future is not ready yet, the call should forward to the original future instead. What I propose is this: promise<int> p; future<int> f1 = p.get_future(); future<int> f2 = f1.then(launch::deferred, [] (auto f) { return f.get(); }); assert(f2.wait_for(0) == future_status::timeout); p.set_value(42); assert(f2.wait_for(0) == future_status::deferred); Is there any reason for the continuation future to not behave this way? Regards Tomas

2 1

[outcome] narrow-contract, wide-contract, and value_if
by Andrzej Krzemienski 31 May '17

31 May '17

Hi Everyone, Some comments about `outcome`'s observers with narrow and wide contracts. First, the wide-contract functions. We have a situation when someone assumes that `o` currently stores an error_code, and with this assumption in mind calls `o.error()`, but somehow his assumption is incorrect. What do we want to do? 1. Try to report programmer's bug at run-time? 2. Since in this case it is a bug anyway and are screwed, at least let's make such behavior useful for other situations where `error()` is called conciously on `o` without an error code? The first scenario attempts at identifying a bug, bringing it to attention of developers (maybe in form of a log), and minimizing its consequences by perhaps skipping the execution of some part of the program in hope that the bug will no show symptoms again. The second scenario in a way ignores the bug, and lets the program continue, as though it was correct, and from now on the program is doing something else than what the programmer intended. But the semantics of the function are useful in itself. Users who check `o.has_error()` before calling it can use it as if `error()` had a single purpose and a narrow contract; and users who know the additional semantics can use it for other useful things, like saving themselves of writing some boilerplate code. It is my impression that some of these observer functions in `outcome` follow this second scenario: just do something useful for people who use it unchecked. Saving boilerplate is useful, but let's state it clear: these functions offer no protection against inadvertent mistakes: no run-time or static protection. If I call `o.error()` and it throws when `o.is_empty()`, it is a form of protection. If `o.error()` returns `E{}` when `o.has_value()`, this is no protection, it is convinience function that can be used as a narrow-contract observer. Maybe the interface of `outcome` should make this distinction and offer two sets: one for observers with run-time protection, and the other for nice convenience functions? Second, narrow-contract functions. Narrow functions acheive the following goals: 1. Simple design: function only does one thing, it does not have any if inside. 2. The interface of the library makes a clear distinction of what is valid and what is an invalid usage of the library. It helps in code reviews. For instance, you are looking for a bug in a big code, you find the following piece: ``` auto e = o.error(); ``` and it turns out that `e` contains a value. Did you just find a bug, or was it the author's intention to get an `E{}` at this point? You do not know with wide contracts. With narrow contracts you know: it is a bug. 3. Narrow contracts assist instrumentation in test builds and runs. If I have function `just_value` with a narrow contract, I leave myself the freedom: I can do whatever I want when has_value() is false. What can I do with this freedom: A. In test build, I can check the precondition at run-time and launch the debugger B. I can (run-time) check the precondition, and std::termiante() or throw an exception. C. I can ignore the potential precondition violation, check nothing and aim at some performance gain. D. I can put some code that assists the static analyser (like __builtin_unreachable()) E. I can put some instrumentation code that assists an UB sanitizer (like __builtin_unreachable()) F. I can put hints for optimizer (like __builtin_unreachable(), again) G. Finally, I can put a macro `PRECONDITION(has_value())` which can do any of the above based on the build configuration. Given that, the proposed function `value_if` (which returns a pointer to value) will not satisfy my needs. It has a wide contract, so I cannot put macro `PRECONDITION()` inside. It rturns a pointer. The pointer's operator-> inded does have a narrow contract, but it gives me no room where I can put macro `PRECONDITION()`. So I get some narrow contract, but without the benefits I am looking for. So that is my view of the observer functions. Now my proposal is to provide a pair of observers for each value, error_code and exception -- narrow and wide: `value()` and `just_value()`, `error()` and `just_error()`, `exception()` and `just_exception()` Or maybe, even three for narrow-contract, wide-contract with run-time protection, and for convenience function: `error()` -- wide-contract, runtime-checked precondition `just_error()` -- narrow contract `as_error()` -- convenience function, e.g. returns E{}, on value, monad::has_exception on exception, etc.. Regards, &rzej;

2 2