On 12/22/2015 9:09 AM, Robert Ramey wrote:
Of course I'm interested any feedback and/or observations anyone want's to offer.
Hey there, First let me say that I haven't tried out your library yet, but from what I've read I think it's great. So I stumbled upon the comments in your default constructor: // default constructor constexpr explicit safe_base() { // this permits creating of invalid instances. This is inline // with C++ built-in but violates the premises of the whole library // choice are: // do nothing - violates premise of he library that all safe objects // are valid // initialize to valid value - violates C++ behavior of types. // add "initialized" flag. Preserves fixes the above, but doubles // "overhead" // still pending on this. } We've been having this debate over in the "[smart_ptr] Interest in the missing smart pointer (that can target the stack)" thread. It seems to have become a big thread, the relevant posts are near the bottom. I think we ultimately decided that both options should be provided. So for example safe<int> might have default initialization and almost_safe<int> might not. And even in the case where there is default initialization, there's the question of whether you should still require that the value be explicitly set before the first use. (This can be checked for and enforced in debug mode.) While writing some security conscious applications I've been incidentally writing a small library of safer substitutes for some C++ data types (https://github.com/duneroadrunner/SaferCPlusPlus). Among the substitutes it includes are those for int and size_t. Rather than doing comprehensive range checking like your library does, my types just do range checking only where I have the feeling it's particularly important and worth the performance cost. That's basically just when converting to different integer types, and in operator-=() for size_t. Would your library support limiting it's range checks for performance reasons? I guess the goal of my library is roughly to enable C++ programmers to, if they choose, write their code with "language safety" approaching that of Java's. But your library suggests that C++ could maybe even surpass Java as the choice for safe, secure and correct applications. So I wonder about the motivating cases for your library. I mean, was it designed to address specific use cases, or is it meant to be used more generally? I think your library is so novel to me, I don't have a good grasp on the range of application types that might end up using it. 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, for example, invalid memory access or out of range vector element access. I guess what I'm wondering is, whether you think your library is an intrinsically independent one addressing a specific domain, or ultimately should be part of a larger set of tools for facilitating safety/security/correctness in C++? Noah