On 2/3/2016 3:18 PM, Robert Ramey wrote:
Would your library support limiting it's range checks for performance reasons?
I'm not sure what you mean here.
Sorry, I meant for cases where performance is more of a priority, can people have range checking enabled for conversions, but disabled for arithmetic operations (except for maybe operator-=() in the size_t type). I assume that for arithmetic operations a lot of the range checking would occur at run-time. I'm assuming?
I might guess though, that some of the applications using your library to ensure against out of range arithmetic results might also benefit from using something like my library to ensure against,
From what you've said, I think the libraries address the same problem.
Oh sorry, I wasn't clear. The main point of my library isn't the replacements for integers. Probably the main element of my library is a safe drop-in replacement for native pointers. And also an almost completely safe implementation of std::vector and it's iterators. I was thinking of dumping the integer classes from my library and just using yours.
But there is one more thing ...
Writing correct code is not considered a major problem by most programmers and organizations which depend on code. Code that works most of the time is considered good enough. In spite of the current problems like unintended acceleration, failures on ABS systems, blown missile launches, crashing mars probes - this is not considered a problem. Two papers were submitted to CppCon 2015 on safe integers (one by me and one on bounded integers - similar topic) and neither were considered interesting to other reviewers to potential attendees. I suspect they are right - and that's a problem - a huge problem. This problem affects all computer languages. There has never been an industrial strength solution to this problem - until now. And the response has been .... I've requested twice that this library be added to the boost review queue - no action. I've requested twice that a simpler version of this library which was formulated as a proposal be added to the list of standard library proposals - again - no actions.
It's just not important to most of the world. I'm not bitter (though it might seem that I am - I'm really not). I'm just disgusted. (which is an entirely different thing.
Amen brother :) So maybe our libraries actually target slightly different domains. Your library targets the "correctness" issue, where my library targets more the "language safety" issue. Your library wants to make sure ABS systems work reliably. My library is more targeted at reducing the incidence of hackers taking over online banking servers (or your ip camera) through web server vulnerabilities. (While, as much as possible, maintaining performance.) You suggest, and you would know better than me, that your library has no audience because people just don't care. But I wonder if it actually would have an audience if there was more awareness. If it had better marketing. I suspect that my library might also face an awareness issue in that its natural customer is not currently a C++ programmer. Security conscious applications often aren't written in C++ because of it's reputation as an "unsafe" language. But if there were a "safe" C++ library, a single, standard, one-stop library for all your "safe" C++ needs, a library that was truly useful, that library might have a better chance of achieving wider recognition. Don't you think? I mean maybe in this case there's an intermediate step before becoming part of boost. And that is becoming part of a proven, useful "safe" C++ library. "Correct" being a subcategory of "safe". Also, while the performance cost may limit the (perceived) use cases for you library in deployed applications, the performance cost may be less of an issue in debug and test modes. So it might help if it was also marketed as a test library. Just brainstorming here. So I guess I'm wondering if you have any interest in general C++ language safety, or just in the correctness aspect. Or are you of the position that C++ language safety, outside of correctness, is already a solved issue?