Path: csiph.com!weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Gabriel Rolland Newsgroups: comp.lang.c Subject: Re: Effect of CPP tags Date: Mon, 15 Jan 2024 17:40:25 +0100 Organization: A noiseless patient Spider Lines: 114 Message-ID: <87h6jev9c6.fsf@gmail.com> References: <20240112134536.695@kylheku.com> <87zfxakqjd.fsf@nosuchdomain.example.com> <20240112200241.728@kylheku.com> <87o7dolxkj.fsf@nosuchdomain.example.com> <87jzoclss6.fsf@nosuchdomain.example.com> <86h6jfls0e.fsf@linuxsc.com> <87o7dndln6.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain Injection-Info: dont-email.me; posting-host="e357d719e710cc470fa99bb526177c64"; logging-data="1061454"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18Ca+f33qlc5GorBX7rEygkGgLue4YGdCRrHX1Fr4Obvg==" User-Agent: Gnus/5.13 (Gnus v5.13) Cancel-Lock: sha1:IuuRIQiBh4Y07pKzw3zDiEl7W8w= sha1:2veCS00wgVvjFaoJis9iMftWXbM= Xref: csiph.com comp.lang.c:380191 bart writes: > On 15/01/2024 08:51, Gabriel Rolland wrote: >> bart writes: > >> If I recall the ongoing thread, there was two "indefendable" statements: > > OK, whatever the actual spelling of 'indefendable' might be... > Oh no, that was not about the spelling of the word. It was about semantics. I think they can be quite defended, and everybody here has proved it. >> a) make is useless and cryptic > > My 'C and Make' thread showed a clear example of it being used > gratuitously. I contend that that happens a lot. > >> b) gcc's outputing of binaries to a.out by default is useless and >> cryptic >> Since *a* has been explained already. I'll just give my two cents on >> *b*. >> When I'm learning to program, I use to have a lot of source files in the >> same repository. I don't want't the binaries, I just want to play with >> the source and sometimes, compile them and see if they compile correctly >> and the behavior is correct. Outputting the binary to a.out by default >> instead of "hello.o" is sort of useful here. For two reasons : >> 1. I don't have the overhaul of remembering how did I call that source >> file in that particular moment when I wrote it. I know I have to call >> ./a.out > > Hang on: are you generating 'a.out' the object file, or 'a.out' the > executable file? (Because ./a.out will execute the file.) This has been answered better than I could by David Brown. > Here is where Unix/Linux's treatment of file extensions does my head > in. 'a.out' is used there for both kinds of file. To find out what it > actually is, you have to look inside the file, which defeats the > purpose of having a file extension at all. The executable. Unix treatment of file extension is non existent, true. So I don't bother with file extensions much. But I have yet to go on comp.os.windows to explain how confusing file extensions are. >> and that's it. >> 2. It doesn't crowds my directory with lots of useless binaries. > > The problems of always having the same a.exe/a.out output (here it is > the executable file - see, I have to keep disambiguating!) are > multiple: > > * If you working with several small one-file programs c, d, and e say, > you want them compiled as c.exe, d.exe and e.exe. Having them all be > a.exe is not going to work; which of c, d, e does it correspond to? > Suppose you want to run c, d, e one after the other? > > * You might be testing (as I do), multiple compilers on the same > c.c. The first produces c.exe; you test it. Compile with the second > to make a new c.exe; you test that. Compile with gcc to make a new > ... a.exe. Now you have to remember it's a different executable. > That is not about the use case my two cents were about. Why bring up cross compilation to the table ? I think it is another problem and it is the reason why your answer is longer than you intended. > (The number of times I've forgotten that and run c.exe instead, and > thought gcc's code wasn't quite as fast as I'd expected...). > > * You compile a big program one.c which takes a long time. You then > compiled another program two.c, which you now realise has > overwritten the a.exe that represented one.c. > > The answer isn't to use '-o c.exe' either. In both cases gcc is out of > kilter with the other compilers; it will eiher produce the wrong EXE, > or you need extra options that the others don't. > > > OK, I replied at more length than I intended. I really feel these > small matters in such tools are important. Others gloss over them: > > * "You never run gcc directly; use make!" > > * "Write a wrapper script or program around gcc" > > * "You spent more time complaining about it then you'd have spent just > typing '-oprog.exe!" > > And so on. The trouble is if you post, on a forum, some C code with a > brief note of how it should be built, you can't assume somebody has > the same wrapper, and you don't want to also post a make script, but > you have to add these stupid extra options each time. > > I could suggest for example that, if 'gcc prog.c' always generated > 'prog', that you instead used: > > gcc prog.c -oa.out > > if you don't want the proliferation of binaries. But I guess you > wouldn't want that extra hassle. This is a supposition on your part. If gcc/cc was working as you said, like outputting of hello.c hello.exe by default. In that case I would maybe have considered something like aliasing gcc thus : alias cc='gcc -o current.exe' So I wouldn't have that extra hassle. But that would belong to my '.profile' opinions and everybody can have his own '.profile' opinion about how gcc should work. I respect that.