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

21–30 of 91 posts

Re: C++ at Google: Here Be Dragons

#21

Post by profquail »

timr wrote: post #16

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 .

the rest of the world is falling in love with the "power" of weak typing systems

Really? I'd argue the exact opposite -- with F# and Scala (and some others) on the rise, I think there are plenty of people who are fed up with weak/dynamic typing and want to take advantage of building programs with strong type systems.

At the very least, it seems that the programming world is becoming much more polarized. Anecdotally, it seems that every developer I know is either a proponent of strong/static typing or weak/dynamic typing -- but I don't know anyone that's just sitting on the fence.

Re: C++ at Google: Here Be Dragons

#22

Post by undees »

profquail wrote: post #21
timr wrote: post #16

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 .

the rest of the world is falling in love with the "power" of weak typing systems Really? I'd argue the exact opposite -- with F# and Scala (and some others) on the rise, I think there are plenty of people who are fed up with weak/dynamic typing and want to take advantage of building programs with strong type systems. At the very least, it seems that the programming world is becoming much more polarized. Anecdotally,…

The term "strong" appears overloaded here. A language can be dynamically typed, but still have strong typing (in the sense that the language, whether at compile time or runtime, enforces what operations are allowed on a particular value).

Re: C++ at Google: Here Be Dragons

#23

Post by mcbain »

chandlerc wrote: post #13
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 yo…

Static analysis is a great tool - Clang's isn't too bad - but it isn't the right one to drop into a normal workflow.

We still develop using GCC - for our use case Clang performance isn't there yet - but have our continuous integration system perform Clang builds (as well as other platform/compiler variants, with unit+regression tests, etc.) so we miss out on the immediate build breakage that you mention, but do find out within ~30 mins if someone slipped up.

Re: C++ at Google: Here Be Dragons

#24

Post by spitfire »

chandlerc wrote: post #13
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 yo…

These sort of articles (and the attendant comments about false positives) always scream out for Ada to me. It's a language designed by a calm, careful thinker back in the 80's for life critical programs. It has everything Java and C++ have except the vast number of undefined states and it's designed for static analysis. By designed I mean, there are formal verifiers and the NSA has used it in a test security system.

Plus the compiled code is pretty fast. So if you're feeling the need to reduce your workload take a look at it, you might be surprised.

Re: C++ at Google: Here Be Dragons

#25

Post by michaelcampbell »

timr wrote: post #16

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 .

I hear you, but I think the rest of the world is actually polarizing to some degree. Perhaps I'm just fickle or a language whore, but I love both the dynamism and freedom of Ruby (et. al.) and the "protect me from doing stupid $#@!" of Scala (et. al.) Although honestly, I don't know that I'd want a language that supported both, if even such a thing were possible.

I do see a lot of people getting all hung up on one side or the other though; and it could be that the rest of the world you are seeing is just that group "over there".

Perhaps predictably, as I get older (in my 40's now), I am leaning more towards the strong type system languages, but I do enjoy my dalliances with a dynamic language, at least for small things.

Re: C++ at Google: Here Be Dragons

#26

Post by michaelcampbell »

profquail wrote: post #21
timr wrote: post #16

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 .

the rest of the world is falling in love with the "power" of weak typing systems Really? I'd argue the exact opposite -- with F# and Scala (and some others) on the rise, I think there are plenty of people who are fed up with weak/dynamic typing and want to take advantage of building programs with strong type systems. At the very least, it seems that the programming world is becoming much more polarized. Anecdotally,…

I'm a fence-sitter, but as you note, it's unlikely you know me. I do find that I'm starting to lean more on the strong/static side lately, but that might be because professionally I write financial institution software which tends to be big, and I want as much checked as early and as thoroughly as possible.

For fun hobby stuff, I love dynamic languages where I can produce quite a bit of functionality in a very short (if dangerous) time and rely on a set of tests to keep it all managed.

Re: C++ at Google: Here Be Dragons

#27

Post by nradov »

michaelcampbell wrote: post #25
timr wrote: post #16

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 .

I hear you, but I think the rest of the world is actually polarizing to some degree. Perhaps I'm just fickle or a language whore, but I love both the dynamism and freedom of Ruby (et. al.) and the "protect me from doing stupid $#@!" of Scala (et. al.) Although honestly, I don't know that I'd want a language that supported both, if even such a thing were possible. I do see a lot of people getting all hung up on one si…

Why can't we have a language that supports both? I would love to have a language with a scalable type system where I could hack out a quick small prototype with dynamic typing first, and then perhaps layer on static types later where necessary to improve reliability and performance as the program evolves. For example, I would like to be able to declare a variable in all of the following different ways.

a value

a number

a rational number

a rational number between [0.0 - 1.0)

a rational number between [0.0 - 1.0), and I don't need any more than 30 bits of precision

a rational number between [0.0 - 1.0), and I don't need any more than 30 bits of precision, and please try to optimize for minimum memory usage instead of performance

Re: C++ at Google: Here Be Dragons

#28

Post by swannodette »

profquail wrote: post #21
timr wrote: post #16

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 .

the rest of the world is falling in love with the "power" of weak typing systems Really? I'd argue the exact opposite -- with F# and Scala (and some others) on the rise, I think there are plenty of people who are fed up with weak/dynamic typing and want to take advantage of building programs with strong type systems. At the very least, it seems that the programming world is becoming much more polarized. Anecdotally,…

Those in favor of only static typing and those in favor of only dynamic typing are living in the past. Any interesting evolution in programming languages will allow developers to program with and without types / contracts from the same language.

Re: C++ at Google: Here Be Dragons

#29

Post by daniel-cussen »

undees wrote: post #22
profquail wrote: post #21

Earlier quoted context omitted.

the rest of the world is falling in love with the "power" of weak typing systems Really? I'd argue the exact opposite -- with F# and Scala (and some others) on the rise, I think there are plenty of people who are fed up with weak/dynamic typing and want to take advantage of building programs with strong type systems. At the very least, it seems that the programming world is becoming much more polarized. Anecdotally,…

The term "strong" appears overloaded here. A language can be dynamically typed, but still have strong typing (in the sense that the language, whether at compile time or runtime, enforces what operations are allowed on a particular value).

This is true. Lisp compiles beautifully if you put the work into making it do so, and this work can be automated with macros.

Re: C++ at Google: Here Be Dragons

#30

Post by archangel_one »

The article implies to me that the third bug (passing 0.5 to sleep() ) is not caught by gcc. Does anyone know if this is the case? It doesn't seem excessively hard to produce a warning about shortening like that - the first two seem more subtle, but that one less so. I don't have gcc on this machine to check it, but VC++ certainly does emit a warning for that kind of thing.
Post reply on HN