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

91–100 of 108 posts

Re: Google C++ Style Guide Is No Good

#91

Post by AstralStorm »

wyldfire wrote: post #87
Jyaif wrote: post #45

Earlier quoted context omitted.

You'd never see `v.resize(10, 42);` because 10 and 42 would be in self-documenting variables, e.g. ``` int kDefaultValue = 42; size_type kExpectedSize = 10; v.resize(kExpectedSize, kDefaultValue); ```

...though in this case it's still the reviewers job to help understand what the code does and if the reviewer doesn't know for sure which arg comes first then they still can't easily check that the code does what's intended.

The guide should then specify some common instances where arguments may be flipped.

Re: Google C++ Style Guide Is No Good

#93

Post by jcelerier »

groby_b wrote: post #38
jcelerier wrote: post #17

Earlier quoted context omitted.

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

> Literally the entire reason for having a coding standard is to have a well-defined subset of the language you're using.

that's a perversion of what "standards" means. Standards are originally there to codify existing practice, not to put new practice into existence. "#pragma once" is common enough that it has its own wikipedia page : https://en.wikipedia.org/wiki/Pragma_once with the list of all supported compilers.

Re: Google C++ Style Guide Is No Good

#94

Post by knorker »

> GSG prohibits the use of static definitions and annonymous namespaces in header files. How else do we declare constants?

Uhm… what?

1) I would challenge the author to produce any useful use of anonymous namespaces in header files that doesn't violate ODR. I'd also challenge them to not break ODR with constants in header files in the way they seem to mean.

I should add: without UB, plz.

2) How else do we declare constants? Uhm, how about: extern const int foo; or just "inline constexpr int foo = 1" in header but non-static and not in anonymous namespace?

> Globals like this are not problematic and very useful: [example of nontrivially destructible global]

It doesn't look dangerous, but allowing it does not scale to a billion lines of code. Code easier to reason about is less buggy code.

In general though: Author spends 1 SWE-year per year on coding, Google spends what, 100 SWE-millenia per year? It's optimizing for that use case.

Re: Google C++ Style Guide Is No Good

#95

Post by bluGill »

kazinator wrote: post #82
bluGill wrote: post #41

Earlier quoted context omitted.

it is also less bugprone in the real world. There are cases where it doesn't work, but they amount to stupid things that nobody does outside of contrived examples. I switched our codebase after finding several variations of #ifdef message_h #define massage_h That potential bug existed in our code base for years (I checked history)

The worst thing that happens due to this "potential bug" is that someone introduces a double inclusion of that header, which fails to be suppressed and the build blows up in their face due to duplicate definitions. The error could be diagnosed by the compiler---submit a patch to gcc! That is to say, if the following pattern occurs around the content of the file: #ifndef #define #endif the compiler can validate that a…

clang actually does have the warning you want gcc to have - this is how I found our instances of it.

What none of the above can do is two different projects have MESSAGE_H headers that are different can fully compatible to include both. #pragma once handles this correctly.

Re: Google C++ Style Guide Is No Good

#96

Post by kazinator »

bluGill wrote: post #95
kazinator wrote: post #82

Earlier quoted context omitted.

The worst thing that happens due to this "potential bug" is that someone introduces a double inclusion of that header, which fails to be suppressed and the build blows up in their face due to duplicate definitions. The error could be diagnosed by the compiler---submit a patch to gcc! That is to say, if the following pattern occurs around the content of the file: #ifndef #define #endif the compiler can validate that a…

clang actually does have the warning you want gcc to have - this is how I found our instances of it. What none of the above can do is two different projects have MESSAGE_H headers that are different can fully compatible to include both. #pragma once handles this correctly.

The clash between two different MESSAGE_H can be rendered vanishingly unlikely by having a convention of adding some random digits.

I adopted the following pattern some twenty years ago of affixing a random 32 bit number in hex:

   #ifndef MESSAGE_H_3DF0_9A73
   #define MESSAGE_H_3DF0_9A73

   #endif

Re: Google C++ Style Guide Is No Good

#97

Post by kazinator »

loeg wrote: post #84
tpolzer wrote: post #62

Earlier quoted context omitted.

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.

> You could say that there's no reason we're still using a stupid preprocessor hack of textual inclusion to import interfaces. You could say that. I didn't. Bolting on some sort of module system is just a totally different scope of enhancement than my modest proposal. > 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 inclu…

