Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Google C++ Style Guide Is No Good

eyakubovich.github.io

Post reply on HN
Print view View original

61–70 of 108 posts

Re: Google C++ Style Guide Is No Good

#61

Post by sytelus »

jmgao wrote: post #8

I 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…

Same sentiment here. Many of GSG constraints are good and others are purely because of legacy code at Google. So don't take GSG as religion and implement it to the letter ask why this constraint is proposed and does it apply to my code?

> GSG forbids exceptions on the ground of “Google’s existing code is not exception-tolerant”.

Unless you are doing embedded software, you should use exceptions. I have tried this "modern" trend of returning instead of raising a few times and I'm not convinced at all its less bloated or less error prone way of doing things.

Re: Google C++ Style Guide Is No Good

#62

Post by tpolzer »

loeg wrote: post #48
kazinator wrote: post #6

> GSG prefers #ifndef/#define idiom over the simpler #pragma once. Yes, #pragma once is non-standard but widely supported. Google is right here; a purely build-time issue, like avoiding including a header file twice, should be solved without having to resort to nonstandard language features. The generated code doesn't change in any way, so it is gratuitous. Save the language extensions for doing something that is inh…

Meh. C and C++ should just standardize on #pragma once. Everything supports it. It's trivial for new compilers to implement. There's no reason a stupid preprocessor hack should still be required in order to prevent double-inclusion.

You could say that there's no reason we're still using a stupid preprocessor hack of textual inclusion to import interfaces.

As usual, the devil lies in the detail. If you want to make pragma once robust you need to checksum files, which in the end will be slower than include guards.

Re: Google C++ Style Guide Is No Good

#63

Post by tpolzer »

cletus wrote: post #21

