8 ms·

A lot of C++ software out there could afford to use a GC.

• wiseowise 4y ago
  What’s wrong with RAII?
  • Rochus 4y ago
    nothing
  • Yoric 4y ago
    I can think of a few cases in which GC would really simplify things, both in C++ and in Rust. I want to do some serious D and Go (and Crystal?) some day to see how it changes life.
  • pebal 4y ago
    It is not a solution for all cases.
    • wiseowise 4y ago
      Care to give cases where it is not a solution?
      • pebal 4y ago
        - Some graph structures. The shared_ptr does not release circular data structures and has a lot of memory overhead. - Memory managing of concurrent containers. Lock-free algorithms requires GC or the hazard pointers and these are basically based on GC. - You often need the GC engine when you implementing or integrating another language.
      • hgs3 4y ago
        RAII amounts to reference counting which means you need to handle circular references yourself. A garbage collector should handle them automatically. In addition to memory, GC's can catch other unused resources like unclosed file handles.
      • fasterik 4y ago
        Arena allocation is useful when many objects have the same known lifetime. An example from games is per-frame allocations. All objects needed only for the frame being rendered are carved out of a large chunk of preallocated memory. The chunk is reused every frame instead of being freed back to the system allocator. In addition to the performance benefits, this results in less memory fragmentation.
  • UncleMeat 4y ago
    Unless you use shared_ptr for all heap allocations (and are also careful about references to stack-allocated data) it allows for uaf bugs. And at that point you are probably better off with a GC since you've got all of the problems with a reference-counting GC but none of the opportunities for optimization.
    • FpUser 4y ago
      Modern C++ provides enough nuts and bolts to avoid explicit allocations. My current C++ project (backend business server) only has single one. The rest is handled happily by RAII (what a dumb name). I could eliminate that single explicit allocation as well but I think I could manage single occurrence ;). Also It would be really dumb to use shared_ptr for every case of allocation
      • UncleMeat 4y ago
        "I only every allocate things on the stack" is not sufficient to have safe lifetime access. I've seen enough cases of some stack-allocated string getting passed as a string_view and then blowing up because somebody stored it. "I have a complete tree of object ownership with a single allocated root" is also a mess for a different reason - you literally never delete anything. Either you have a very very strange application or you are being massively wasteful with memory pressure. It would be really dumb to use shared_ptr for every allocation. But it is the only way in C++ to systematically ensure that you never have a uaf (I guess you could also have a custom allocator and a custom pointer type that does a null check on every dereference - but now you are paying a major performance cost for a lock and a branch on every dereference). That's why I mention the benefit of a GC. You can get safe lifetime access without shared_ptr everywhere (or going all the way to where Rust went and demanding very explicit lifetime annotations for the compiler to use).
        • FpUser 4y ago
          >"I've seen enough cases of some stack-allocated string getting passed as a string_view and then blowing up because somebody stored it ..." Shortest answer - I do not get scared into using particular tools just because they're "safe" and in practice I've never had to deal with the problems you mentioned in my products. There are also various tools that catch these kinds of errors for C++ and other languages. I do use those them tools ;)
  • Koshkin 4y ago
    Unlike GC, RAII is “eager” - which has performance implications.
    • de_keyboard 4y ago
      RAII can push resources to a collection that is disposed later
  • p0nce 4y ago
    Basically if your C++ function takes a pointer you need to write one for unique_ptr, or raw pointer (documenting the ownership). With a GC, there is a global owner so you don't have to think about ownership for everything, this breaks down for some resource release (maybe half of objects) which is not necessarily easier. But typically GC languages also allow you to use RAII, though maybe not as consistently as C++. What kind of programs can have unclear ownership? Basically everything that doesn't need to be high quality.