Re: Baby X is bor nagain

On 29/06/2024 13:11, bart wrote:

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.
 

Don't be silly.  Testing can only show the presence of bugs, not their absence.  It is not an alternative to automatic checks.

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.
 

It's a very different style of language from C, and I use it for very different purposes, so my development process is different.  It is very common in Python development to have unit tests that you can run for automatic testing.  (It's common in C and C++ programming too, but it can be hard to do that for hardware-specific embedded code.)  There are also linters and checkers for Python, editors and IDEs that help you avoid some mistakes, type annotation, and other tools.  You can't do nearly as much pre-run checking as you can in static languages, but you do what you can.  Of course, for small programs or parts of programs, quick tests are all you need - not all code needs extensive tests.

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.
 

No, not after every edit.  But then, I don't compile my C code after every edit.  It depends on the size and type of the edit.  Some checks - such as for misspelling - /are/ done continuously during editing, at least to some extent.  A decent IDE or editor will help there.

You use Python /because/ it's quick and informal.
 

I use Python for tasks where it is a lot faster to develop in Python than C or C++, easier to get right, and where it has the libraries and modules that I need.  I would not say it is "informal", I would say it is flexible.

 

  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.
 

Every modern car has automatic checks for tyre pressure every mile or so.  I don't want to spend time every build /manually/ re-checking through piles of code looking for errors, but I am quite happy to let my computer and compiler do it.

 

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

I agree.  So I don't use a setup like that.

That is what gcc is like to me. There is no fluency. YMMV.

It is possible to have your cake and eat it.  You think this is all a binary choice - it is not.  You can have smooth and fluent development /and/ powerful checking /and/ efficient generated code /and/ full-featured tools.