3 ms·

Agreed, it is a very good guide. However, the ZeroMQ author goes a lot further than that for his specific application. He made some reasonable arguments that

by drucken 14y ago

Agreed, it is a very good guide. However, the ZeroMQ author goes a lot further than that for his specific application. He made some reasonable arguments that even the use of OOP/classes in C++ makes catching undefined behaviour unnecessarily difficult for systems programming.

Locke1689 14y ago
His other objections didn't make a lot of sense to me. Destruction doesn't seem like something that can fail. Your object has been deleted or it is going out of scope. You don't even manually call the destructor. It should be about freeing resources. what work is he doing in the destructor that can fail?
- gchpaco 14y ago
  Well, fclose can fail, for example; it can as part of the closing process flush its buffer and that can fail like any other I/O process. Further, sometimes the error than happened during a previous write(2) call is only detected in the close(2); think NFS and quotas, or check the man page. So already we have errors that occur during teardown that need to be handled somehow. Similarly one can imagine using RIAA to hold a file lock, or a temporary directory; this is a perfectly reasonable thing to do but there are dozens of reasons why the final rm -rf of the tempdir could fail. The idea that somehow object teardown is immune to failure is overly naive, and the fact that you can't accommodate it easily in RIAA is quite disappointing and makes the whole paradigm much less useful for carefully coded software.
  - Locke1689 14y ago
    My claim is that object teardown is not what the destructor is for. Teardown encompasses many things that are not resource releasing. Destructors are for releasing resources, not necessarily guaranteeing their destruction. For example, fclose can fail, but even if it does, the stream given is no longer held. In fact, any further use of the stream is undefined. There is certainly a place for logging in this situation, but if close was a behavior of the class, it should have a separate close function. As far as locking goes, it is the responsibility of the locking routine (probably a semaphore) to release the callers hold on the lock, but it is not the callers responsibility to ensure that whatever resources are associated with the lock (e.g., a file) actually get deleted. That is the locking object's responsibility. I agree that some aspects of RAII could be better, but C is not the answer to that. C doesn't even have scope-based RAII.

by drucken 14y ago

Locke1689 14y ago

His other objections didn't make a lot of sense to me. Destruction doesn't seem like something that can fail. Your object has been deleted or it is going out of scope. You don't even manually call the destructor. It should be about freeing resources. what work is he doing in the destructor that can fail?

gchpaco 14y ago
Well, fclose can fail, for example; it can as part of the closing process flush its buffer and that can fail like any other I/O process. Further, sometimes the error than happened during a previous write(2) call is only detected in the close(2); think NFS and quotas, or check the man page. So already we have errors that occur during teardown that need to be handled somehow. Similarly one can imagine using RIAA to hold a file lock, or a temporary directory; this is a perfectly reasonable thing to do but there are dozens of reasons why the final rm -rf of the tempdir could fail. The idea that somehow object teardown is immune to failure is overly naive, and the fact that you can't accommodate it easily in RIAA is quite disappointing and makes the whole paradigm much less useful for carefully coded software.
- Locke1689 14y ago
  My claim is that object teardown is not what the destructor is for. Teardown encompasses many things that are not resource releasing. Destructors are for releasing resources, not necessarily guaranteeing their destruction. For example, fclose can fail, but even if it does, the stream given is no longer held. In fact, any further use of the stream is undefined. There is certainly a place for logging in this situation, but if close was a behavior of the class, it should have a separate close function. As far as locking goes, it is the responsibility of the locking routine (probably a semaphore) to release the callers hold on the lock, but it is not the callers responsibility to ensure that whatever resources are associated with the lock (e.g., a file) actually get deleted. That is the locking object's responsibility. I agree that some aspects of RAII could be better, but C is not the answer to that. C doesn't even have scope-based RAII.