On 2/3/16 9:05 PM, Noah wrote:
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?
yep - you're assuming too much. a) lot's of operations don't need checking: int8_t i, j i + j // can never overflow due to C++ type promotion rules int l, m l + m // can overflow. But the later case can be "fixed" by changing the promotion policy so that rather than int, the result is calculated in a larger intermediate type. etc. etc. It turns out that many cases can't fail anyway and others can be made safe with only minor changes. This is why it's impossible to do without a type aware library such as this one.
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.
or maybe making a safe_pointer library. Feel free to borrow anything from the safe_integer library which might be useful.
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.)
OK - I can't really understand what your library does without studying it.
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.
Maybe, we'll see. Maybe a few more big crashes might help.
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?
maybe - it wouldn't hurt
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.
LOL - aren't we all. Actually, I've worked on a fair number of embedded systems - which is my main inspiration for this. In the real world, there is huge pressure to "make it work". I get this. Then it is "tested" until the bugs stop appearing. It seems cost effective. And perhaps it is. Because, to make a safe C++/C program now would require writing C code in the style of assembler, checking all intermediate operations and doing conversions by hand. So the choice is pretty simple - ignore the issue or don't deliver the system. The ultimate customer doesn't seem to care. When the Mars Lander crashed into mars - wasting several hundred million dollars - due to a problem in conversion of english and metric units - an extensive investigation was undertaken. The final result was ... it was nobody's fault. To me this is incomprehensible. It seems as as a facet of the "hacker mentality" which is widely lauded these days. I think a big part of the problem is that I'm just to old and living in the distant past.
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?
I want to be able to write and read a program which clearly states what it is supposed to do and know that it will do exactly that or tell me why it can't do that. What I don't want is to write/read a program that no one can understand what it does. I don't want it to return an incorrect result at all. among other things things that means. a) if you write i + j you will get either the correct arithmetical result or some sort of exception that you are expected handle. b) if you allocate an object .... c) if you do anything at all - it either works as written or handles some sort of d) if I write x + y (floating point) I get either the expected result or a reason why it can't be returned. This is a very difficult goal to realize. Damian Vicino is working on this. I don't know his current progress. I believe that C++ already addresses some of this- memory allocation, multi-threading, etc. But other parts are only addressed in an ad hoc way - I want to see that changed. Robert Ramey