Hacker News Reader

Comment by viraptor | Hacker News Reader

I'm not sure this screenshot is convincing. Do you see the last error message?

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.

View on HN

"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 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.

I agree, but it might be helpful if it put something in saying that it had made that assumption. For example they could say

[...] 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.

I usually try to fix as many errors as I can identify before recompiling. And yes, I usually fix from the bottom up, because that way my changes don't alter the line numbers of future fixes. On large projects, recompile time can be significant.

Yes, sure, large projects can take time to compile, but doesn't your compile environment just try to recompile the last file that it failed on during the build? That is, if in trying to build my app FooBar, and foo.c compiles ok but bar.c fails, when I try to run the build the next time having modified bar.c, it starts by trying to compile bar.c anyway... So I guess what I'm trying to say is that I don't understand the advantage you are apparently getting by woring from bottom up.

I don't want to get into the specifics of the build system since it's proprietary, but there's a non-trivial startup cost for it. It's optimized for being able to compile really huge projects in a tractable amount of time, not being able to recompile individual files in the shortest possible amount of time. The latter will execute quickly enough (yes, it only recompiles what you've changed), but the startup time is still annoying enough to want to batch up edits.

I think you need to upgrade you editor. For instance both vim & emacs are smart enough to adjust for inserts and removals.

I use vim. How do I get it to adjust for edits?

Use the :make command so that vim knows about the errors. Then use :clist to list errors, :cnext to go to the next error, etc. :help clist and :help make will get you started.

If you are using :make, and _don't_ jump out of the file (split the window if you need to jump out), line deletions and additions down the window are automatically accounted for.

As for turning it on or off, I've never had too, unless it's part of cindent.

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 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).

How long is recompiling really going to be if it's one file, though? I'm not talking about C++, which clang isn't quite fluent in yet, but one file of pure C shouldn't take long to compile. Or have I not been compiling the right C files?

Let's say you edit point.h, and many files include it. Then these files must be compiled too, and the files that include them, etc. until eventually you compile nearly the whole application.

I've been bitten by the dependencies in C++ before. I have this file "image.h" which contains a templated image class with quite a few algorithms. My app is about image processing, so nearly everything uses the image datatype. I hate having to edit this file because it means recompiling nearly everything. Of course templates make it much worse than pure C...

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".

I think the standard requires that.

the struct point holds a def for the correct spelling so I would guess that they are using known good variables and suggests the one that is closest to it.

Reply on news.ycombinator.com