C++ and quality of software
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 b.. no usage of functions from the c library, which do not check for correct type, like *printf(), *scanf(). c.. no dangling resources, no resource leaks in any case 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) 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) What do you think? I also published this on my blog: http://foelsche.spaces.live.com/blog/cns!2BFA22F3AB9E833!921.entry
Google has some effort in that direction : http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml http://google-styleguide.googlecode.com/svn/trunk/cpplint/cpplint.py On Mon, Jan 25, 2010 at 9:58 PM, Peter Foelsche <foelsche@sbcglobal.net> wrote:
On Jan 25, 2010, at 1:18 PM, Bo Jensen wrote:
Yes they do. It includes nuggets like this: <http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#Exceptions> Smart Pointers ▶ If you actually need pointer semantics, scoped_ptr is great. You should only use std::tr1::shared_ptr under very specific conditions, such as when objects need to be held by STL containers. You should never use auto_ptr. Reference Arguments ▶ All parameters passed by reference must be labeled const. Default Arguments ▶ We do not allow default function parameters, except in a few uncommon situations explained below. Exceptions ▶ We do not use C++ exceptions. Run-Time Type Information (RTTI) ▶ We do not use Run Time Type Information (RTTI). -- Marshall
On Jan 25, 2010, at 1:49 PM, joel falcou wrote:
I agree. And I think that the best way to do that is .... via clang. http://clang.llvm.org -- Marshall
Marshall Clow wrote:
I recently (2 weeks ago) started working for Grammatech (makers of CodeSonar, see http://grammatech.com), and one of the things they were looking for when we interviewed was the ability to help their static analysis get to where it could provide high quality feedback on modern C++. The tool makers are developing a strong interest in providing better analysis tools for C++, and hopefully that effort will succeed. John
Hi, I think you need to read the explainations that follow each statements from the google document. For example they don't say that they really don't use exceptions, they just cannot use them in their "old" base code (that was relying on old compilers) but allow usage in new softwares. Just picking titles without reading the whole document (that I feel globally makes sense because seems defined by practicallity) is not a good idea. By the way, I don't think saying that not using exception (for example) is bad practice, expecially on some embeded softwares. For example in video games on game console hardware it's just not viable as explained in the EASTL document there : http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2271.html Even Stroustrup (in his last book if my memory is right) says that in some limited environnements you just have to use a subset of C++. It's not bad, it's flexibility. I personally think that good practice and expeptionally breaking rule code living together is sane. So I don't clearly understand the idea behind the original mail of this thread. On Tue, Jan 26, 2010 at 00:38, John Phillips <phillips@mps.ohio-state.edu>wrote:
2010/1/26 joel falcou <joel.falcou@lri.fr>
What would you do if you had to do non-trivial (i.e. something that might fail) initialization in constructor but you weren't allowed to throw an exception? This rule is an obvious consequence of banning exceptions. And en exception ban is a consequence of having hundreds of millions lines of non-exception-safe code. Roman Perepelitsa.
On Mon, Jan 25, 2010 at 7:43 PM, joel falcou <joel.falcou@lri.fr> wrote:
I mean, 1970 called and they want them back ...
I find it really sad that Google (which is known world-wide to be a leader in technology) could violate such industry standards as not leaving an instance in an unknown state... and prohibiting exceptions. And both of them simplify code in exponential amounts. Google had the opportunity to create a (simple, at the time) algorithm that made them a lot of money, but violating these principles makes me seriously doubt their technological excellence. I hope that managers everywhere don't make the mistake of making Google's POV theirs. This, along with the EBML Ctrl-C Ctrl-V rip-off called "Protocol Buffers", makes me really doubt Google. For me, the Boost community knows more about C++ than a dozen blended Stroustrups. Cheers, Madera
"Marshall Clow" <mclow.lists@gmail.com> wrote in message news:D43C711F-03E0-4A3C-BE40-BA99BE379F30@gmail.com...
I think this is an embarrasement for google. Didn't they claim to hire only very good people? I would not want to work under these conditions. If there is again some security hole due to a buffer overflow, such an institution could claim, that software using fixed-sized-buffers would not get their stamp of approval. And that the customer should be looking and asking for this stamp of approval when buying software. How many fixed sized buffers are in the main OSs?
I have been developing software since the 1960's and in my experience the ones that complain the most either are the worst offenders of making readable code or are one of the very few that write code that mere mortals have trouble understanding (readable here meaning to someone other than the originator of the code). If you are trying to maintain several MLoc of code then guidellines such as the Google guidelines can help with consistency in form as newer programmers come on to maintain the code or add new function. I worked for a company that had guidelines since the 1960's. The "rules" were not static but evolved over time and were adapted as new languages became the basis of development. I do not recall an instance where the guidelines inhibited the development of good sound code. As for the fixed length buffers they are diminishing but there are probably lots of them still out there that just haven't shown up as security issues. Still, a lot of issues still show up - not necessarily in OS code but code perhaps just as critical. Much of this discussion will be similar to a discussion of "good and evil" as there is no one answer. Larry "There is nothing either good or bad but thinking makes it so." - William Shakespeare, "Hamlet", Act II, Scene V ----- Original Message ----- From: "Peter Foelsche" <foelsche@sbcglobal.net> To: <boost-users@lists.boost.org> Cc: <boost@lists.boost.org> Sent: Monday, January 25, 2010 5:28 PM Subject: Re: [Boost-users] C++ and quality of software
joel falcou a écrit :
We're mainly bitching about stupid assertion like the Init() vs ctor or the noe xception rule
If you don't have exceptions, you *need* two-phase construction.
which makes absolutely 0 sense in 2010.
Not using exceptions is very sensible if you: - have a lot of non exception-safe code or - do not wish to write exception-safe code. Google acknowledges that its developers aren't trained for this, and since they've also got a lot of legacy code, they've got both reasons. In any case, I prefer that kind of decision rather than using exceptions without enforcing exception-safety, like most developers seem to do.
This discussion is really not relevant to Boost, is it? At Mon, 25 Jan 2010 14:28:34 -0800, Peter Foelsche wrote:
-- Dave Abrahams Meet me at BoostCon: http://www.boostcon.com BoostPro Computing http://www.boostpro.com
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.
Patrick
"Patrick Horgan" <phorgan1@yahoo.com> wrote in message news:4B5F6B51.5070108@yahoo.com...
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 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.
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.
Aegypt? Sphinx? Pyramids?
Patrick
Peter Foelsche wrote:
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.
Patrick
"Patrick Horgan" <phorgan1@yahoo.com> wrote in message news:4B5F821C.60202@yahoo.com...
typedef std::vector<std::string> CStringVector; CStringVector sFileNames; for (CStringVector::const_iterator p = sFilenNmes.begin(), pEnd = sFileNames.end(); p != pEnd; ++p) { CFile sFile(*p); // use sFile here }
This thread is not on topic for boost-users. If I can put on my moderator hat for a moment, I'd like to ask those that are interested in pursuing it, to do so off-line. Thanks for your understanding. -- Jon Meet me at BoostCon http://boostcon.com
"Peter Foelsche" <foelsche@sbcglobal.net> wrote in message news:hjl0l9$2rr$1@ger.gmane.org...
(I consider usefulness of C++ Exceptions obvious -- no need for a discussion here). Nobody here cares about my suggestion for such a logo program? I think this would be a powerful method to get quality software. Of course this organization must be non-profit. As long as google follows their current coding guideline, they would not get this logo. As long as people are using MFC they also would not get this logo. There should be some advertisement so that customers look for it.
"Bronek Kozicki" <brok@spamcop.net> wrote in message news:4B5F7D4D.8090905@spamcop.net...
participants (15)
-
Bo Jensen -
Bronek Kozicki -
David Abrahams -
Hartmut Kaiser -
joel falcou -
John Phillips -
Jon Kalb -
Klaim -
Larry -
Marshall Clow -
Mathias Gaunard -
Patrick Horgan -
Peter Foelsche -
Rodrigo Madera -
Roman Perepelitsa