Having written C++ at Google using these (strictly enforced) style guidelines, I actually kind of likes Google's subset of C++. It should be noted that any reasonably sized shop uses a subset of C++. It's insanity not to. It's just a question of what to allow and what not to. Google C++ uses a style of error-handling that's akin to how Go handles errors. Many functions return a util::Status (which would be OK or an e…

There's a very big C inherited footgun you can avoid with signed sizes: implicit conversions to unsigned on comparison.

Re: Google C++ Style Guide Is No Good

#64

Post by [deleted] »

tpolzer wrote: post #62
loeg wrote: post #48

Earlier quoted context omitted.

Meh. C and C++ should just standardize on #pragma once. Everything supports it. It's trivial for new compilers to implement. There's no reason a stupid preprocessor hack should still be required in order to prevent double-inclusion.

You could say that there's no reason we're still using a stupid preprocessor hack of textual inclusion to import interfaces. As usual, the devil lies in the detail. If you want to make pragma once robust you need to checksum files, which in the end will be slower than include guards.

[deleted]

Re: Google C++ Style Guide Is No Good

#65

Post by microtherion »

jcelerier wrote: post #42
cma wrote: post #11

Earlier quoted context omitted.

Template libraries that have to deal with stuff that could throw vs couldn't end up with lots of nearr duplicate code, twice as much needed test coverage, and/or less efficiency if you just cover the could-throw case. And you will still probably get it wrong. Exceptions can work ok in a GCed language, but I haven't seen them work well otherwise. Maybe it is possible, but in C++ it is a huge trap and isn't worth the e…

> Template libraries that have to deal with stuff that could throw vs couldn't end up with lots of nearr duplicate code, twice as much needed test coverage, and/or less efficiency if you just cover the could-throw case. And you will still probably get it wrong. what are you referring to ? I have never seen template libraries having to do anything particular wrt to exceptions. If you want to throw just throw, that's t…

Something like a std::vector constructor/assignment operator can get rather messy if the value type constructor can throw.

Re: Google C++ Style Guide Is No Good

#66

Post by kazinator »

loeg wrote: post #48
kazinator wrote: post #6

> GSG prefers #ifndef/#define idiom over the simpler #pragma once. Yes, #pragma once is non-standard but widely supported. Google is right here; a purely build-time issue, like avoiding including a header file twice, should be solved without having to resort to nonstandard language features. The generated code doesn't change in any way, so it is gratuitous. Save the language extensions for doing something that is inh…

Meh. C and C++ should just standardize on #pragma once. Everything supports it. It's trivial for new compilers to implement. There's no reason a stupid preprocessor hack should still be required in order to prevent double-inclusion.

Is it trivial to implement?

The detailed semantics of #pragma once is murky. If #pragma once appears in a file, will that preclude an identical copy of the file from being included? Do we go by content, or just some filesystem identifier like device and inode number? Or the absolute path? Will #pragma once preclude that same file from being included again through a symbolic or hard link? Is the answer the same for all compilers?

The semantics of the #ifndef/#define/#endif trick is crystal clear; we can predict what it will do in any given situation. The identity of the file, for the purpose of suppressing duplicates, is tied to a made-up symbol which the program explicitly specifies, and that's that. It may go wrong (e.g. due to clashes on the identifier between unrelated files), but in a way that is understandable.

#pragma once seems like a bad trade-off for the sake of saving two lines of preprocessing.

Re: Google C++ Style Guide Is No Good

#67

Post by ridiculous_fish »

hendzen wrote: post #28
stdplaceholder wrote: post #23

Earlier 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.

Exceptions impose indirect costs other than just code size. For example, when std::vector reallocates, it copies instead of moves its elements, in case the move constructor throws and leaves the vector in an inconsistent state.

Re: Google C++ Style Guide Is No Good

#68

Post by kazinator »

tpolzer wrote: post #62
loeg wrote: post #48

Earlier quoted context omitted.

Meh. C and C++ should just standardize on #pragma once. Everything supports it. It's trivial for new compilers to implement. There's no reason a stupid preprocessor hack should still be required in order to prevent double-inclusion.

You could say that there's no reason we're still using a stupid preprocessor hack of textual inclusion to import interfaces. As usual, the devil lies in the detail. If you want to make pragma once robust you need to checksum files, which in the end will be slower than include guards.

If you want to make #pragma once robust, you firstly have to specify the requirements rigorously. The requirements can be specified in such a way that checksumming of files is avoided. We can stipulate that exact (as well as inexact) copies of a file are distinct objects with their own identity under #pragma once, and are not mutually excluded.

#pragma once can be defined in terms of a reference model whereby it is equivalent to a machine-generated sequence:

  #ifndef 
  #define 

  #endif
where the detailed semantics is tied to how the machine generates .

If is a digest of the absolute path, then references to the same file via different hard or symbolic links look different and do not mutually exclude.

If is produced from the volume and object identifier (like inode number) then different links to the same header will mutually exclude.

If is a content hash, then identical files will mutually exclude (but we need to deal with hash collisions somehow).

A much better solution would be to sidestep this whole thing entirely and just allow any file-scope definition in C++ to be repeated in the same translation unit (with some proviso, like that the multiple definitions have to be identical; and that could be enforced with diagnostics). The multiple inclusions of the same material aren't a problem.

Re: Google C++ Style Guide Is No Good

#69

Post by eyakubovich »

jupp0r wrote: post #29

It 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 trouble with "this is not the law" argument is that it's not clear how to make the judgement. The reviewer should be using the style guide during the review and should call out any violations. A restrictive guide then places a huge burden on the author to justify the deviations.

Re: Google C++ Style Guide Is No Good

#70

Post by DannyBee »

It's very interesting to me that the author writes a critique of a style guide, but doesn't seem to have tried to understand the perspective of those who created it or what their goals were (they basically give this lip service)

They don't really try and understand the rationale in detail and then argue that that rationale would be better served through a different set of features, they mostly just say "hey I think Google is wrong and these features are pretty cool"

Post reply on HN