5 ms·

It's a C++ myth that files and memory are the same problem, in reality files are an easier problem, cf java.

saurik 4y ago
?! Java doesn't offer a reasonable solution for files... it is presumed they can be closed by the garbage collector calling "finalizers", but that results in problems such as holding file locks long after they should have been released (which is a correctness problem) and running out of file handles (a limited resource that Java does not track pressure against) due to this mechanism having no time horizon. The result is that you are essentially trapped into the realm of manual resource management, having to put a try block around every single use of a file to make sure you can control its lifetime and prevent it from "leaking" into the collector. You then would have to use a finally block and call close. Memory is certainly the easier problem as it is a single constrained resource with usage semantics (licenses and conflicts) entirely constrained by the language. (They at least have recently added some syntax that makes the last bit of that easier, but which doesn't at all make it less manual. This syntax is somewhat based on C#'s using blocks, a feature which I might have actually caused due to some strong advocacy surrounding this issue when .NET was in beta, and yet I have always insisted this syntax failed to correctly understand the problem as, even if you buy into the manual-ness of it all, it leads to colored objects, as there are objects controlled by the garbage collector and objects controlled by using and now adding a field to an object that must be disposed flips it from one regime into the other regime without causing a type incompatibility.)
- GoblinSlayer 4y ago
  There's no limit to perfection, but java approach is reasonable, because it works in practice.
- cryptonector 4y ago
  If you use a try-with-resources in Java, then the closeables are closed immediately when the try block exits, and in reverse order to acquisition.
vitiral 4y ago
There is a separate solution for files: defer. Defer can be implemented trivially in assembly by putting the deferred block on the return stack (then the defer block simply returns). This glosses over handling the local stack, but it's not impossible. It would be a relatively minor feature to add to C IMO
- kevin_thibedeau 4y ago
  Breaks with longjmp().
  - vitiral 4y ago
    I've not done an in-depth analysis but I don't think longjmp is as performant as pushing (and updating) the return stack. Maybe you could do it with assign to our variable + jmp.
jcelerier 4y ago
cf Java? Both in it and c# forgetting to close handles has been one of the most common mistakes I've seen. It pretty much never happens on c++.
- GoblinSlayer 4y ago
  I saw it two times in real world C++ code and never saw it in C# and java. Memory leaks are much more common.
bunderbunder 4y ago
I would argue that the opposite is true, because memory is fungible and files are not. c.f.) Java, where the GC can handle memory, but it didn’t work out so well for files, so, to restore correctness, we needed the Closeable and AutoCloseable interfaces to give manual control back to the programmers.
- yakubin 4y ago
  Closing a file doesn't trigger a cascade of closing other files, while freeing memory in RAII does trigger a cascade of more frees.
TomSwirly 4y ago
No, C++ has the idea that the same solution can be used for all resource management: file handles, memory, sockets, database cursors or connections, you name it. And it works. Resource life management is not a problem that Java handles with grace...
- GoblinSlayer 4y ago
  That's the myth, C++ way is not the only true way. Many C++ programmers know only C++ way and can't imagine anything else, because they spent all their life on learning C++ and it consumed all their mental resources.

?! Java doesn't offer a reasonable solution for files... it is presumed they can be closed by the garbage collector calling "finalizers", but that results in problems such as holding file locks long after they should have been released (which is a correctness problem) and running out of file handles (a limited resource that Java does not track pressure against) due to this mechanism having no time horizon. The result is that you are essentially trapped into the realm of manual resource management, having to put a try block around every single use of a file to make sure you can control its lifetime and prevent it from "leaking" into the collector. You then would have to use a finally block and call close. Memory is certainly the easier problem as it is a single constrained resource with usage semantics (licenses and conflicts) entirely constrained by the language. (They at least have recently added some syntax that makes the last bit of that easier, but which doesn't at all make it less manual. This syntax is somewhat based on C#'s using blocks, a feature which I might have actually caused due to some strong advocacy surrounding this issue when .NET was in beta, and yet I have always insisted this syntax failed to correctly understand the problem as, even if you buy into the manual-ness of it all, it leads to colored objects, as there are objects controlled by the garbage collector and objects controlled by using and now adding a field to an object that must be disposed flips it from one regime into the other regime without causing a type incompatibility.)

GoblinSlayer 4y ago
There's no limit to perfection, but java approach is reasonable, because it works in practice.
cryptonector 4y ago
If you use a try-with-resources in Java, then the closeables are closed immediately when the try block exits, and in reverse order to acquisition.

vitiral 4y ago

There is a separate solution for files: defer. Defer can be implemented trivially in assembly by putting the deferred block on the return stack (then the defer block simply returns). This glosses over handling the local stack, but it's not impossible. It would be a relatively minor feature to add to C IMO

kevin_thibedeau 4y ago
Breaks with longjmp().
- vitiral 4y ago
  I've not done an in-depth analysis but I don't think longjmp is as performant as pushing (and updating) the return stack. Maybe you could do it with assign to our variable + jmp.

jcelerier 4y ago

cf Java? Both in it and c# forgetting to close handles has been one of the most common mistakes I've seen. It pretty much never happens on c++.

GoblinSlayer 4y ago
I saw it two times in real world C++ code and never saw it in C# and java. Memory leaks are much more common.

bunderbunder 4y ago

I would argue that the opposite is true, because memory is fungible and files are not. c.f.) Java, where the GC can handle memory, but it didn’t work out so well for files, so, to restore correctness, we needed the Closeable and AutoCloseable interfaces to give manual control back to the programmers.

yakubin 4y ago
Closing a file doesn't trigger a cascade of closing other files, while freeing memory in RAII does trigger a cascade of more frees.

TomSwirly 4y ago

No, C++ has the idea that the same solution can be used for all resource management: file handles, memory, sockets, database cursors or connections, you name it. And it works. Resource life management is not a problem that Java handles with grace...

GoblinSlayer 4y ago
That's the myth, C++ way is not the only true way. Many C++ programmers know only C++ way and can't imagine anything else, because they spent all their life on learning C++ and it consumed all their mental resources.