3 ms·

> A generational GC is way more efficient than `std::shared_ptr` that's true, but it's also a moot point because std::shared_ptr is almost never the semantics

> A generational GC is way more efficient than `std::shared_ptr` that's true, but it's also a moot point because std::shared_ptr is almost never the semantics you want. You want std::unique_ptr. Also, you can get away without allocating memory dynamically in a lot of cases (thus not incurring overhead of malloc). After C++11 and Rust I'm starting to think garbage collection is holding us back from doing research into better approaches to automatic memory management.

pjmlp 10y ago
The main problem with std::shared_ptr as a library type, is not being able to forbid developers to call get() or pass a reference or pointer to it.
- nice_byte 10y ago
  agreed, but that doesn't affect performance (i was responding to grandparent's performance argument).
lomnakkus 10y ago
> that's true, but it's also a moot point because std::shared_ptr is almost never the semantics you want. You want std::unique_ptr. unique_ptr still has the malloc()/free()[1] overhead, I'm assuming the parent poster just misspoke. One major issue with shared_ptr (which unique_ptr doesn't have) is that it must work properly when different threads have different shared_ptr's (copies of each other) pointing to the same object. This adds overhead. > Also, you can get away without allocating memory dynamically in a lot of cases (thus not incurring overhead of malloc). Ok, but we're specifically talking about GC and RC here, so I don't see why you'd bring that up. > After C++11 and Rust I'm starting to think garbage collection is holding us back from doing research into better approaches to automatic memory management. GC literally is automatic memory management. (And as others have pointed out, so RC is a form of GC.) Also, there's lots and lots of research into various different ways of doing automatic memory management. [1] Alright, they don't literally use malloc/free, but you know what I mean.
- nice_byte 10y ago
  > Ok, but we're specifically talking about GC and RC here, so I don't see why you'd bring that up. well, my point was, in garbage-collected languages you don't have the option to never even engage the garbage collector by creating variables on the stack, while in languages like C++ you can avoid the overhead of malloc/free by using stack variables. > GC literally is automatic memory management. It is, but there are other approaches to automatic memory management that don't introduce another entity that does stuff to your program at runtime. C++'s smart pointers is one such approach, see also Automatic Reference Counting and Rust's borrow checking. I wish there was more research done into compile-time techniques to prevent resource leaks.
  - lomnakkus 10y ago
    > well, my point was, in garbage-collected languages you don't have the option to never even engage the garbage collector by creating variables on the stack, while in languages like C++ you can avoid the overhead of malloc/free by using stack variables. Oh, I see. I can see what you mean, but there are solid techniques for avoiding GC in e.g. JVM-based langauges -- for an example see e.g. Disruptor/Aeron. I'll happily grant that it's a problem that it can be quite hard to see if you're actually avoiding GC when using these patterns. It'd be interesting if there were a "@no-gc" annotation which could enforce such patterns on the source code. (So, essentially you'd have a compile-time "GC by default, but you can opt-out and the compiler will tell you when you violate that". One can dream.)

pjmlp 10y ago

The main problem with std::shared_ptr as a library type, is not being able to forbid developers to call get() or pass a reference or pointer to it.

nice_byte 10y ago
agreed, but that doesn't affect performance (i was responding to grandparent's performance argument).

lomnakkus 10y ago

> that's true, but it's also a moot point because std::shared_ptr is almost never the semantics you want. You want std::unique_ptr. unique_ptr still has the malloc()/free()[1] overhead, I'm assuming the parent poster just misspoke. One major issue with shared_ptr (which unique_ptr doesn't have) is that it must work properly when different threads have different shared_ptr's (copies of each other) pointing to the same object. This adds overhead. > Also, you can get away without allocating memory dynamically in a lot of cases (thus not incurring overhead of malloc). Ok, but we're specifically talking about GC and RC here, so I don't see why you'd bring that up. > After C++11 and Rust I'm starting to think garbage collection is holding us back from doing research into better approaches to automatic memory management. GC literally is automatic memory management. (And as others have pointed out, so RC is a form of GC.) Also, there's lots and lots of research into various different ways of doing automatic memory management. [1] Alright, they don't literally use malloc/free, but you know what I mean.

nice_byte 10y ago
> Ok, but we're specifically talking about GC and RC here, so I don't see why you'd bring that up. well, my point was, in garbage-collected languages you don't have the option to never even engage the garbage collector by creating variables on the stack, while in languages like C++ you can avoid the overhead of malloc/free by using stack variables. > GC literally is automatic memory management. It is, but there are other approaches to automatic memory management that don't introduce another entity that does stuff to your program at runtime. C++'s smart pointers is one such approach, see also Automatic Reference Counting and Rust's borrow checking. I wish there was more research done into compile-time techniques to prevent resource leaks.
- lomnakkus 10y ago
  > well, my point was, in garbage-collected languages you don't have the option to never even engage the garbage collector by creating variables on the stack, while in languages like C++ you can avoid the overhead of malloc/free by using stack variables. Oh, I see. I can see what you mean, but there are solid techniques for avoiding GC in e.g. JVM-based langauges -- for an example see e.g. Disruptor/Aeron. I'll happily grant that it's a problem that it can be quite hard to see if you're actually avoiding GC when using these patterns. It'd be interesting if there were a "@no-gc" annotation which could enforce such patterns on the source code. (So, essentially you'd have a compile-time "GC by default, but you can opt-out and the compiler will tell you when you violate that". One can dream.)