A Usable C++ Dialect That Is Safe Against Memory Corruption
1–10 of 103 posts
Re: A Usable C++ Dialect That Is Safe Against Memory Corruption
#2This is basically how I program C++. Except that I try to avoid the 'new' keyword too by std::make_unique and std::make_shared. This way there are literally zero 'new' and 'delete' or 'malloc' or 'free' calls in your program.
Re: A Usable C++ Dialect That Is Safe Against Memory Corruption
#3There's a pretty good comment on this post from a shadow banned user named Kenji, which I'm reproducing below:
This is basically how I program C++. Except that I try to avoid the 'new' keyword too by std::make_unique and std::make_shared. This way there are literally zero 'new' and 'delete' or 'malloc' or 'free' calls in your program.
Re: A Usable C++ Dialect That Is Safe Against Memory Corruption
#4I have a question about this.
Articles like http://blog.llvm.org/2011/05/what-every-c-programmer-should-... have convinced me that even if C or C++ reads logically like it is safe, there is a possibility that the compiler can rewrite your code in an acceptable way according to the standards such that the checks that are clearly visible in your code disappear, opening up the very problems that you thought you were protected against.
Is there any possibility that after an aggressive compiler gets done with inlining and optimization that that could happen here in some way? Can it be proven that if the compiler works according to the standard that this won't happen..even if the programmer accidentally trips on undefined behavior?
Re: A Usable C++ Dialect That Is Safe Against Memory Corruption
#5There's a pretty good comment on this post from a shadow banned user named Kenji, which I'm reproducing below: This is basically how I program C++. Except that I try to avoid the 'new' keyword too by std::make_unique and std::make_shared. This way there are literally zero 'new' and 'delete' or 'malloc' or 'free' calls in your program.
I just vouched for that comment, so it should show up now.
Re: A Usable C++ Dialect That Is Safe Against Memory Corruption
#6"Now, we can extend our allocation model with a few additional guidelines, and as long as we’re following these rules/ guidelines, our C++ programs WILL become perfectly safe against memory corruptions."
What could possibly go wrong?
Re: A Usable C++ Dialect That Is Safe Against Memory Corruption
#7There's a pretty good comment on this post from a shadow banned user named Kenji, which I'm reproducing below: This is basically how I program C++. Except that I try to avoid the 'new' keyword too by std::make_unique and std::make_shared. This way there are literally zero 'new' and 'delete' or 'malloc' or 'free' calls in your program.
I just vouched for that comment, so it should show up now.
Oh cool, I didn't know you could do that.
Re: A Usable C++ Dialect That Is Safe Against Memory Corruption
#8TL;DR; use smart pointers, RAII semantic and STL containers/iterators. Though, I'd have a few criticism...
> Rules to ensure memory safety
These "rules" only protect you against object's lifetime issues, not overflow / underflows, and other kind of memory issues.
> ‘owning’ pointers are obtained only from operator new
no, you shall be using std::make_{unique,shared}(...) which will protect you against leaking memory if exceptions are raised.
> Calling a function passing the pointer as a parameter, is ok.
Correct, but you can still shoot yourself in the foot. Best is to pass a [const] reference to the function called.
> This only leaves us with functions such as strchr()
Don't use C API. The STL should provide you with enough API to use the proper C++ types, either std::string or std::string_view in C++17 if possible.
> and also prohibits C-style cast and static_cast with respect to pointers
IIRC, you can't static_cast a pointer, you'd have to reinterpret_cast it, which the document does mention.
> For arrays, we can always store the size of the array within our array collection, and check the validity of our ‘safe iterator’ before dereferencing/indexing
use std::array.
Re: A Usable C++ Dialect That Is Safe Against Memory Corruption
#9There's a pretty good comment on this post from a shadow banned user named Kenji, which I'm reproducing below: This is basically how I program C++. Except that I try to avoid the 'new' keyword too by std::make_unique and std::make_shared. This way there are literally zero 'new' and 'delete' or 'malloc' or 'free' calls in your program.
[deleted]
Re: A Usable C++ Dialect That Is Safe Against Memory Corruption
#10I have a question about this. Articles like http://blog.llvm.org/2011/05/what-every-c-programmer-should-... have convinced me that even if C or C++ reads logically like it is safe, there is a possibility that the compiler can rewrite your code in an acceptable way according to the standards such that the checks that are clearly visible in your code disappear, opening up the very problems that you thought you were pro…
Perhaps someone better versed in those compilers can add to/correct me here, but I'm pretty sure that can only happen if you're invoking UB somewhere along the line.