I presume you're the one who downvoted my comment.
C++ leaves OS level resource handling to the user. It's not C++'s job to figure out if the user wanted to close this unused resource. It's the programmer's job to not leak resources. And that includes closing each file descriptor once, or deleting allocated memory exactly once.
Go came with a GC model. Yay! But file descriptors aren't pointers to memory. They're representations of physical objects on disk.
Again, it's the programmer's job to tell the compiler when they're done with the file, and not rely on the compiler to figure out when they're actually done with it.
Could go reference count file descriptors/handlers? Yes! But they also chose not to.
Is this right? Don't languages clean up resources in finalizers? (It's just often not ideal because finalizer calling is not predictable... Or really that they are by default called by memory pressure and not resource pressure).
I presume you're the one who downvoted my comment.
C++ leaves OS level resource handling to the user. It's not C++'s job to figure out if the user wanted to close this unused resource. It's the programmer's job to not leak resources. And that includes closing each file descriptor once, or deleting allocated memory exactly once.
Go came with a GC model. Yay! But file descriptors aren't pointers to memory. They're representations of physical objects on disk.
Again, it's the programmer's job to tell the compiler when they're done with the file, and not rely on the compiler to figure out when they're actually done with it.
Could go reference count file descriptors/handlers? Yes! But they also chose not to.
Is this right? Don't languages clean up resources in finalizers? (It's just often not ideal because finalizer calling is not predictable... Or really that they are by default called by memory pressure and not resource pressure).
You've clearly never coded in C/C++ where it's your job as the coder to manage memory and other resources.
3 replies →