3 ms·

Look man, I don't know what to tell you except that you view code fundamentally differently. My point is that yes, obviously everything gets turned into x64/x86

Look man, I don't know what to tell you except that you view code fundamentally differently. My point is that yes, obviously everything gets turned into x64/x86 assembly at some point, and that yes, I'm sure seeing it is very easy. But if I need to prevent a GC pause from happening at some point in the frame my hands are tied. Debating this is like pulling teeth, and I'm inclined to say that if you can't follow at this point, just use your GC everywhere.

pjmlp 11y ago
This whole thread started by my statement that I haven't seen large projects without errors doing manual memory management. I doubt very seriously that anyone can write code in large teams where Valgrind will state there aren't double frees, bad frees, or dangling pointers happening. Or a run with Coverity will state everything is nice and shinning. Once upon a time I had to write a tool in a well known particle accelerator research institute to track down C++ memory errors in a multi-thread environment for cluster algorithms used in data analysis. As one common problem on that specific team was plugins bringing the cluster down due to memory corruption. So I also do know one or two things about manual memory management. And with what I know, I rather use automatic memory management, be it in the form of GC, RC, affine types or dependent types.
- banachtarski 11y ago
  Dangling resources are common in any language. Ports don't get reclaimed, file descriptors are opened and never closed... the same principles apply. Its funny since I actually started writing code for particle accelerator research as well, although it was a mixture of terrible C and F77. Physicists and mathematicians are good at their respective fields, but not necessarily coding sadly (I used to be both). Would the code have been better with a different language? Doubtful. They used literally zero established patterns and wrote everything with copy paste and with zero regard for what the machine actually did. To each their own though. I'm glad your projects and line of work afford you the ability to work with a GC. Mine do not.

pjmlp 11y ago

This whole thread started by my statement that I haven't seen large projects without errors doing manual memory management. I doubt very seriously that anyone can write code in large teams where Valgrind will state there aren't double frees, bad frees, or dangling pointers happening. Or a run with Coverity will state everything is nice and shinning. Once upon a time I had to write a tool in a well known particle accelerator research institute to track down C++ memory errors in a multi-thread environment for cluster algorithms used in data analysis. As one common problem on that specific team was plugins bringing the cluster down due to memory corruption. So I also do know one or two things about manual memory management. And with what I know, I rather use automatic memory management, be it in the form of GC, RC, affine types or dependent types.

banachtarski 11y ago
Dangling resources are common in any language. Ports don't get reclaimed, file descriptors are opened and never closed... the same principles apply. Its funny since I actually started writing code for particle accelerator research as well, although it was a mixture of terrible C and F77. Physicists and mathematicians are good at their respective fields, but not necessarily coding sadly (I used to be both). Would the code have been better with a different language? Doubtful. They used literally zero established patterns and wrote everything with copy paste and with zero regard for what the machine actually did. To each their own though. I'm glad your projects and line of work afford you the ability to work with a GC. Mine do not.