As a dynamic language guy, I can't help but look at the static analysis here and feel a twinge of jealousy. There really isn't anything like this in the Ruby world. Some stuff is starting to emerge, but we're still largely dependent on tests to catch stupid mistakes. When I'm chasing down a bug, it would be nice to have a variety of tools to throw at the problem.
How to convince any C developer to dump gcc and use clang
41–50 of 97 posts
Re: How to convince any C developer to dump gcc and use clang
#42Re: How to convince any C developer to dump gcc and use clang
#43you're saying I should port all my code just because the ui is more user-friendly? what about performance, options, special warnings, builtins, and everything else? I've been using gcc for a while now, and every time I use it I found a new feature. It's rock solid and had never let me down.
Those better warnings aren't just due to a simple UI patch ... clang is doing better and deeper static analysis than gcc in order to even be able to produce those more intelligent warnings.
Re: How to convince any C developer to dump gcc and use clang
#44I am currently switching between gcc and clang for my codebase. The performance is mixed. For some programs (2-level hashtable, for example), the clang version got about 50% speed up against gcc and icc. But other programs (sobel filter for example), clang version slows down about 25% (against gcc 4.4). The result certainly machine specific, but I think clang can do better in a long run.
a quick search yields http://clang.llvm.org/performance.html (favourable, but somewhat skewed results). http://forums.cocoaforge.com/viewtopic.php?f=10&t=21016 indicates improved compile times, but it's purely anecdotal.
That said, does anyone else have any experience moving a performance-centric or cross platform project to clang?
Re: How to convince any C developer to dump gcc and use clang
#45I'm excited about clang but it's not that important: gcc is good enough. I'll just wait until I can install it from Ubuntu repositories, and then I'll happily try out and hopefully switch over to clang.
Re: How to convince any C developer to dump gcc and use clang
#46Earlier quoted context omitted.
It's quite common and accepted for compilers to make assumptions about the rest of the code, and for those to be wrong if your code is broken. For example, the C# compiler has a large number of passes, and it will do no more passes after seeing an a previous pass. Thus, you might knock a file down to one error, fix that error, and then find that you have a couple dozen more errors.
> It's quite common and accepted for compilers to make assumptions about the rest of the code, and for those to be wrong if your code is broken. Indeed. Most annoyingly, many "modern" C compilers still attempt to muddle onward by replacing unknown types with "int".
Re: How to convince any C developer to dump gcc and use clang
#47As a dynamic language guy, I can't help but look at the static analysis here and feel a twinge of jealousy. There really isn't anything like this in the Ruby world. Some stuff is starting to emerge, but we're still largely dependent on tests to catch stupid mistakes. When I'm chasing down a bug, it would be nice to have a variety of tools to throw at the problem.
I spend most of my time writing C code, but like to work with Python when I get the chance. There isn't anything like pylint for Ruby? A dynamic runtime doesn't necessarily mean you have to give up static analysis.
Re: How to convince any C developer to dump gcc and use clang
#48you're saying I should port all my code just because the ui is more user-friendly? what about performance, options, special warnings, builtins, and everything else? I've been using gcc for a while now, and every time I use it I found a new feature. It's rock solid and had never let me down.
just because the ui is more user-friendly? Those better warnings aren't just due to a simple UI patch ... clang is doing better and deeper static analysis than gcc in order to even be able to produce those more intelligent warnings.
Re: How to convince any C developer to dump gcc and use clang
#49Earlier quoted context omitted.
"What would happen if the programmer got a list of error and started fixing from the end?" I always fix the first 1 or 2 reported errors and try to recompile. I assume everyone did. A traditional "report on errors which are actually there each time they happen" compiler will give you tons of completely spurious errors which happily disappear once you fix the first few. In the instance you point out, it could just use…
One point was mentioned - recompiling time may be huge. On the other hand - if the recompile time is tiny, I don't bother with any specific order, I just fix what I see as trivial first. But when you see the clang's very verbose errors - how many can you fit on the screen? 10? 15? To make sure none of the last ones depend on some code guessing, you'd have to scroll to the top every time, instead of just fixing what y…
Re: How to convince any C developer to dump gcc and use clang
#50I am currently switching between gcc and clang for my codebase. The performance is mixed. For some programs (2-level hashtable, for example), the clang version got about 50% speed up against gcc and icc. But other programs (sobel filter for example), clang version slows down about 25% (against gcc 4.4). The result certainly machine specific, but I think clang can do better in a long run.
Although cryptic, I'd say that gcc's error messages are manageable. I'd hold other factors, such as performance of compiled code - across platforms - to be more important. Alternatively, they could improve on the C++ template error reporting (when they get around to taking C++ support beyond alpha) and that may be enough to sell me. a quick search yields http://clang.llvm.org/performance.html (favourable, but somewha…