4 ms·

Good riddance! So the proposal was sponsored by HP, Symantec and Intel. I was expecting something related to Microsoft and it's ill conceived idea of "Managed

Good riddance! So the proposal was sponsored by HP, Symantec and Intel. I was expecting something related to Microsoft and it's ill conceived idea of "Managed C++", but it all boils down to: Hans Boehm. As surprised as the next guy to find this in C++ standard. ...Again: good riddance.

AdmiralAsshat 3y ago
Garbage Collection is not a bad idea, but, my takeaway is that if you try to bolt it onto a language that didn't have it in its core design, you're gonna have a bad time.
- mikepurvis 3y ago
  Interesting that GC was originally part of rust and got un-bolted: http://pcwalton.github.io/_posts/2013-06-02-removing-garbage-collection-from-the-rust-language.html http://pcwalton.github.io/_posts/2013-06-02-removing-garbage...
- repelsteeltje 3y ago
  It's rather that with RAII (C++, Rust) you don't need a GC. Of course, you can still create and operate a GC arena in C++, to manage a data structure or problem area where it makes sense. But why build in into the language, library, runtime if developers don't need it?
  - simiones 3y ago
    (Well-designed, first-class) GC is still the only system proven to completely remove memory safety issues. Rust comes close, but it's not RAII but the compiler-enforced ownership tracking which allows for this. C++ is very much proven to be memory unsafe in practice despite the RAII and smart pointers being part of the standard for a decade or more now. Opt-in memory safety basically just means no memory safety. Of course, this doesn't mean that you can't create memory safe C++ programs. Probably one or two actually exist. But there also exist memory safe C programs and probably somewhere there is some memory safe program written in assembly as well.
    - repelsteeltje 3y ago
      > (Well-designed, first-class) GC is still the only system proven to completely remove memory safety issues. To be pedantic, you need more than a GC for memory safety. Like a language (type system, bounds checks) that forces you to only look only inside the memory being managed. :-) Also, "for free" memory safety as offered by java's GC doesn't automatically guarantee resource safety. Without RAII, you still need to manage you file handles the old-fashioned manual way. Beyond that there are safety concerns that where the shared memory model managed by the GC bites you. For example: Rust solves threading issues with move semantics and pinning, guiding programmer away from shared mutable state. Also think of stop-the-world problems inherent with GCs. They can be life threatening in real-time systems. So: yes it's true that it's difficult to write safe code in C++, and many safety bugs are related to memory. But that doesn't mean that code in a GCed language is inherently safer.
      - vips7L 3y ago
        > Also, "for free" memory safety as offered by java's GC doesn't automatically guarantee resource safety. Without RAII, you still need to manage you file handles the old-fashioned manual way Don’t you think a file handle is a completely different thing than what is normally talked about with memory safety? Can a un-closed handle let you ++ your way into remote code execution? Or reading uninitialized memory? Regardless, a GC is about trade offs. A GC alleviates the 99% of programming. Thinking about having to close a file resource occasionally, especially since javac will warn you when you don’t, is leagues easier than having to navigate the borrow checker all of the time. The same goes for concurrent programming. 99.9% of all code written in GC’d languages like Java never go over a thread boundary.
        aidenn0 3y ago
        > Don’t you think a file handle is a completely different thing than what is normally talked about with memory safety? Can a un-closed handle let you ++ your way into remote code execution? Or reading uninitialized memory? Unfreed memory also doesn't let you ++ your way into remote code execution. Using a file-handle after it's been closed can cause all sorts of issues; and if the underlying file-descriptor is being reused to e.g. write a shell script you can end up in RCE territory as well.
  - another2another 3y ago
    I'd also argue that with well used RAII, programs can be written more reliably than in some GC languages as you have finer control over the lifetime of system resources like Windows HANDLES or sockets and can free them on scope destruct with a simple wrapper class. On .net I'm constantly fiddling with IDispose and checking each object if it needs a 'using' block so I'm not leaking resources. On long running resource intensive apps, this can make a real difference and I prefer the finer control C++ gives me.
  - kaba0 3y ago
    RAII gives you only static, scope-based lifetimes. These are not sufficient in itself for every kind of application. With that said, C++ is a low-level language with manual memory management, so you can do whatever, an unused GC is indeed good riddance.

