Google's
Google C++ Style Guide Is No Good
31–40 of 108 posts
Re: Google C++ Style Guide Is No Good
#32Earlier quoted context omitted.
It results in slower generated code and much larger binaries, neither of which would be acceptable to Google (some of their binaries are already on the brink of being unbuildable, so a bunch of junk to enable exceptions is not possible.)
the slower generated code is an academic concern. Show me a realistic/non-contrived benchmark where not keeping the stack unwindable actually helps give a useful performance increase. Error codes force people to litter the code with branches and put error handling code in the hot path of the instruction stream.
Using 'likely/unlikely' compiler directives, the instructions in the unlikely error branch can be hoisted out to another area and not significantly affect instruction cache. It still is a branch though.
Re: Google C++ Style Guide Is No Good
#33Regarding the advice on globals, and the comments here regarding destructors, how does `constexpr` interact with RAII?
Are `constexpr` values destructed when they go out of scope? Or is it simply not possible to `constexpr` them?
Re: Google C++ Style Guide Is No Good
#34Regarding the advice on globals, and the comments here regarding destructors, how does `constexpr` interact with RAII? Are `constexpr` values destructed when they go out of scope? Or is it simply not possible to `constexpr` them?
constexpr variables must have a literal type, which requires a trivial destructor.
Re: Google C++ Style Guide Is No Good
#35It seems like the author didn't read the guidelines very well. Especially this part: "The intent of this document is to provide maximal guidance with reasonable restriction. As always, common sense and good taste should prevail." There are good arguments for deriving from the guidelines in lots of situations, guidelines merely establish the default style, but don't prohibit code that does not follow the guidelines _i…
The author is complaining about the use of these guidelines in other places outside Google, especially for people who take these guidelines more seriously than Google itself.
Re: Google C++ Style Guide Is No Good
#36I disagree with a lot of the Google C++ style guide, but I disagree with many of the complaints in the post. > Although GSG does not forbid them categoricaly, it says to “Avoid using forward declarations where possible”. However forward declarations are useful in contexts like the following: ... Yes, those are the cases where it isn't possible to avoid forward declarations, so it's fine to use them? > While it’s true…
> No, globals like that are very problematic
Indeed, they're terrible. What I don't understand is why basically every Google-authored project has loads of these (protobuf, gflags, TensorFlow...)
Re: Google C++ Style Guide Is No Good
#37I think the author misunderstands the difference between his use of C++ and Google's use, where Google wants to treat thousands of developers are largely exchangeable over billions of lines of code.
joy
Re: Google C++ Style Guide Is No Good
#38I don’t particularly like the style guide either, but the reasons presented here aren’t great: > GSG prefers #ifndef/#define idiom over the simpler #pragma once. Yes, #pragma once is non-standard but widely supported. I mean, it’s non-standard. What more do you need? > Although GSG does not forbid them categoricaly, it says to “Avoid using forward declarations where possible”. The example provided is like the one pla…
> I mean, it’s non-standard. What more do you need? so are most programming languages used in the world. In practice, #pragma once is less trouble than #ifdef ; we had the debate just today in reddit :-) https://www.reddit.com/r/cpp/comments/a14o5q/real_world_prob...
Nobody is proposing a non-standard language, that's the point. Literally the entire reason for having a coding standard is to have a well-defined subset of the language you're using.
Meanwhile, the "trouble" the reddit thread comes up with is copy/paste programming for #ifdef. That's a one-time effort of writing a commit hook that checks for that. But no amount of effort will ensure the next compiler you need supports #pragma once
Re: Google C++ Style Guide Is No Good
#39I think the author misunderstands the difference between his use of C++ and Google's use, where Google wants to treat thousands of developers are largely exchangeable over billions of lines of code.
One problem is that many people fail to make that distinction and then cargo cult whatever google puts forth for style guides
People need to remember that just because Google does something one way does not imply it is correct nor that it is incorrect
Re: Google C++ Style Guide Is No Good
#40Earlier quoted context omitted.
it really isn't that hard if you practice RAII properly. I've used C++ exceptions on several large C++ codebases and not run in to major issues.
It results in slower generated code and much larger binaries, neither of which would be acceptable to Google (some of their binaries are already on the brink of being unbuildable, so a bunch of junk to enable exceptions is not possible.)
Also... there is a proposal to fix the overhead of the code that current compilers generate for exception based code.
P0709 R0 – Zero-overhead deterministic exceptions
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p070...