zlacker

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.

>>bb88+(OP)
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).

>>jayd16+c1
You've clearly never coded in C/C++ where it's your job as the coder to manage memory and other resources.

>>bb88+H1
I'm confused. Are your comments only relevant to C/C++ when the thread is about Go and the question was what any language should do? Personally I was thinking about garbage collected finalizers such as in Java.

>>jayd16+c2
No.. Go did a half-assed version of reference counting on resources. Memory yes. File descriptors, no so much.

Edited to add: What's the point of continuing to discuss this if all you understand is .NET and not actually tried to manage C/C++ resources (without using boost smart pointers) by hand?

>>bb88+x2
FWIW Go doesn't do any reference counting, its GC implementation is a concurrent mark and sweep. And also file descriptors are subject to the same mechanism, a finalizer is set on them and they will be closed when the associated object is collected.