Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: bart <bc@freeuk.com>
Newsgroups: comp.lang.c
Subject: Re: Baby X is bor nagain
Date: Sat, 29 Jun 2024 12:11:52 +0100
Organization: A noiseless patient Spider
Lines: 96
Message-ID: <v5oq5o$3srp8$1@dont-email.me>
References: <v494f9$von8$1@dont-email.me> <v53i4s$33k73$2@dont-email.me>
 <v53lf7$34huc$1@dont-email.me> <v53vh6$368vf$1@dont-email.me>
 <v54se1$3bqsk$1@dont-email.me> <20240624160941.0000646a@yahoo.com>
 <v5bu5r$va3a$1@dont-email.me> <20240624181006.00003b94@yahoo.com>
 <v5c86d$11ac7$1@dont-email.me> <JEheO.108086$ED9b.74955@fx11.iad>
 <v5cblg$11q0j$1@dont-email.me> <gEieO.108089$ED9b.25598@fx11.iad>
 <20240625113616.000075e0@yahoo.com> <mUzeO.141609$Cqra.55051@fx10.iad>
 <v5elql$1jmii$1@dont-email.me> <m3BeO.24907$Gurd.16179@fx34.iad>
 <v5empd$1jndv$2@dont-email.me> <v5eph4$1k6a9$1@dont-email.me>
 <87ed8jnbmf.fsf@bsb.me.uk> <v5jhls$2m7np$1@dont-email.me>
 <v5jm32$2nqvp$1@dont-email.me> <v5k3v2$2qllm$1@dont-email.me>
 <v5kfst$2svt3$1@dont-email.me> <v5kmlm$2u918$1@dont-email.me>
 <20240627201830.854@kylheku.com> <v5m2nl$39qob$3@dont-email.me>
 <v5ohno$3rjfp$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sat, 29 Jun 2024 13:11:53 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="8999aade17fef69a77001a25d1c0d2c5";
	logging-data="4091688"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19KJ6YJXHyM9re3f3rPk5rJ"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:8bxJPWmlRtyItTE9MEovd8fZhfs=
In-Reply-To: <v5ohno$3rjfp$1@dont-email.me>
Content-Language: en-GB
Bytes: 6060

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.