> It doesn't need to be robust against byzantine source trees

A locally developed hack, or even a compiler extension, doesn't have to be; an ISO-standard feature should be well specified.

If something is specified in such a way that it is less robust than the #ifndef trick, then any programmer worth their salt will use the #ifndef trick.

An acceptable pragma-once would look like this:

  #pragma once 9DF9-C3D9-BDF0
Basically it should take an argument string which specifies an ID for the file, intended to be unique.

Re: Google C++ Style Guide Is No Good

#98

Post by alexeiz »

The thing that bothers me about GSG is that it seems to be enforced across Google no matter what team you're in or what project you work on. Think about it: somebody who thinks that he knows better than you decided how you and other 10000s developers at Google should use C++. I think such approach is incredibly inflexible and shortsighted. Even if that somebody is a well-renowned C++ expert I would still doubt he can come up with the C++ style guide applicable to the whole Google. If I lead a project at Google I don't want someone unrelated to my project or some committee higher up to make decisions for my team. I want my team to decide how to use C++ (or any other language or technology for that matter) based on the project needs and the team developer skills. One coding style for everyone reduces the skill level of everyone to the lowest common denominator. Even if you have better skilled developers around you, if they can't use their skills professionally, they either quit or lose their skills. Soon you'll be surrounded by developers with only poor skills who you can learn nothing from. I remember a story told by Sean Parent (if you don't know him, look him up) about the time he worked at Google and he was told that his code is hard to understand because it uses concepts and ideas nobody at Google is familiar with (because they are likely not part of the GSG). I find that story quite instructive.

Re: Google C++ Style Guide Is No Good

#99

Post by loeg »

kazinator wrote: post #97
loeg wrote: post #84

Earlier quoted context omitted.

> You could say that there's no reason we're still using a stupid preprocessor hack of textual inclusion to import interfaces. You could say that. I didn't. Bolting on some sort of module system is just a totally different scope of enhancement than my modest proposal. > 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 inclu…

> It doesn't need to be robust against byzantine source trees A locally developed hack, or even a compiler extension, doesn't have to be; an ISO-standard feature should be well specified. If something is specified in such a way that it is less robust than the #ifndef trick, then any programmer worth their salt will use the #ifndef trick. An acceptable pragma-once would look like this: #pragma once 9DF9-C3D9-BDF0 Basi…

> ISO-standard feature should be well specified.

That claim doesn't match up with the C standard I've read. I.e., this is an "isolated demand for rigor." Are we looking at the same document? Quite a lot is underspecified or implementation defined to accommodate differences in architectures and systems.

The 2018 C standard doesn't specify whether NULL is a pointer or integer; what a null pointer's representation is; nor the representation of negative (signed) integers. The C standard defines some loose requirements around observable behavior and leaves the specific details to the implementation.

> Basically it should take an argument string which specifies an ID for the file, intended to be unique.

Or the standard could leave it up to the implementation to identify file uniqueness without this additional, incompatible argument. Like I said before, all you have to do for Unix implementations to be as robust as the stupid ifndef trick is to check st_ino and st_dev.

It's important to recognize that implementations and implementation details are distinct from the standard.

Also note that the ifndef hack is non-robust in its own way — false positive exclusions due to accidental identifier conflicts. #pragma once does not have this problem.

Re: Google C++ Style Guide Is No Good

#100

Post by loeg »

kazinator wrote: post #96
bluGill wrote: post #95

Earlier quoted context omitted.

clang actually does have the warning you want gcc to have - this is how I found our instances of it. What none of the above can do is two different projects have MESSAGE_H headers that are different can fully compatible to include both. #pragma once handles this correctly.

The clash between two different MESSAGE_H can be rendered vanishingly unlikely by having a convention of adding some random digits. I adopted the following pattern some twenty years ago of affixing a random 32 bit number in hex: #ifndef MESSAGE_H_3DF0_9A73 #define MESSAGE_H_3DF0_9A73 #endif

If only the filesystem would assign some sort of unique, 32- to 64-bit identifier to files that a compiler could use to distinguish one header from another. We could call them inode numbers. Hmm. No, I'm sure no one has ever thought of the problem of identifying unique files before.[0][1]

I guess instead we must embed GUIDs in every file to keep track of uniqueness.

[0]: https://stackoverflow.com/a/13172784/218830

[1]: https://stackoverflow.com/a/1866547/218830

Post reply on HN