3 ms·

> How do I deal with memory leaks? > plug in a garbage collector. Love it!

jlarocco 5mo ago
I don't know. Bjarne's has been saying for 40 years that C++ will eventually have opt-in garbage collectors written for it, but after all this time I don't think one exists yet unless you count C++/CLI. For example, the 1987 edition of "The C++ Programming Language" (only 328 pages, including the index!) explains how the user can handle `new` failures with `set_new_handler` to "plug in" a garbage collection function that frees up memory and handles the failure. And section 10.7 of "The Design and Evolution of C++", is titled "Automatic Garbage Collection", and covers in depth his reasons for not including a garbage collector, and explains a bit about how a plugin automatic collector might work. The TL;DR is that the hardware of the time was too limited and the performance overhead would have killed C++'s chances in its target market. He also posits that memory leaks "are quite acceptable" in many applications because most don't have to run forever and aren't "foundation libraries', but he's probably changed his mind on that by now.
stackghost 5mo ago
You can leak memory in Go, C#, and Java (all GC'ed languages) too. In fact, I've done it. The real trick, in my experience, is to design your software with things like bounded queues or ring buffers, and to avoid manual memory management (new/delete). This works in C++ just as well as GC'ed languages. One of my favorite consequences of LLM-heavy workflows (vibe-coding "make me a CRUD app"-style prompts aside) is that prompting the LLM forces the user to put at least a modicum of thought into how the software is actually architected.
- jffhn 5mo ago
  Bounded collections still allow for useless reachings of their bounds, and corresponding memory and CPU wastes (and possibly functional/domain issues). The main reason I saw around me for memory leaks in GC'ed languages, is devs only thinking about the 'add' part, not the 'when-to-remove' part. I always think of both and the only leaks I got were from slowdowns causing events to pile up in scheduler queues (deliberately not bounded).

I don't know. Bjarne's has been saying for 40 years that C++ will eventually have opt-in garbage collectors written for it, but after all this time I don't think one exists yet unless you count C++/CLI. For example, the 1987 edition of "The C++ Programming Language" (only 328 pages, including the index!) explains how the user can handle `new` failures with `set_new_handler` to "plug in" a garbage collection function that frees up memory and handles the failure. And section 10.7 of "The Design and Evolution of C++", is titled "Automatic Garbage Collection", and covers in depth his reasons for not including a garbage collector, and explains a bit about how a plugin automatic collector might work. The TL;DR is that the hardware of the time was too limited and the performance overhead would have killed C++'s chances in its target market. He also posits that memory leaks "are quite acceptable" in many applications because most don't have to run forever and aren't "foundation libraries', but he's probably changed his mind on that by now.

stackghost 5mo ago

You can leak memory in Go, C#, and Java (all GC'ed languages) too. In fact, I've done it. The real trick, in my experience, is to design your software with things like bounded queues or ring buffers, and to avoid manual memory management (new/delete). This works in C++ just as well as GC'ed languages. One of my favorite consequences of LLM-heavy workflows (vibe-coding "make me a CRUD app"-style prompts aside) is that prompting the LLM forces the user to put at least a modicum of thought into how the software is actually architected.

jffhn 5mo ago
Bounded collections still allow for useless reachings of their bounds, and corresponding memory and CPU wastes (and possibly functional/domain issues). The main reason I saw around me for memory leaks in GC'ed languages, is devs only thinking about the 'add' part, not the 'when-to-remove' part. I always think of both and the only leaks I got were from slowdowns causing events to pile up in scheduler queues (deliberately not bounded).