4 ms·
Actually the problem is deeper than this. You can't have type safety w/o memory safety, and it has nothing to do with casting. Here's an example. You allocat
by kenjackson 15y ago
Actually the problem is deeper than this. You can't have type safety w/o memory safety, and it has nothing to do with casting.
Here's an example. You allocate a chunk of memory as type Foo. You use it as Foo. You hand out references to Foo. Everyone is happy. Then someone says, "We don't need this instance of Foo anymore" and deletes it. Someone later comes and allocates Bar and the memory allocator correctly goes and grabs some of Foo's old memory and uses it for Bar.
All good, right? Well, except there's this other thread that is using a reference to that old instance of Foo. Suddenly you have a type safety issue at hand.
Now you can say, "Don't write programs with bugs". And indeed that is just about the only alternative.
- saurik 15y agoMy claim is that well designed C++ programs do not have calls to delete at all, not just ones that cause bugs: you come up with your memory abstraction, you build that part of the system (it is likely that this code will have a single call to delete in it), and then your actual program relies on that as a "runtime": if the code in that area calls "delete", you do not allow that code, and treat it as a build failure. I have been responsible for projects with on the order of hundreds of thousands of line of C++ (such as for a video game we were developing), and the only calls to "delete" were in the stack-locked reference counting implementation I designed, and a few optimized containers. It isn't even hard to think like this in a language like C++, and isn't highly different than a language like Haskell (you build abstractions from unsafePerformIO: you don't routinely code with it).
- jules 15y agoFor concurrent data structures this "runtime" ends up being basically a re-implementation of garbage collection.
- cperciva 15y agoI don't understand you java people. Are you really saying that because a pointer-to-Foo will always point to a Foo, you're somehow safe from bugs? Sure, you might be less likely to crash; but you're far more likely to get silent data corruption -- and I know which of those two I'd prefer to see.
- barrkel 15y agoNo; the pointer-to-Foo will always point to the original Foo (unless it's reassigned). The point of the example is to show that type safety depends on not having access explicit heap management. You're more likely to get silent data corruption without memory safety, than with it. It has nothing to do with Java specifically, FWIW. Ruby, Python, shell script, C#, Haskell, they are all memory safe. It's a big church.
- cperciva 15y agounless it's reassigned Well, sure. And that's true of C as well. The question is what happens when that memory gets reused.
- barrkel 15y agoI don't know if you're being deliberately obtuse. At the semantic level of a memory safe language, there never is any memory reuse, because memory isn't a resource like that. It is impossible to observe memory being reused from within the language. In fact, you could use that as a kind of definition of memory safety. It cuts off a whole kind of memory corruption bug, makes it impossible (aside from bugs in the language and / or runtime, of course). I'm just going to have to throw up my hands here. The masses on HN are apparently proudly ignorant, and unwilling to learn even the slightest thing before wading in.
- cperciva 15y agoWhat you're talking about is the benefits of garbage collection -- the fact that you can't free memory until nobody has a reference to it any more. That's completely different from type safety.
- barrkel 15y agoColin, it's embarrassing at this point, it really is. I'd have hoped, with your background, that you'd know better. Memory safety is not dependent on having a GC - if you have an appropriate runtime, a smart enough type system, or a simple enough language semantics.
- sausagefeet 15y agoThis is why God invented std::shared_ptr