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

C++ at Google: Here Be Dragons

blog.llvm.org

Post reply on HN
Print view View original

11–20 of 91 posts

Re: C++ at Google: Here Be Dragons

#11

Post by marshray »

matthavener wrote: post #3

I wonder if this is an indication that google is moving to clang for compiling (and not just diagnostic tools). If that's true, maybe this is another nail in the coffin for gcc? I see apple and google behind llvm/clang, who's behind gcc? Nobody?

GCC has enabled Apple and Google far more than the other way around. Clang and LLVM sound like great projects, but I hardly think GCC is heading for the grave anytime soon.

http://gcc.gnu.org/releases.html#timeline http://www.gnu.org/philosophy/pragmatic.html (see part about Objective C)

Re: C++ at Google: Here Be Dragons

#13

Post by chandlerc »

anonymous246 wrote: post #10

I wonder how their checks compare to Coverity's and QAC++'s. I have a passing acquaintance with both, and I'm almost certain both would have caught the three bugs listed on that page.

I would expect many of these tools to catch these types of bugs. The challenging thing for us has been to catch only bugs, and to catch them very fast during normal compilation.

A lot of the static analyses we've looked into (and I'm hoping for more detailed blog posts about that in the future) find plenty of bugs, but also find lots of non-bugs. Combine that with being too slow to run during the normal build, and you can't break the build when such a bug is found.

I think one of the most interesting aspects of this is how we catch the bugs early, and force developers to fix them immediately by breaking the build.

Re: C++ at Google: Here Be Dragons

#15

Post by loup-vaillant »

irons wrote: post #8
wmobit wrote: post #6

Earlier quoted context omitted.

Google has said before they didn't use Clang and LLVM because of performance issues. GCC is far from dead, and probably never will. Clang generated code is still typically 10-20% slower than GCC. Lots of companies work on GCC, including Google, Intel, AMD, IBM, Red Hat and others.

Apple's been pushing developers toward LLVM for several years, and is bound to make it an app store requirement at some point. I've observed no such 10-20% slowdown on iOS, which is more CPU-constrained than most realms. Typically, LLVM-generated code is equivalent to or faster than gcc. Sometimes it's much faster.

Just a guess: couldn't be an x86(-64) vs ARM thing? Like GCC being better on x86, and LLVM on par with it on ARM? Or maybe they tuned the compiler for the iDevices?

Re: C++ at Google: Here Be Dragons

#16

Post by timr »

To me, the most remarkable thing about this post is that when the rest of the world is falling in love with the "power" of weak typing systems, Google is going the other way.

Re: C++ at Google: Here Be Dragons

#17

Post by nikki9696 »

chandlerc wrote: post #14
mayoff wrote: post #12

When will they enhance it to flag the other error in this line: long kMaxDiskSpace = 10 10<<30 is ten gigs, not thirty gigs.

Doh! Good catch, comment updated. =[ Maybe we do need Clang-for-comments as well as Clang-for-C++ code.... ;]

And the error says it's an int, but it's declared long. Am I missing something about long in C++ not being 64 bits?

Re: C++ at Google: Here Be Dragons

#18

Post by chandlerc »

nikki9696 wrote: post #17
chandlerc wrote: post #14

Earlier quoted context omitted.

Doh! Good catch, comment updated. =[ Maybe we do need Clang-for-comments as well as Clang-for-C++ code.... ;]

And the error says it's an int, but it's declared long. Am I missing something about long in C++ not being 64 bits?

That's the whole point. =] This is a surprising aspect of C++: the shift expression doesn't have the type of the declared variable.

The integer literals we are shifting are of 'int' type, and the shift occurs at that type (based on the usual arithmetic conversions). There is stack overflow question with explanations and a good blog post here about it:

http://stackoverflow.com/questions/836544/usual-arithmetic-c...

http://blogs.msdn.com/b/oldnewthing/archive/2004/03/10/87247...

Also, you can look through the C++98 standard to understand all the details. Relevant sections are [expr]p9 and [expr.shift].

Re: C++ at Google: Here Be Dragons

#19

Post by DarkShikari »

nikki9696 wrote: post #17
chandlerc wrote: post #14

Earlier quoted context omitted.

Doh! Good catch, comment updated. =[ Maybe we do need Clang-for-comments as well as Clang-for-C++ code.... ;]

And the error says it's an int, but it's declared long. Am I missing something about long in C++ not being 64 bits?

long is 32-bit on x86_32 Linux, 64-bit on x86_64 Linux, and 32-bit on x86_64 Windows.

Re: C++ at Google: Here Be Dragons

#20

Post by tedunangst »

jrockway wrote: post #7
matthavener wrote: post #3

I wonder if this is an indication that google is moving to clang for compiling (and not just diagnostic tools). If that's true, maybe this is another nail in the coffin for gcc? I see apple and google behind llvm/clang, who's behind gcc? Nobody?

who's behind gcc? Nobody? I hear there's this kernel called Linux that depends heavily on GCC.

And Linus's feelings about that relationship are...?
Post reply on HN