What this feature needs now is code correction on the fly. Any error reporter smart enough to ask "did you mean 'x'?" should allow me to answer "yes", and write the changes to the file. That would sell clang to a lot of people.
integration with an IDE or vim/emacs + incremental compilation ==> smart error messages and corrections 'on the fly' while you're typing! sort of like how Eclipse gives you sqiggly line warnings almost instantaneously after you finish coding a line
file.cpp:65: error: please have a look at this line and see if anything jumps out at you.
If you have to use someone else's macros you can use a wrapper function with exactly the same effects.
Also avoid #define constants not related to compilation or pre-processing themselves.
Readable code > unreadabe code. Same counts for compiled binaries.
-E Stop after the preprocessing stage; do not run the compiler proper.
The output is in the form of preprocessed source code, which is
sent to the standard output.
Input files which don't require preprocessing are ignored.
In the second error message clang found that `horisontal` doesn't exist and suggested `horizontal`. That's fair enough. The last error message actually assumes the code said `horizontal`, which is just horribly wrong. I think that the compiler should never ever report an error on code that is not really there. What would happen if the programmer got a list of error and started fixing from the end? What if the guessed name was wrong? The programmer would spend time chasing some bug which doesn't exist outside of compiler's "that's what you probably meant" version of code.
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 uselessly say "no member named horisontal" but it knows it already gave you that error. So instead of repeating itself or shutting up, it reasons in the alternative--even if the name was corrected, the type is wrong. I would actually find that far more useful for fixing all the compiler errors at once.
[...] has type 'double' (assuming argument horizontal was intended)
With you on the reported errors and trying to recompile; more helpful error messages later in the build would remove some of those compile-fix-compile cycles.
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 you see.
I'm still not a fan of guessing - badly reported error is still better than properly reported error on a nonexisting code (potentially incorrectly guessed).
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.
Indeed. Most annoyingly, many "modern" C compilers still attempt to muddle onward by replacing unknown types with "int".
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.
Or do you use a lot of gcc extensions?
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.
My point is Clang is good but friendly error messages is not the only reason I would change to Clang.
First we need full C++ coverage in clang. Onward!
Orders of magnitute more than just for the error messages.
Obviously, clang does not mean to attract C++ developers. For a while, I'd been adamant about developing in C and not C++. One day I discovered that I'd hand-coded a vtable in order to allow polymorphism in structures of function pointers. The next day, I halved the project complexity by writing 3 classes and changing a flag in the make configuration.
I use Gnu make through the Eclipse CDT on Ubuntu. It's a clunky and ugly toolchain/IDE combo that took days to configure. It compiles C, C++, CUDA and Brook+ in the same project across 3 different computers. A better C frontend would be nice, but I do not look forward to getting that working with everyone else in this chain.
I've found myself in a similar situation. I am writing embedded software which needs to be as portable as possible, but I've found myself starting to implement polymorphism and objects in C. I am tempted to ignore platforms that lack a C compiler and switch to C++, but the reduced predictability of runtimes has kept me from doing so thus far.
I had a 2x speedup a few years ago on math-heavy code (FFTs) by switching from gcc 4.2 to gcc 3.4 -- apparently there was a known issue in gcc's optimizer where it would flag too many values as "keep this in a register" and end up spending lots of time moving data to and from the "register overflow space" on the stack. (I don't know if this has been fixed -- as I said, it was a few years ago that I ran into this issue.)
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?
Meanwhile, I got seduced by gcc's nested functions which are not supported by clang. Apparently they are non-trivial in clang so won't appear soon if at all.
Two incompatible mechanisms for function decomposition are annoying.
("blocks" does a lot more, but for the afflicted project I don't need that. Just nested functions would be spiffy, it saves the plethora of arguments being passed to each function if you keep them at file scope.)
GCC is not perfect, but works well enough, is stable enough, that to switch without a strong argument is going to be a slow process at best.
>> often beats every other C compiler out there
I'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.