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

51–60 of 91 posts

Re: C++ at Google: Here Be Dragons

#51

Post by lurker19 »

chandlerc wrote: post #36
archangel_one wrote: post #30

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.

GCC definitely has a warning for 0.5 -> int (likely -Wconversion, but I've not checked). It also has a warning for setting a pointer to "false" (-Wconversion-null). However, turning that warning on in a codebase where every warning breaks the build was challenging because of false positives. We're able to remove false positives and narrow the scope of the warning to just the buggy code in many cases with Clang, and t…

When is assigning a pointer to be boolean false intentional and correct?

Re: C++ at Google: Here Be Dragons

#52

Post by anamax »

nradov wrote: post #27
michaelcampbell wrote: post #25

Earlier quoted context omitted.

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

> a rational number

> a rational number between [0.0 - 1.0)

Those are representation errors.

The hard problems that I run into rarely have much to do with representation. The hard problems are knowing when it's okay to add apples and oranges and when it isn't.

Re: C++ at Google: Here Be Dragons

#54

Post by jamesaguilar »

SwellJoe wrote: post #42

I haven't worked in C (or C++) heavily in about 6 years, since I shut down my prior company and stopped working on Squid or having to look at kernel code. But, these errors are simply beautiful, and make me have vague longings to work on C projects again (I'm sure I'll get over those longings soon). These are the kinds of mistakes I made all the time when working in C, and the kind of thing that made coding extremely…

> I'm sure I'll get over those longings soon

Your getting over those longings will probably coincide with when you start working with C++ again.

Re: C++ at Google: Here Be Dragons

#55

Post by cpeterso »

lurker19 wrote: post #51
chandlerc wrote: post #36

Earlier quoted context omitted.

GCC definitely has a warning for 0.5 -> int (likely -Wconversion, but I've not checked). It also has a warning for setting a pointer to "false" (-Wconversion-null). However, turning that warning on in a codebase where every warning breaks the build was challenging because of false positives. We're able to remove false positives and narrow the scope of the warning to just the buggy code in many cases with Clang, and t…

When is assigning a pointer to be boolean false intentional and correct?

I think the -Wconversion-null warnings are the other way around:

    int i = NULL;
Because of C++'s conflation of NULL and 0 (and now C++0x's nullptr).

Re: C++ at Google: Here Be Dragons

#56

Post by protomyth »

spitfire wrote: post #48
iskander wrote: post #46

Earlier quoted context omitted.

Admittedly I only programmed in Ada for a few months, but I found it to be an unbearably tedious language. The verbosity is monstrous--- the type system is inexpressive; it feels primitive. Nothing is inferred, everything is repeated. Ugh, I would rather code exclusively in C++ templates than touch Ada again.

I will freely admit that Ada is not appropriate for all uses. But for the sort of thing you'd want to use Ada for (life critical systems, critical infrastructure, control systems, etc) The explicit type system, explicit declaration, statically typed system is ideal. I particularly like the ability to declare down to the bit level how my data is stored. Very useful for working with low level hardware. Take a look agai…

I would also add that Ada compilers do generate some surprisingly efficient executables. This helps quite a lot in the embeded space.

Re: C++ at Google: Here Be Dragons

#57

Post by SoftwareMaven »

chancho wrote: post #45
DanielRibeiro wrote: post #43

Earlier quoted context omitted.

People forget that AOT can only get you so far. JIT not only has all the info the AOT mechanism has, but also has real runtime fact based data, and can do wonders with it.

For the sake of argument: What is an example of an optimization that a JIT compiler can make that a AOT compiler cannot? If the developer is able to profile the application on typical end-user workloads, don't profile-guided optimizations provide the same benefit as JIT runtime profiling? Why can't an AOT compiler just consider every path a "hot" path? Last but not least: Got any benchmarks?

Wouldn't you get a code explosion and difficulties dealing with cache coherency if every path was a hot path (serious question, I don't know much about this stuff)?

Re: C++ at Google: Here Be Dragons

#58

Post by ch0wn »

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.

Clang has support for a lot of gcc extensions: http://clang.llvm.org/docs/LanguageExtensions.html

Re: C++ at Google: Here Be Dragons

#59

Post by jonhohle »

DanielRibeiro wrote: post #47
chancho wrote: post #45

Earlier quoted context omitted.

For the sake of argument: What is an example of an optimization that a JIT compiler can make that a AOT compiler cannot? If the developer is able to profile the application on typical end-user workloads, don't profile-guided optimizations provide the same benefit as JIT runtime profiling? Why can't an AOT compiler just consider every path a "hot" path? Last but not least: Got any benchmarks?

For one: JIT can do polymorphic inline caching (you can read more about from Google's senior vice president of operations Urs Hölzle[1]), while AOT can't. Wikipedia gives a few more[2]: runtime profile-guided optimizations and pseudo-constant propagation [1] http://research.google.com/pubs/author79.html [2] http://en.wikipedia.org/wiki/AOT_compiler

The Polymorphic Inline Caching paper refers to AOT compiling with runtime hints.

In the case of non-dynamic languages like C and C++ that clang generally targets, are there other examples of where JIT would make things possible that are not possible in AOT?

Re: C++ at Google: Here Be Dragons

#60

Post by stephen_g »

SwellJoe wrote: post #42

I haven't worked in C (or C++) heavily in about 6 years, since I shut down my prior company and stopped working on Squid or having to look at kernel code. But, these errors are simply beautiful, and make me have vague longings to work on C projects again (I'm sure I'll get over those longings soon). These are the kinds of mistakes I made all the time when working in C, and the kind of thing that made coding extremely…

"Having this capability in the compiler is pretty cool and brings C/C++ a small step closer to working in higher level languages"

C++0x is another (much bigger, in my opinion) step that makes C++ a lot easier to program. It's not quite as easy as higher level languages, but far closer than before, and the performance gains over most other languages make it worth using.

Post reply on HN