AdmiralAsshat 3y ago

Garbage Collection is not a bad idea, but, my takeaway is that if you try to bolt it onto a language that didn't have it in its core design, you're gonna have a bad time.

mikepurvis 3y ago
Interesting that GC was originally part of rust and got un-bolted: http://pcwalton.github.io/_posts/2013-06-02-removing-garbage-collection-from-the-rust-language.html http://pcwalton.github.io/_posts/2013-06-02-removing-garbage...
repelsteeltje 3y ago
It's rather that with RAII (C++, Rust) you don't need a GC. Of course, you can still create and operate a GC arena in C++, to manage a data structure or problem area where it makes sense. But why build in into the language, library, runtime if developers don't need it?
- simiones 3y ago
  (Well-designed, first-class) GC is still the only system proven to completely remove memory safety issues. Rust comes close, but it's not RAII but the compiler-enforced ownership tracking which allows for this. C++ is very much proven to be memory unsafe in practice despite the RAII and smart pointers being part of the standard for a decade or more now. Opt-in memory safety basically just means no memory safety. Of course, this doesn't mean that you can't create memory safe C++ programs. Probably one or two actually exist. But there also exist memory safe C programs and probably somewhere there is some memory safe program written in assembly as well.
  - repelsteeltje 3y ago
    > (Well-designed, first-class) GC is still the only system proven to completely remove memory safety issues. To be pedantic, you need more than a GC for memory safety. Like a language (type system, bounds checks) that forces you to only look only inside the memory being managed. :-) Also, "for free" memory safety as offered by java's GC doesn't automatically guarantee resource safety. Without RAII, you still need to manage you file handles the old-fashioned manual way. Beyond that there are safety concerns that where the shared memory model managed by the GC bites you. For example: Rust solves threading issues with move semantics and pinning, guiding programmer away from shared mutable state. Also think of stop-the-world problems inherent with GCs. They can be life threatening in real-time systems. So: yes it's true that it's difficult to write safe code in C++, and many safety bugs are related to memory. But that doesn't mean that code in a GCed language is inherently safer.
    - vips7L 3y ago
      > Also, "for free" memory safety as offered by java's GC doesn't automatically guarantee resource safety. Without RAII, you still need to manage you file handles the old-fashioned manual way Don’t you think a file handle is a completely different thing than what is normally talked about with memory safety? Can a un-closed handle let you ++ your way into remote code execution? Or reading uninitialized memory? Regardless, a GC is about trade offs. A GC alleviates the 99% of programming. Thinking about having to close a file resource occasionally, especially since javac will warn you when you don’t, is leagues easier than having to navigate the borrow checker all of the time. The same goes for concurrent programming. 99.9% of all code written in GC’d languages like Java never go over a thread boundary.
      - aidenn0 3y ago
        > Don’t you think a file handle is a completely different thing than what is normally talked about with memory safety? Can a un-closed handle let you ++ your way into remote code execution? Or reading uninitialized memory? Unfreed memory also doesn't let you ++ your way into remote code execution. Using a file-handle after it's been closed can cause all sorts of issues; and if the underlying file-descriptor is being reused to e.g. write a shell script you can end up in RCE territory as well.
- another2another 3y ago
  I'd also argue that with well used RAII, programs can be written more reliably than in some GC languages as you have finer control over the lifetime of system resources like Windows HANDLES or sockets and can free them on scope destruct with a simple wrapper class. On .net I'm constantly fiddling with IDispose and checking each object if it needs a 'using' block so I'm not leaking resources. On long running resource intensive apps, this can make a real difference and I prefer the finer control C++ gives me.
- kaba0 3y ago
  RAII gives you only static, scope-based lifetimes. These are not sufficient in itself for every kind of application. With that said, C++ is a low-level language with manual memory management, so you can do whatever, an unused GC is indeed good riddance.