Google C++ Style Guide

This is a discussion on Google C++ Style Guide within the C++ Programming forums, part of the General Programming Boards category; 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 ...

  1. #1
    Registered User
    Join Date
    Mar 2009
    Posts
    399

    Google C++ Style Guide

    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.

  2. #2
    Ex scientia vera
    Join Date
    Sep 2007
    Posts
    478
    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.
    "What's up, Doc?"
    "'Up' is a relative concept. It has no intrinsic value."

  3. #3
    The larch
    Join Date
    May 2006
    Posts
    3,573
    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.
    I might be wrong.

    Thank you, anon. You sure know how to recognize different types of trees from quite a long way away.
    Quoted more than 1000 times (I hope).

  4. #4
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    21,713
    Quote Originally Posted by IceDane
    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.
    C + C++ Compiler: MinGW port of GCC
    Version Control System: Bazaar

    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  5. #5
    Registered User
    Join Date
    Mar 2009
    Posts
    399
    Quote Originally Posted by anon View Post
    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

  6. #6
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    21,713
    Quote Originally Posted by Memloop
    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.
    C + C++ Compiler: MinGW port of GCC
    Version Control System: Bazaar

    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  7. #7
    Registered User
    Join Date
    Sep 2004
    Location
    California
    Posts
    3,246
    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.
    bit∙hub [bit-huhb] n. A source and destination for information.

  8. #8
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    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.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  9. #9
    and the hat of sweating
    Join Date
    Aug 2007
    Location
    Toronto, ON
    Posts
    3,545
    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.
    "I am probably the laziest programmer on the planet, a fact with which anyone who has ever seen my code will agree." - esbo, 11/15/2008

    "the internet is a scary place to be thats why i dont use it much." - billet, 03/17/2010

  10. #10
    Dae
    Dae is offline
    Deprecated Dae's Avatar
    Join Date
    Oct 2004
    Location
    Canada
    Posts
    1,034
    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.
    Warning: Have doubt in anything I post.

    GCC 4.5, Boost 1.40, Code::Blocks 8.02, Ubuntu 9.10 010001000110000101100101

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. favorite style guide?
    By m37h0d in forum C++ Programming
    Replies: 4
    Last Post: 04-01-2008, 10:31 AM
  2. WM_CAPTION causing CreateWindowEx() to fail.
    By Necrofear in forum Windows Programming
    Replies: 8
    Last Post: 04-06-2007, 08:23 AM
  3. Button handler
    By Nephiroth in forum Windows Programming
    Replies: 8
    Last Post: 03-12-2006, 05:23 AM
  4. Tab Controls - API
    By -KEN- in forum Windows Programming
    Replies: 7
    Last Post: 06-02-2002, 09:44 AM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21