Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Usable C++ Dialect That Is Safe Against Memory Corruption

ithare.com

Post reply on HN
Print view View original

11–20 of 103 posts

Re: A Usable C++ Dialect That Is Safe Against Memory Corruption

#11

Post by saagarjha »

btilly wrote: post #4

I 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…

As far as I'm aware, if you stay within the confines of smart pointers (and don't drop down to the raw pointer it owns) you will never encounter undefined behavior. You may have crashes if you try to double free something, but these are defined to crash rather than letting the compiler optimize out checks.

Re: A Usable C++ Dialect That Is Safe Against Memory Corruption

#12

Post by saagarjha »

Animats wrote: post #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?

If you're not being facetious, then really, not much. You really can't go wrong with smart pointers unless you explicitly try to access the memory it handles rather than going through its normal interface (e.g., not using get()). Shared pointers are basically reference counted just like many other language handle memory management.

Re: A Usable C++ Dialect That Is Safe Against Memory Corruption

#13

Post by saagarjha »

EpicEng wrote: post #10
btilly wrote: post #4

I 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.

Once you've entered the realm of undefined behavior, the compiler can really do whatever it likes. Before then all it can do is assume you're not doing anything undefined.

Re: A Usable C++ Dialect That Is Safe Against Memory Corruption

#14

Post by zach43 »

saagarjha wrote: post #11
btilly wrote: post #4

I 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…

As far as I'm aware, if you stay within the confines of smart pointers (and don't drop down to the raw pointer it owns) you will never encounter undefined behavior. You may have crashes if you try to double free something, but these are defined to crash rather than letting the compiler optimize out checks.

Wouldn't you have a problem with reference cycles in C++ smart pointers? Not sure if they do anything special to prevent this.

Re: A Usable C++ Dialect That Is Safe Against Memory Corruption

#15

Post by ape4 »

Kenji wrote: post #2

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.

Likewise, I avoid -> if possible.

Re: A Usable C++ Dialect That Is Safe Against Memory Corruption

#17

Post by beached_whale »

alacombe wrote: post #8

TL;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…

Using iterators and ranges(think a generalized string_view) handles the overflow/underflow issue in conjunction with algorithms(std ones).

Re: A Usable C++ Dialect That Is Safe Against Memory Corruption

#18

Post by masklinn »

saagarjha wrote: post #11
btilly wrote: post #4

I 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…

As far as I'm aware, if you stay within the confines of smart pointers (and don't drop down to the raw pointer it owns) you will never encounter undefined behavior. You may have crashes if you try to double free something, but these are defined to crash rather than letting the compiler optimize out checks.

> As far as I'm aware, if you stay within the confines of smart pointers (and don't drop down to the raw pointer it owns) you will never encounter undefined behavior.

Deref'ing an empty (e.g. moved-from) unique_ptr is still UB.

Re: A Usable C++ Dialect That Is Safe Against Memory Corruption

#19

Post by saagarjha »

alacombe wrote: post #8

TL;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…

Mostly agree, but:

> 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.

Sometimes you're working with C API that gives you back a char * that they've already allocated. AFAIK there isn't a way to create an std::string out of that without a copy.

> you can't static_cast a pointer

You can static_cast a void * into other kinds of pointers.

> use std::array

Do you mean std::vector and at()?

Re: A Usable C++ Dialect That Is Safe Against Memory Corruption

#20

Post by saagarjha »

zach43 wrote: post #14
saagarjha wrote: post #11

Earlier quoted context omitted.

As far as I'm aware, if you stay within the confines of smart pointers (and don't drop down to the raw pointer it owns) you will never encounter undefined behavior. You may have crashes if you try to double free something, but these are defined to crash rather than letting the compiler optimize out checks.

Wouldn't you have a problem with reference cycles in C++ smart pointers? Not sure if they do anything special to prevent this.

std::weak_ptr is there for resolving reference cycles.
Post reply on HN