- Boost - lists.boost.org

[safe_numerics] Review
by Barrett Adair 12 Mar '17

12 Mar '17

Last minute review here. This will be short and sweet. > What is your evaluation of the design? I like it. The "drop-in replacement" approach is easy to understand. > What is your evaluation of the implementation? It's more complicated than I expected, but if it works, it works. I think the runtime checks in this library might be good candidates for BOOST_[UN]LIKELY. Are there test cases for post decrement? The implementation appears to return a reference to local: https://github.com/robertramey/safe_numerics/blob/master/include/safe_base.… safe_base & operator--(int){ // post decrement safe_base old_t = *this; --(*this); return old_t; } If I'm reading correctly, this is UB (and likely a segfault). > What is your evaluation of the documentation? The documentation is quite thorough. A "cheatsheet" page would be nice, because most of the documentation is rather in-depth. There are many bells and whistles documented that end users might not want to sift through. I'm not sure what this would look like, though. The FAQ appears to be formatted strangely. Notes about bitwise operators in the FAQ might be nice (signed right-shift especially). Very nice job overall. Much work and thought went into this. > What is your evaluation of the potential usefulness of the library? Useful. I'd consider using it in applications that are not latency-sensitive, perhaps if only in debug mode. Detecting accidental unsigned underflow is especially useful. I do think this library might be much more useful with floating point support, if it is eventually added. > Did you try to use the library? With what compiler? Did you have any problems? No. > How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? 3 hours reading documentation, source code, and previous reviews. > Are you knowledgeable about the problem domain? No more than any CS grad should be. > Do you think the library should be accepted as a Boost library? Yes. This library would be a good addition to Boost. I trust that Robert will address the issues raised in this review and others (especially Steven's) before this library would be shipped with a future Boost release, should it be accepted.

3 3

[container] moving a pre-built vector into a flat_set
by Sam Kellett 12 Mar '17

12 Mar '17

a common problem i encounter is that i have two stage's w/r/t to a large collection of data: building and querying. vector is obviously the king of building. flat_set is the king of querying. so what i often tend to do is build up a very large vector, sort it then create a flat_set using the flat_set(ordered_unique_t) constructor. however this still copies the entire vector into the flat_set, right? what i would like to be able to do is move the vector straight into the flat_set, something like: std::vector<T> data; flat_set data_set1(std::move(data)) // move vector in and sort it // or: std::sort(data.begin(), data.end()); // sort vector flat_set data_set2(ordered_unique_t, std::move(data)) // and move it in is this doable (am i just being blind?) or is there plans/interest for this?

8 19

[safe_numerics] review
by John McFarlane 12 Mar '17

12 Mar '17

I'm reviewing this library as someone who has tried to use it in the past, has made minor contributions to it and has a vested interest in improving numeric support for C++ developers. However, I have very little knowledge of the code and relatively little experience of Boost and the Boost community. I hope my comments are helpful nevertheless. tl;dr: make `safe<>` more like the type I describe in [ http://wg21.link/p0554#componentization-safety] or at least ensure that the API can evolve toward this without backward-breaking changes. ---- I do feel that a safe integer type should be available to as many people as possible and Robert's approach is on the right track. But given the choice, I would make some significant API changes. Any of these which can be added incrementally should not delay acceptance of safe_numerics into Boost. The goal of making `safe<int>` a drop-in replacement for int is essential. But further, `safe<Rep>` should be a drop-in replacement for `Rep` where `Rep` is any integer type which exhibits "surprising" results, e.g. through UB of overflow / divide-by-zero or indeterminate initial value. `Rep` should not just be any type for which `std::is_integral_v<Rep>` is true and ideally, `safe<safe<Rep>>`, while pointless, should compile and function like `safe<Rep>`. Unfortunately, `safe<int>` fails to be a drop-in replacement for fundamental integer types for a number of reasons. Firstly, conversion from floating-point types is not fully supported [ https://github.com/robertramey/safe_numerics/issues/13] This alludes to a wider issue with the API of this library: it tries to do too much. Conversion from integers to real numbers is not so much *unsafe* as *lossy*. Users intuitively understand that `int n = 0.5;` will not define a variable with value 0.5 and this is often exactly what they intend, e.g.: void sample(map<safe<int>, safe<int>>& histogram, double v) { ++ histogram[v]; } If implicit conversions to and from other numeric types is not supported, this prevents potential users from converting existing programs. Bear in mind that implicit conversions do not prevent `safe<>` from catching run-time errors. And if one wishes to catch risky narrowing conversions, they already have tools to do this, e.g. GCC's `-Wconversion`. In short, it's a separate concern. Another example of overreach of the API is in governing the results of arithmetic operations. Via policy choice, `safe<int>` can produce auto-widening functionality, e.g. returning a 16-bit result from a multiply operation with 8-bit operands. This behavior belongs in a whole different class. It achieves overlapping safety wins but it complicates the interface. I believe that the correct approach is to produce a type which is dedicated to performing run-time overflow checks and another type which performs automatic widening and to combine them, e.g.: // simplified for clarity, see: wg21.link/p0554#composition-safe_elastic_integer template<typename Rep> class auto_widening_integer; template<typename Rep> class safe_integer; template<typename Rep> using extra_safe_integer = safe_integer<auto_widening_integer<Rep>>; Of the two component classes, `auto_widening_integer` can be used to perform limited overflow-avoidance with zero run-time overhead. (The penalty is that if, say, you multiply two 32-bit integers together, you get back a 64-bit result.) Meanwhile, `safe_integer` provides iron-clad run-time safety checking and obeys the promotion rules of its `Rep` type. The combination of them reduces the number of run-time checks by reducing the chance of overflow. This solution is more complex, but the individual components are simpler and self-sufficient. Unfortunately, due to these kinds of design choices, I have not spent more time attempting to integrate Robert's library with my own. I would dearly like to include `safe<>` as part of a wider set of numeric components which users can then combine to their hearts content. Details of how I think that might come about can be found in (shamelessly plugged) paper, [wg21.link/p0554]. I accept that's a tall order. At the very least I would like developers of substantial projects to be able to replace build-in integers with the following: #if defined(NDEBUG) template<typename Rep> using Integer = Rep; #else template<typename Rep> using Integer = safe<Rep>; #endif Hope that helps, John

4 12

HELP Needed
by Poulomi Hore 11 Mar '17

11 Mar '17

Hi, I would like to work on project 1 under Boost.Geometry for GSoc 2017. Can you please suggest as to where should i start from ? Thank you. Regards, Poulomi Hore

2 1

[safe_numerics] One more review
by Antony Polukhin 11 Mar '17

11 Mar '17

- What is your evaluation of the design? Looks good, simple to use. I'd like to see an additional statefull ExceptionPolicy that remembers that an UB was triggered, but does not throw at all. Here's how it could be used: bool try_do_something(int& out) noexcept { using namespace boost::numeric; safe<int, native, lazy> x = INT_MAX; // remembers that error was triggered ++x; // ... other operations on `x` // ... if (!x.no_errors()) { // One of the operations triggered UB return false; } out = x; return true; } - What is your evaluation of the implementation? Checked a few border cases that I'm aware of. All of them were taken care of in the library. Nitpicks: Missing BOOST_NORETURN in multiple places, for example https://github.com/robertramey/safe_numerics/blob/master/include/exception_… . Adding that attribute may result in better code generation and in warnings suppression. std::is_literal_type type trait is deprecated since C++17 https://github.com/robertramey/safe_numerics/blob/master/include/interval.h… More generic streaming operators could be profitable (better to use basic_ostream<Char, Trait> instead of ostream) https://github.com/robertramey/safe_numerics/blob/master/include/interval.h… Many operations may be decorated with noexcept This macro seems broken https://github.com/robertramey/safe_numerics/blob/master/include/safe_liter… . Also looks like this class is not covered well with tests, because line https://github.com/robertramey/safe_numerics/blob/master/include/safe_liter… shall not compile There's a bunch of implicit conversions in the library https://github.com/robertramey/safe_numerics/blob/master/include/safe_base.… (BTW, have not found a body of this one). Would it be better to make them explicit? Those headers are very heavy https://github.com/robertramey/safe_numerics/blob/7ee656ecdf23f6f29f9333176… Try using <iosfwd> and making all the function below to use `basic_ostream<Char, Trait>&`. No need to define those in `namespace std` https://github.com/robertramey/safe_numerics/blob/7ee656ecdf23f6f29f9333176… . Defining those in `boost::numeric` namespace works fine (thanks to ADL!). I'd really like to see tests coverage for the library. This is pretty simple to add, just follow the instructions from here: https://svn.boost.org/trac/boost/wiki/TravisCoverals - What is your evaluation of the documentation? Good, very interesting examples. - What is your evaluation of the potential usefulness of the library? Useful. I was dealing with such problems in Boost.LexicalCast. - Did you try to use the library? With what compiler? Did you have any problems? Have not tried. - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? About two hours of reading source code and docs. - Are you knowledgeable about the problem domain? A little bit, not an expert. - Do you think the library should be accepted as a Boost library? Yes, the library should be accepted. -- Best regards, Antony Polukhin

5 10

[safe_numerics] Formal review starts today
by Andrzej Krzemienski 11 Mar '17

11 Mar '17

Hi Everyone, Today, on March 2nd (or tomorrow, depending on your timezone), is the start of the formal review of safe_numerics library by Robert Ramey. The review will run till March 11th. I will be serving as review manager. safe_numerics is a set of drop-in replacements for the built-in integer types, which make the guarantee that the results of operations are either correct according to the rules of integer arithmetic or report a diagnosable error (rather than offering modulo arithmetic results, or resulting in undefined behavior, or returning incorrect results as in the case of signed vs. unsigned comparisons). The library can be found on GitHub: https://github.com/robertramey/safe_numerics/ Online docs: http://htmlpreview.github.io/?https://github.com/robertramey/safe_numerics/ master/doc/html/index.html Formal Review comments can be posted publicly on the mailing list or Boost Library Incubator <http://blincubator.com>, or sent privately to the review manager, that is myself. 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 Your review is needed! Regards, Andrzej Krzemieński, review manager.

5 19

[safe_numerics] Last three days
by Andrzej Krzemienski 11 Mar '17

11 Mar '17

Hi Everyone, We have three last days remaining for safe_numerics review (till March 11th). If you like working under time pressure, this is the perfect moment for doing your review. If you would like to submit your review, but feel you will not make it till March 11th, let me know, we can try to extend the review period. Currently, I recorder three reviews with a yes/no call, from Paul A. Bristow and Steven Watanabe, and one without a yes/no call from Vicente J. Botet Escriba. If you have submitted a review, but were not mentioned in my list, please let me know: it means I must have missed it. ----- safe_numerics is a set of drop-in replacements for the built-in integer types, which make the guarantee that the results of operations are either correct according to the rules of integer arithmetic or report a diagnosable error (rather than offering modulo arithmetic results, or resulting in undefined behavior, or returning incorrect results as in the case of signed vs. unsigned comparisons). The library can be found on GitHub: https://github.com/robertramey/safe_numerics/ Online docs: http://htmlpreview.github.io/?https://github.com/robertramey /safe_numerics/master/doc/html/index.html Formal Review comments can be posted publicly on the mailing list or Boost Library Incubator <http://blincubator.com>, or sent privately to the review manager, that is myself. 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 Regards, &rzej;

7 17

how can I use ipv6 on boost::asio
by Kazuaki Okimoto 11 Mar '17

11 Mar '17

Hi I can connect through IPV4 when I open the socket by following method. _socket->open(boost::asio::ip::tcp::v4()); But , it can't use IPV6 network. I'd like to use my app on IPV6 network. How can I use IPV6 on boost:asio ? Dies anyone tell me the method of it ? best regards

2 1

IPC: compiler optimization related issues
by Robert 11 Mar '17

11 Mar '17

Hi! Before creating a bug in trac, would you accept issues related to compiler optimization (-O2 and -O3) flags? I have a very specific issue with an inter-process mutex (race condition), but it can be reproduced only when flag O2 or higher is being used during compilation. Thank you!

2 2

To contribute in Static map (boost::static_map<Key, T, ConstExprHash = boost::constexpr_hash<Key>, Pred = boost::constexpr_equal_to<Key>>)
by SUSHIL KHANCHI 11 Mar '17

11 Mar '17

Hello, I am an engineering student in Computer Science from SMVDU(India). I would like to contribute to your STATIC MAP project and take part in Gsoc.For getting familiar to your work, I would like to get my hands on your projects issues. Can you please guide me to your project where I can start with fixing small bugs.

1 0