In understanding the two implementations and their pros and cons, I find it useful to generalize here:
- Summarize the concept of the file to really consider any resource purchased; and
- Summarize what the operating system provides to what is also provided by the programming language, libraries, or frames.
As to why systems can use the first method ...
The answer will likewise apply to why you can use a programming idiom like RAII . That is, you want to do your own resource lifecycle management or want it to be done for you.
Sometimes, when life cycle management is done for us (we, as programmers), we may lose the ability to do what we want (things that would otherwise be possible if we ourselves implement life cycle management). Sometimes it is more important that there is no possibility of a resource leak, and not for access to every call and whistle.
Take memory management in C ++, for example. We can allocate memory from the system using new or you can call std::make_shared . The first, however, requires us to also name delete (at the end of its use) if we want the memory to not leak. Meanwhile, Java does not give the programmer direct access to memory allocation and instead uses garbage collection, so that "programmers can get rid of the need to perform manual memory management . "
As for the examples of the first method ...
Many Unix-like operating systems provide a programming interface for the syslog object. Although it has open and close analogies in openlog and closelog , calling them is optional. You can simply call syslog to run the syslog text.
Similarly, we are also controlled by standard input and output. When a program starts, it is usually already open and accessible. When it comes out, these flows will be closed to us (if necessary). The program does not need to call fclose(stdout) (and not something like fopen("/dev/console") ). Programs can simply call fputs or fgets using stdout or stdin .