Google C++ Style Guide

[Memloop]

What do you more experienced programmers think about Google's C++ style guide?

http://google-styleguide.googlecode....k/cppguide.xml


I've also read people talking about only using "safe" subsets of C++, so that could that could be discusses in this topic as well since it's related to Google's style guide. More particularly, what parts of the C++ language do you consider "safe", and which parts do you consider to be more error prone than the added functionality they give is worth.

I personally haven't used C++ enough to give any insightful comment on any of this, but I do know from the little programs I've had to write that exceptions are very hard to work with and always leave me wondering if a piece of code I haven't written myself will throw exceptions or not.

[IceDane]

It's their projects, so I guess they set the rules, but I would definitely not mind some explanations for some of their choices.

I mean, there are reasons why you might not use exceptions(Some might think that their cons outweigh their pros), but I would really like to hear why they chose as they did, not only for exceptions but for other things as well.

[anon]

If you don't consider exceptions part of the "safe" C++, then it would seem the rest of your code cannot be particularly safe either.

The style guide says that exceptions are fine, but their existing code is not exception-safe and hence they'd rather not use them.

[laserlight]

I mean, there are reasons why you might not use exceptions(Some might think that their cons outweigh their pros), but I would really like to hear why they chose as they did, not only for exceptions but for other things as well.

Their reasoning is given; you just need to click on the arrow.

[Memloop]

If you don't consider exceptions part of the "safe" C++, then it would seem the rest of your code cannot be particularly safe either.

I just think it's much harder to write code that deals with exceptions than code that deals with errors by return values.

Or do you not agree with this answer: 13 - Joel on Software

[laserlight]

I just think it's much harder to write code that deals with exceptions than code that deals with errors by return values.

Or do you not agree with this answer: 13 - Joel on Software

I do not agree with Joel Spolsky's point of view. This is a debate where the answer is probably "it depends". You can find more online material discussing the pros and cons of exceptions versus return values/error codes, but here is one that tries to directly address Joel's points: Exceptions vs. status returns.

[bithub]

That coding standard implicitly disallows the RAII design pattern. In my opinion, this greatly adds to the complexity of programming in C++. I thought my company's coding standard was bad, but it is much better than Google's.

[CornedBee]

I do know from the little programs I've had to write that exceptions are very hard to work with and always leave me wondering if a piece of code I haven't written myself will throw exceptions or not.

That's simple. Everything can throw, unless it is explicitly documented as nothrow. That may not be technically true, but it is a great guideline. Writing exception-safe code, to an experienced C++ programmer, should not be a complicated task, but simply the natural way of coding. Writing code with the basic safety guarantee ("don't corrupt the program") is easy and should not require any thought. Writing code with the strong safety guarantee ("all or nothing") is more demanding, but actually rarely needed.

The exception prohibition is the single most discussed element of these style guidelines. But I'm not happy with several other points.
The suggestion to use two-stage initialization ("Don't do work in constructors") is a (disastrous, IMO) consequence of the exception prohibition. Two-stage initialization is an incredibly destabilizing trait. Are you worried you don't know what code throws exception? Try worrying about what objects have a meaningful state.
Under "Operator Overloading", they discourage overloading of the assignment operator. This is absurd. If you want objects with value semantics, you have to overload assignment. Even if you don't overload any other operator, you should always be prepared to overload assignment if required. If a style guideline discourages this, then it should very strongly encourage using reference semantics only, i.e. not writing value classes. Make them all noncopyable. Not implementing assignment is just setting yourself up for disaster.
But the exceptions are the really tricky part. I, for one, think the rule wrong. Look at the cons for exceptions:

When you add a throw statement to an existing function, you must examine all of its transitive callers.

This is nonsense. Either your function never promised not to throw exceptions, in which case the callers should already be safe no matter what you throw. Or you previously promised not to throw, in which case you're breaking the interface of your function: the exception guarantee of a function is part of its interface! (Unfortunately, except for the nothrow guarantee, it is not documentable as a language feature.) If you change the error return of a function from 0 to -1, that's exactly the same. Not detectable by the compiler, and you have to examine every caller. And you don't have to transitively examine every caller if you introduce throwing to a previously nothrow function. You only need to do that for functions that were in turn nothrow. But if you detect such a dependency, then you might really, really think again about introducing throwing to the function. Remember: don't document a function as nothrow if it is only the current implementation that happens not to throw. Nothrow means, "I cannot logically fail." It is an inherent property of a function.

More generally, exceptions make the control flow of programs difficult to evaluate by looking at code: functions may return in places you don't expect. This results maintainability and debugging difficulties. You can minimize this cost via some rules on how and where exceptions can be used, but at the cost of more that a developer needs to know and understand.

This is half-true. The last part of the last sentence is true: there is a cost in developer knowledge on the comfortable use of exceptions. On the other hand, in my opinion there is no comfortable use of other error reporting mechanism no matter the developer knowledge.
Also, a function never returns in places I don't expect, because I expect every function to return from anywhere, unless I'm specifically looking to write a function with the strong exception guarantee, in which case I think about it a bit more.

Exception safety requires both RAII and different coding practices.

They claim that these coding practices have downsides. I say that the advantages of RAII and these coding practices always outweigh the costs, whether you use exceptions or not. This argument follows the very typical pattern in exception cons: ignoring that, if you don't use exceptions, you still have to detect and report errors. Making guarantees about behavior in the face of errors doesn't get any easier if you use return values instead of exceptions.

Turning on exceptions adds data to each binary produced, increasing compile time (probably slightly) and possibly increasing address space pressure.

True, but I'm not aware of any exhaustive test for the size of the code needed to deal with other error mechanisms. Are exception handling tables larger than ifs on every possibly failing function call?

The argument against exceptions comes down to this:

for existing code, the introduction of exceptions has implications on all dependent code.

Everything else is just a vain attempt at justification, instead of stating outright, "We have legacy code. Deal with it."
And yeah, making legacy code exception-safe is one major pain. I don't even try.

[cpjust]

I think their standards just plain suck. They sound like a bunch of C+ programmers. There are far more things I disagree with than I agree with.

[Dae]

I remember reading it and disagreeing with roughly 20% of it, and preferring a different choice 20% of the time. Adding up to 40% disapproval, 60% approval.