On Jan 25, 2010, at 1:18 PM, Bo Jensen wrote:

On Mon, Jan 25, 2010 at 9:58 PM, 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 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

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 Mon, Jan 25, 2010 at 10:43 PM, joel falcou wrote:

Marshall Clow wrote:

...

Yes they do. It includes nuggets like this

And the all mighty: http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml?showone=Doing...

I mean, 1970 called and they want them back ...

-- ___________________________________________ Joel Falcou - Assistant Professor PARALL Team - LRI - Universite Paris Sud XI Tel : (+33)1 69 15 66 35

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

Hey I was not saying they were right, merely pointing out other approaches. Some kind of boost cpplint might be a simple solution.

On Jan 25, 2010, at 1:49 PM, joel falcou wrote:

Bo Jensen wrote:

...

Hey I was not saying they were right, merely pointing out other approaches. Some kind of boost cpplint might be a simple solution Was just a bit amazed to find such stuff there, not criticizing your contribution.

The boostlint idea is sound :)

I agree. And I think that the best way to do that is .... via clang. http://clang.llvm.org -- Marshall

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.

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 wrote:

Marshall Clow wrote:

...

On Jan 25, 2010, at 1:49 PM, joel falcou wrote:

Bo Jensen wrote:

...

...

Hey I was not saying they were right, merely pointing out other approaches. Some kind of boost cpplint might be a simple solution

Was just a bit amazed to find such stuff there, not criticizing your contribution.

The boostlint idea is sound :)

I agree. And I think that the best way to do that is .... via clang. http://clang.llvm.org

-- Marshall

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

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

2010/1/26 joel falcou

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 don't gringe that much on the no exveption rules, but the no ctor but init() method feels like 1980's bad C++ lessons.

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 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" wrote in message news:D43C711F-03E0-4A3C-BE40-BA99BE379F30@gmail.com...

Exceptions ▶ We do not use C++ exceptions.

Run-Time Type Information (RTTI) ▶ We do not use Run Time Type Information (RTTI).

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?

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. We're mainly bitching about stupid assertion like the Init() vs ctor or

Larry wrote: the noe xception rule which makes absolutely 0 sense in 2010.

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. FLB is the less annoying of their rules in fact. I don't think we bitch about that

-- ___________________________________________ Joel Falcou - Assistant Professor PARALL Team - LRI - Universite Paris Sud XI Tel : (+33)1 69 15 66 35

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.

...

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.

Sure, and the best cure for a headache is to cut off the head... Regards Hartmut --------------- Meet me at BoostCon www.boostcon.com

"Patrick Horgan" wrote in message news:4B5F6B51.5070108@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

"Patrick Horgan" wrote in message news:4B5F821C.60202@yahoo.com...

...

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?

typedef std::vectorstd::string CStringVector; CStringVector sFileNames; for (CStringVector::const_iterator p = sFilenNmes.begin(), pEnd = sFileNames.end(); p != pEnd; ++p) { CFile sFile(*p); // use sFile here }

...

What about after a close() and a subsequent open() in a routine processing a series of files? typedef std::vectorstd::string CStringVector;

CStringVector sFileNames;

for (CStringVector::const_iterator p = sFilenNmes.begin(), pEnd = sFileNames.end(); p != pEnd; ++p) { CFile sFile(*p); Is that an MFC CFile!? Won't work on linux! LOL. Anyway, not standard, certainly not the fstream we were talking about, and although I don't know anything about construction cost, I do know you'll have to

Peter Foelsche wrote: ...elision by Patrick... (I wrote;) pay it every time through the loop. That's cool. I understand the disconnect in our communications a lot better now:) Patrick

On 26/01/2010 22:31, Peter Foelsche wrote:

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.

frankly, the whole idea is bit silly. B. PS. I was sitting quiet 4 or more years, and this thing got me out!