Peter Foelsche wrote:
I also use fixed arrays for arrays, which never change in size. Obviously I meant something different here, e.g. buffers for reading from data from somewhere. In this case fixed sized buffers either mean truncation or buffer overflow.
I'm working in a scanner for a parser right now that uses fixed sized input buffers for some things, but never reads more than that size. I agree that truncation and buffer overflow can be a result of nutty indiscriminate reading into a fixed size buffer. If you wanted to make a rule, "Don't be an idiot and give a pointer to be the destination of a read without making sure that there won't be truncation or overflow"--that would be cool.
I meant usage of C++ Exception for errors. Errors usually mean, that the following code does not need to be executed. If the following code needs to be executed, it would be stupid to throw an exception just to catch it at the same level. We'll have to agree to disagree here. Sometimes it makes sense to use exceptions sometimes error codes.
I don't see any use to the open() method on a file object. What does this object represent, when constructed without a filename? This is what boost::optional is for. What about after a close() and a subsequent open() in a routine processing a series of files?
Using my philosophy leads to code, which avoids protocol errors: Please call routine a() before routine b(), otherwise behvior is not defined. Yes, sometimes things are complicated, and if you don't use them correctly you break things. Don't get me wrong, your guidelines point out places where people can fail and need to be careful, I get that.
Patrick