Re: Baby X is bor nagain

On 29/06/2024 09:47, David Brown wrote:

On 28/06/2024 12:19, bart wrote:

On 28/06/2024 04:23, Kaz Kylheku wrote:

On 2024-06-27, bart <bc@freeuk.com> wrote:

And for most of /my/ compiles, the code produced by gcc-O0 is fast
enough. It also about the same speed as code produced by one of my
compilers.
>
So I tend to use it when I want the extra speed, or other compilers
don't work, or when a particular app only builds with that compiler.
>
Otherwise the extra overheads are not worth the bother.

>
How good are your diagnostics compared to GCC -O2, plus -Wall and -W?

>
>
>
Using products like tcc doesn't mean never using gcc. (Especially on Linux where you will have it installed anyway.)

 >

You can use the latter to do extra, periodic checks that the simpler compiler may have missed, or to produce faster production builds.
>
But gcc is not needed for routine compilation.
>
>

 It is certainly a reasonable idea to use gcc as a linter if your normal compile is poor at static checking.  I've done that myself in the past - in embedded development, you don't always get to choose a good compiler.   These days I'd be more likely to go for clang-tidy as a linter, and there's other more advanced tools available (especially if you have the money).
 However, I don't see the point in doing any kind of compilation at all, until you have at least basic linting and static error checking in place.  If I've used the value of a variable without initialising it, I have no interest in running the program until that is fixed.

You run the program, and if it doesn't work or has some bug that you can't figure out, then you can pass it through a bigger compiler to get its opinion.
If the program works, then you can still do that to pick up things you've missed, in case the program worked by luck. But this doesn't need to be done every time.
I wonder, how do you work with Python. Presumably there you're used to making frequent small tweaks (maybe lining up some output) and running it immediately to check it's OK.
If there was some elaborate checker for Python code, or you had an extensive test suite that executed all lines of the program to check you hadn't mispelled anything, I expect you wouldn't to run those after every minor edit.
You use Python /because/ it's quick and informal.

  And if I don't want to run the program, I've no interest in compiling it.
 So I simply can't comprehend why you'd want fast but pointless compiles regularly, then only occasionally check to see if the code is actually correct - or at least, does not contain detectable errors

For similar reasons that drivers don't stop to check their tyre pressures every mile. Or why MOTs (inspections) are only mandated once a
year.

Now, if you were using one of these "big" linters that does simulations of your code and takes hours to run on a server machine before posting back a report, that's a different matter.  Tools like that run overnight or in batches, integrating with version control systems, automatic test setups, and so on.  But that's not what we are talking about.
 Say tcc takes 0.2 seconds to compile your code, and "gcc -O2 -Wall" takes 3 seconds.  If gcc catches an error that you missed, that's probably going to save you between half and hour and several days finding the problem by trial-and-error debugging.

Take any kind of interactive work done on a computer - editing a source file, doing creative writing, writing a reply on a forum, all sorts of stuff you expect to work smoothly.
Now imagine that every so often it freezes for several seconds. (This is exactly what used to happen on Thunderbird last year. It's what happens now on one of my smart TV apps, there can be several seconds latency after pressing a button on the remote.)
It would be incredibly annoying. It would break your concentration. It would make some things impractical (I don't use the smart TV app; I browse on my PC instead.)
That is what gcc is like to me. There is no fluency. YMMV.