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

[config] msvc-14.1 and C++14 constexpr
by John Maddock 13 Mar '17

13 Mar '17

So.... MSVC-14.1 (2017) sort of supports C++14 constexpr. However, it is also prone to internal compiler errors, and currently does not compile config_test.cpp unless we set BOOST_NO_CXX14_CONSTEXPR. Does anyone have a view on which way this macro should be set? Thanks, John. --- This email has been checked for viruses by AVG. http://www.avg.com

4 3

Re: [boost] [gsoc17] Project1: Static map: Can I implement the competency test in g++-7?
by Vic Luo 13 Mar '17

13 Mar '17

Hi, During the implementation of my static_map, I recently encountered a problem: how to deal with string types? For example: constexpr auto cmap_str = make_static_map({ {"abc", 1}, {"bcd", 2} }); static_assert(cmap_str["abc"] == 1, "test"); In my implementation, KeyType requires 1. constexpr operator==, which is not provided by const char * 2. constexpr hash(const KeyType&). Since there is no such thing in standard library, I have to implement some in this project. Currently I would like to use string_view, since it looks like a general solution for compile-time string with lots of constexpr functions, but I don't know which of the following designs looks better: Design A: template<typename KeyType, typename MappedType, typename EqualOp = StaticEqualOp<KeyType>, typename HashOp = StaticHashOp<KeyType>> class static_map; // StaticEqualOp: Specialize StaticEqualOp for those KeyTypes that // can construct string_view and use operator== of string_view, // otherwise we simply use operator== of KeyType // StaticHashOp: size_t operator()(const string_view&, const string_view&) // for types that can construct string_view Design B: We don't specialize any StaticEqualOp for const char*. Instead, make_static_map({{"abc", 1}}) returns static_map<string_view, int> instead of static_map<const char *, int>. Which one is better? Or is there any more feasible design? Thanks, -- --------------------------------- Vic Luo Shanghai Jiaotong University Key fingerprint 0x98809ca08bf5662a

3 6

[safe_numerics] The review is finished
by Andrzej Krzemienski 13 Mar '17

13 Mar '17

Hi Everyone, The review of safe_numerics library by Robert Ramey is now finished. Thanks to all participants for submitting their reviews, and sharing their insights. I will announce the result in the next couple of days. -- Andrzej Krzemienski, review manager

1 0

[gsoc17] Project Static map : Clarifications and Competency test
by Pasindu Kanchana 13 Mar '17

13 Mar '17

Hi I am Pasindu Kanchana from Sri Lanka, studying at the University of Moratuwa as a final year undergraduate(4th year).I have worked as a developer intern for past 6 months for an exchange related company focusing c++ and have used boost memory mapped_file , tokenizer and filesystem. It would be really helpful if i get answers for the following 3 questions. A)Although the requested key is not in range ,still the code should compile?(without any error throwing and halting compilation) B)The solution to the problem should prove that compile time initiation of the map is confirmed(constexpr should definitely compile at the compile time not remain to the run time).would it be enough to practically proving this for different compilers under c++14 to approve as a solution? C)Should I take the competency test? Thank you.

2 1

[outcome] Seeking review manager for Boost.Outcome
by Niall Douglas 13 Mar '17

13 Mar '17

It's only taken a month of work and writing my own C preprocessor, but I finally have a usable set of API reference docs for Outcome at https://ned14.github.io/boost.outcome/. Apart from a few docs glitches caused by the old version of doxygen on Travis, I'd say Outcome is ready for review. Would anybody be interested in review managing Outcome? Thanks, Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

1 0

[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