4 ms·

To clarify, I assume you mean that FAIL is the one that enumerates to true, but that you dislike this idiom. "For the purposes of the exercise I’ve deliberatel

To clarify, I assume you mean that FAIL is the one that enumerates to true, but that you dislike this idiom. "For the purposes of the exercise I’ve deliberately limited the amount of error checking; this isn’t meant to be industrial-strength code (so don’t gripe to me that I haven’t covered all the error cases!)" I think it's pretty clear (at the very least, it's charitably inferrable) that the author is accustomed to errno-flavour error codes. Everything else you gripe about is just syntactic fluff* that makes no difference whatsoever to the analysis, and is dialect-invariant anyway. * Edit: by syntactic fluff I mean that it has both the properties of being easy to mechanically change and that the given mechanical change wouldn't turn bad code into good. One can have strong feelings about the density of white space in code or the proper place of constructor definitions for a class not defined in a header file (I don't, but whatever), but when the solution to it is to run it through a program for a perfect result, I think it becomes not worth discussing.

ajross 15y ago
For clarity: having a symbol in a program named "FAIL" which evaluates to boolean truth is simply wrong, without room for reasonable disagreement. The errno trick is accepted because of the need to enumerate the "failing" space, it is never used in situations where there is only one kind of failure. And even if there were, it should (again, without argument) be called something specific (e.g. "NO_REAL_ROOT"). As to the latter point about a hypothetical machine I could use: I'd be very surprised if you had a tool which mechanically removes empty destructors, as that changes the semantics of the code (e.g. they can start being POD objects which get different initialization semantics). But in this code they were verifiably needless, which is bad style. Are you in the habit of writing other noop functions "just because?". And I'm amused at your "not worth discussing" point, given that you jumped into a discussion about exactly that. :)

ajross 15y ago

For clarity: having a symbol in a program named "FAIL" which evaluates to boolean truth is simply wrong, without room for reasonable disagreement. The errno trick is accepted because of the need to enumerate the "failing" space, it is never used in situations where there is only one kind of failure. And even if there were, it should (again, without argument) be called something specific (e.g. "NO_REAL_ROOT"). As to the latter point about a hypothetical machine I could use: I'd be very surprised if you had a tool which mechanically removes empty destructors, as that changes the semantics of the code (e.g. they can start being POD objects which get different initialization semantics). But in this code they were verifiably needless, which is bad style. Are you in the habit of writing other noop functions "just because?". And I'm amused at your "not worth discussing" point, given that you jumped into a discussion about exactly that. :)