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

101–108 of 108 posts

Re: Google C++ Style Guide Is No Good

#101

Post by loeg »

tpolzer wrote: post #63
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.

GCC has had -Wsign-compare:

       -Wsign-compare
           Warn when a comparison between signed and unsigned values could
           produce an incorrect result when the signed value is converted to
           unsigned.  In C++, this warning is also enabled by -Wall.  In C, it
           is also enabled by -Wextra.
Since 1996. https://github.com/gcc-mirror/gcc/commit/de9554eb8ae74764555...

(And prior to that explicit option, it was just enabled as part of -Wextra/-W, from 1995: https://github.com/gcc-mirror/gcc/commit/7030c69607d547b3227... . For comparison, Google was founded in 1996.)

I buy that some of the integer promotion rules really suck, and Google's founders learned C prior to 1996. But the compiler has been able to warn us about this particular footgun for a long time.

Re: Google C++ Style Guide Is No Good

#102

Post by kazinator »

loeg wrote: post #100
kazinator wrote: post #96

Earlier quoted context omitted.

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…

Copies of a file have different inode numbers.

Re: Google C++ Style Guide Is No Good

#103

Post by kazinator »

loeg wrote: post #99
kazinator wrote: post #97

Earlier quoted context omitted.

> 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; n…

The #ifndef trick is highly portable and has clear semantics that is under the program's control. Nobody needs a platform-specific, underspecified alternative that saves two lines of code compared to the robust, portable solution. If I am paying with nonportability, I want "bang for the buck": like faster or smaller code on the target, or detailed control of its hardware or host platform features. I don't need unspecified build machine behavior so much. I am not programming the build machine.

Re: Google C++ Style Guide Is No Good

#104

Post by loeg »

kazinator wrote: post #102
loeg wrote: post #100

Earlier quoted context omitted.

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…

Copies of a file have different inode numbers.

I can agree with this statement of fact. I'm missing the part where it's relevant to the conversation or informs some conclusion.

Re: Google C++ Style Guide Is No Good

#105

Post by kazinator »

loeg wrote: post #104
kazinator wrote: post #102

Earlier quoted context omitted.

Copies of a file have different inode numbers.

I can agree with this statement of fact. I'm missing the part where it's relevant to the conversation or informs some conclusion.

It's relevant if I have a requirement that if a file happens to be duplicated, then the once-include mechanism should treat those copies as one object.

This could arise if the code is originally on a system where some header files are symlinks to a common file. These symlinks happen to break (due to the way the code is archived, or on some system that doesn't have symlinks or whatever); they turn into separate copies.

Exclusion that is keyed to a symbol that is encoded in the file has no problem with this; filesystem-id-based excusion doesn't handle the case.

Re: Google C++ Style Guide Is No Good

#106

Post by loeg »

kazinator wrote: post #105
loeg wrote: post #104

Earlier quoted context omitted.

I can agree with this statement of fact. I'm missing the part where it's relevant to the conversation or informs some conclusion.

It's relevant if I have a requirement that if a file happens to be duplicated, then the once-include mechanism should treat those copies as one object. This could arise if the code is originally on a system where some header files are symlinks to a common file. These symlinks happen to break (due to the way the code is archived, or on some system that doesn't have symlinks or whatever); they turn into separate copies…

> It's relevant if I have a requirement that if a file happens to be duplicated, then the once-include mechanism should treat those copies as one object.

I don't believe that is a reasonable requirement.

Re: Google C++ Style Guide Is No Good

#107

Post by Chyzwar »

olliej wrote: post #76
Chyzwar wrote: post #73

Earlier quoted context omitted.

This attitude leads to companies to maintain COBOL codebases on the obscure mainframe for decades.

Why is that bad? If the system works, and is fast and efficient enough for the task (which is clearly is), and supports the needed features (there was an article on the things you could do in COBOL a while back that went over this), then what is the benefit? Sure maintaining something is not as "fun" as writing a new thing, but that doesn't make it better. Anyway, the "obscure mainframes" isn't true - yes there are c…

Problem is that you are locking yourself. Even if this work for decades it can destroy your company. At some point, you will not be able to respond to change. More agile, faster-moving competitors will eat your lunch.

I am not suggesting rewriting to use new shiny things. If the platform is deprecated (32bit, mainframes, windows98, C89, etc) you migrate your code when it is still possible. Customers can still use an older version of your software is they are stuck in the past but you are not compromising future of your product.

Re: Google C++ Style Guide Is No Good

#108

Post by Chyzwar »

dragonwriter wrote: post #74
Chyzwar wrote: post #73

Earlier quoted context omitted.

This attitude leads to companies to maintain COBOL codebases on the obscure mainframe for decades.

Yes,it motivates companies not to do expensive, unnecessary, high-risk complete replacements. This may be less fun for developers, but it's not usually a bad decision.

High-risk complete replacements happen because some risk-averse developers/management resisted change for decades and now the company cannot gradually modernize.

https://en.wikipedia.org/wiki/Phoenix_pay_system

Post reply on HN