5 ms·

Memory Safe C/C++: Time to Flip the Switch

13 points by edwintorok 14y ago

JoeAltmaier 14y ago
C/C++ are often used for things like drivers and operating systems. That code can't have elaborate runtime baggage. So if the memory safety were part of the std lib heap for instance, go for it! But if it means making one instruction (store into array) into 50 (checkthebounds, the store if safe else throw an exception) then it needs to be optional.
- dchichkov 14y ago
  Yes. Good thing about C/C++ (particularly code with statically allocated memory and zero or few virtual calls) is that the resulting code behavior is very predictable. You can almost always expect it to be memory bound, and by counting your memory accesses and cache misses guesstimate the performance really well. I guess, that adding memory safety layer may destroy that predictability. If it does, than no - it needs to be optional.
MostAwesomeDude 14y ago
Garbage collection. That's what all of these decades of research have led to, and that's what you should embrace. It's time. It's been time.
voidlogic 14y ago
Memory Safe C/C++... Sounds like Go :)- http://golang.org/ http://golang.org/ The future is now!
- lholden 14y ago
  Rust I think has more potential to eventually replace C/C++. Besides having modern language features, it still allows the programmer to get down into the nuts and bolts of how memory is being used. (Not that I feel Rust is perfect either...) Go has some cool features... but I have yet to find a really compelling reason to use it over anything else. I also find it to be kinda gross looking. (But maybe I am just weird in that respect?)
  - lholden 14y ago
    From an InfoQ interview: "InfoQ: How does it compare with Google Go? GH: Go's a good language. It's less complex than Rust, but also less ambitious. So you can pick your poison. Go's memory model, for example, has no concept of isolating memory between co-routines or threads, nor of controlling mutability. Everything can always race on the same global mutable heap. Similarly it has only one kind of pointer, which can always be null, and all pointers in all co-routines are subject to a single, global garbage collector. Rust statically differentiates all these cases, divides memory and pointers up into different types, which means we can control safety and performance much better, but at the cost of the programmer having to think more. Rust also provides a few extra "modern bits" that Go lacks: generic types, destructors, disjoint unions, that sort of thing. But to its credit, Go gets a lot of mileage out of the stuff it included, and I'm glad it's making headway." http://www.infoq.com/news/2012/08/Interview-Rust http://www.infoq.com/news/2012/08/Interview-Rust
    - voidlogic 14y ago
      The counter argument is Rust is going to end up an even more bloated ugly language than C++. Go is going to add some of those features, but they are committed to a slow "do it right approach" as opposed to "bolt it on". >>which means we can control safety and performance much better, but at the cost of the programmer having to think more Outside of systems software, there is no room for this. If the top 5% of programmers wrote all the software in the world Rust would be great, but that is just not the case.
      - lholden 14y ago
        I'm guessing you have not really looked into Rust. The idea is to also take a "do it right" approach rather then "à la carte". Keep in mind, the focus in in a different domain. Not really sure what basis you have for the "even more bloated" comment. There has been a lot of movement this past year around features and syntax in Rust... but the language is very much still in development. The main difference with Rust is the focus is on trying to make memory management safe yet applicable to lower level and performance critical programming. (A domain a lot of people are currently using (and getting bitten by) C++ for, hence why Rust is aimed at replacing it.) In regards to 'thinking more', this is in comparison to higher level languages. Things are way better compared to C++ on the other hand. Don't forget that replacing C++ is the target market for the language, not Java/Go/Etc. Anyhow, no reason to have a flame war on the subject. Rust isn't a hammer and neither is Go. :)

13 points by edwintorok 14y ago

C/C++ are often used for things like drivers and operating systems. That code can't have elaborate runtime baggage. So if the memory safety were part of the std lib heap for instance, go for it! But if it means making one instruction (store into array) into 50 (checkthebounds, the store if safe else throw an exception) then it needs to be optional.

dchichkov 14y ago
Yes. Good thing about C/C++ (particularly code with statically allocated memory and zero or few virtual calls) is that the resulting code behavior is very predictable. You can almost always expect it to be memory bound, and by counting your memory accesses and cache misses guesstimate the performance really well. I guess, that adding memory safety layer may destroy that predictability. If it does, than no - it needs to be optional.

MostAwesomeDude 14y ago

Garbage collection. That's what all of these decades of research have led to, and that's what you should embrace. It's time. It's been time.

voidlogic 14y ago

Memory Safe C/C++... Sounds like Go :)- http://golang.org/ http://golang.org/ The future is now!

lholden 14y ago
Rust I think has more potential to eventually replace C/C++. Besides having modern language features, it still allows the programmer to get down into the nuts and bolts of how memory is being used. (Not that I feel Rust is perfect either...) Go has some cool features... but I have yet to find a really compelling reason to use it over anything else. I also find it to be kinda gross looking. (But maybe I am just weird in that respect?)
- lholden 14y ago
  From an InfoQ interview: "InfoQ: How does it compare with Google Go? GH: Go's a good language. It's less complex than Rust, but also less ambitious. So you can pick your poison. Go's memory model, for example, has no concept of isolating memory between co-routines or threads, nor of controlling mutability. Everything can always race on the same global mutable heap. Similarly it has only one kind of pointer, which can always be null, and all pointers in all co-routines are subject to a single, global garbage collector. Rust statically differentiates all these cases, divides memory and pointers up into different types, which means we can control safety and performance much better, but at the cost of the programmer having to think more. Rust also provides a few extra "modern bits" that Go lacks: generic types, destructors, disjoint unions, that sort of thing. But to its credit, Go gets a lot of mileage out of the stuff it included, and I'm glad it's making headway." http://www.infoq.com/news/2012/08/Interview-Rust http://www.infoq.com/news/2012/08/Interview-Rust
  - voidlogic 14y ago
    The counter argument is Rust is going to end up an even more bloated ugly language than C++. Go is going to add some of those features, but they are committed to a slow "do it right approach" as opposed to "bolt it on". >>which means we can control safety and performance much better, but at the cost of the programmer having to think more Outside of systems software, there is no room for this. If the top 5% of programmers wrote all the software in the world Rust would be great, but that is just not the case.
    - lholden 14y ago
      I'm guessing you have not really looked into Rust. The idea is to also take a "do it right" approach rather then "à la carte". Keep in mind, the focus in in a different domain. Not really sure what basis you have for the "even more bloated" comment. There has been a lot of movement this past year around features and syntax in Rust... but the language is very much still in development. The main difference with Rust is the focus is on trying to make memory management safe yet applicable to lower level and performance critical programming. (A domain a lot of people are currently using (and getting bitten by) C++ for, hence why Rust is aimed at replacing it.) In regards to 'thinking more', this is in comparison to higher level languages. Things are way better compared to C++ on the other hand. Don't forget that replacing C++ is the target market for the language, not Java/Go/Etc. Anyhow, no reason to have a flame war on the subject. Rust isn't a hammer and neither is Go. :)