Comment by Locke1689 | Hacker News Reader

Comment by Locke1689 | Hacker News Reader

Parent Full thread

Going forward, I think C++ is not a bad choice, but I can definitely see the distaste for exceptions. Unfortunately, as the author notes, simply not using exceptions doesn't quite do it. Fortunately, the hard work has been done for you. Much of Google's code was written in an exception-free manner before newer evolutions of C++ came out. This means that they have banned use of exceptions in their style guide. Luckily, it also means they've developed workarounds for most of the exception pain points.

I would encourage everyone to take a look at the Google C++ style Guide[1]. Most of the complaints are addressed in that article. Constructors can only signal errors through exceptions, so Google C++ allows only basic initialization in the constructor -- all real work is done in an explicit Init() method which can signal an error. I believe the guide addresses the posters other concerns too.

In general, the Google C++ style guideline is a very good resource for writing consistently good C++.

[1] https://google-styleguide.googlecode.com/svn/trunk/cppguide....

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.

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?

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.

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.

Reply on news.ycombinator.com