Re: [Boost-users] C++ and quality of software

Subject: Re: [Boost-users] C++ and quality of software
From: Peter Foelsche (foelsche_at_[hidden])
Date: 2010-01-26 17:45:07

"Patrick Horgan" <phorgan1_at_[hidden]> wrote in message 
news:4B5F6B51.5070108_at_yahoo.com...
> Peter Foelsche wrote:
>> 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.

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.

>>  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 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.

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.

>>  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.

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.

Using my philosophy leads to code, which avoids protocol errors:
Please call routine a() before routine b(), otherwise behvior is not 
defined.

>> What do you think?
> The whole thing seems of limited use.  You mistake limiting flexibility 
> for good quality I think.

Aegypt?
Sphinx?
Pyramids?

>
> Patrick