

Memory Safe C/C++: Time to Flip the Switch - edwintorok
http://blog.regehr.org/archives/939

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

------
voidlogic
Memory Safe C/C++... Sounds like Go :)- <http://golang.org/>

The future is now!

~~~
lholden
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
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>

~~~
voidlogic
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
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. :)

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

C++ is too complex of a language IMHO. Complexity is bad for new people as it
takes a long time to _know_ the entire language. And its bad for existing
people as it provides too many ways to do the same thing. Rusts features look
to be a superset of C++... You could substitute "too complex" with "too big".

>>Anyhow, no reason to have a flame war on the subject. Rust isn't a hammer
and neither is Go. :)

I thought this was an interesting and friendly conversion, not a flame war. I
do think everyone involved in this conversion probably agrees with each other
in general, just maybe not particulars.

And yes everyone has their favorite hammer, that doesn't mean its not worth
discussing which hammers are best for which tasks.

~~~
lholden
>> Rusts features look to be a superset of C++... You could substitute "too
complex" with "too big".

Feature wise I'd say Rust has more in common with a functional language.

    
    
      * Consistent type system. (base types like int are objects)
      * Emphasis on type safety.
      * First class functions and Lambdas.
      * Pattern matching.
      * All memory is somehow managed or owned. (#1)
      * Isolated concurrent memory. (No need for semaphores/mutexes)
      * 'variables' are immutable by default.
      * Types with traits instead of a "class" system. (#2)
      * No exception catching (#3)
      * Generics (#4)
      * No direct null/nil (Options are used instead.)
      * Concurrency is built in.
      * Can allocate on the stack, or via a managed 'box' on the heap. (#5)
      * Has the ability to link to and call C code.
      * Has the ability to break out into inline assembly.
      * Macros. (#6)
    

The manual is reasonably decent: <http://static.rust-lang.org/doc/rust.html>

#1) Technically you can break out into unsafe memory operations or assembly.
You have to specifically mark your code as 'unsafe' when doing so however.

#2) Similar to Haskell type classes and way simpler then C++ classes.

#3) There is a kind of error/exception but they are way simpler and not meant
to be managed like in C++/Java

#4) Don't confuse generics with C++ templates. (C++ templates can be used for
the same purpose, but is WAY more complex and interesting.)

#5) Perhaps the most complex part of the language... Boxes are a bit like
smart pointers but with way less code involved.

#6) I have not gotten into this very deeply yet but it looks more like Lisp
macros instead of C/C++ macros/preprocessing.

For perspective... C++ has about 84 keywords. Go has 25 keywords plus several
predeclared identifiers (true and false for example). Rust currently has 32
keywords. (Some of which are just syntactic sugar).

>> I thought this was an interesting and friendly conversion, not a flame war.

( _Was trying to show that she saw the subject light heartedly_.) It was meant
more as a tease then an accusation :)

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

