I was thinking. There should be some C++ software quality assurance institution. They would give a stamp of approval to software written in C++. Criteria would be: a.. no usage fixed-sized buffers There are many instances where fixed-sized buffers are the best design. b.. no usage of functions from the c library, which do not check for correct type, like *printf(), *scanf(). While I don't use these myself in new code, when maintaining other's code who do, I don't consider it a quality issue for well written debugged code to use these. c.. no dangling resources, no resource leaks in any case Yeah, that's pretty basic--you might as well add no access to uninitialized variables. d.. usage of C++ Exception Handling for reporting errors (all fallible OS-calls are wrapped into C++, this can be checked by denying read/write permissions on some object, the software is trying to read/write to) This is a bit silly. There are times where exception handling is
Peter Foelsche wrote: perfect and times when it is not, and they are often mixed. I'm thinking that you aren't a system programmer. Often time system calls return to you error codes and you use that to make a decision. That might be to retry, give up, throw an exception, return a code, etc. Your idea is too draconian and rules out many good design patterns.
e.. clean design -- e.g. no protocols (no protocols is my way of saying, that all methods of classes can be used and make sense to be used, as soon as this object exists) This just confuses me. I'm not sure what the word protocol means here--that an object can't keep state and have different behavior over time maybe??? If that's it, an fstream would fail, because you can't use most of it before open(). Strange. What do you think? The whole thing seems of limited use. You mistake limiting flexibility for good quality I think.
Patrick