Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #381780 > unrolled thread
| Started by | bart <bc@freeuk.com> |
|---|---|
| First post | 2024-02-05 01:09 +0000 |
| Last post | 2024-02-05 23:29 +0000 |
| Articles | 20 on this page of 133 — 16 participants |
Back to article view | Back to comp.lang.c
What I've learned in comp.lang.c bart <bc@freeuk.com> - 2024-02-05 01:09 +0000
Re: What I've learned in comp.lang.c Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-05 05:58 +0000
Re: What I've learned in comp.lang.c "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-02-04 22:49 -0800
Re: What I've learned in comp.lang.c Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-05 07:03 +0000
Re: What I've learned in comp.lang.c "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-02-04 23:51 -0800
Re: What I've learned in comp.lang.c "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-02-04 23:52 -0800
Re: What I've learned in comp.lang.c Jan van den Broek <balglaas@dds.nl> - 2024-02-05 08:36 +0000
Re: What I've learned in comp.lang.c Michael S <already5chosen@yahoo.com> - 2024-02-05 18:23 +0200
Re: What I've learned in comp.lang.c Michael S <already5chosen@yahoo.com> - 2024-02-05 18:32 +0200
Re: What I've learned in comp.lang.c David Brown <david.brown@hesbynett.no> - 2024-02-05 20:53 +0100
Re: What I've learned in comp.lang.c Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-05 20:53 +0000
Re: What I've learned in comp.lang.c David Brown <david.brown@hesbynett.no> - 2024-02-06 09:44 +0100
Re: What I've learned in comp.lang.c "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-02-06 01:03 -0800
Re: What I've learned in comp.lang.c Michael S <already5chosen@yahoo.com> - 2024-02-06 13:41 +0200
Re: What I've learned in comp.lang.c David Brown <david.brown@hesbynett.no> - 2024-02-06 13:08 +0100
Re: What I've learned in comp.lang.c Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-06 23:23 +0000
Re: What I've learned in comp.lang.c David Brown <david.brown@hesbynett.no> - 2024-02-07 08:54 +0100
Re: What I've learned in comp.lang.c Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-07 08:59 +0000
Re: What I've learned in comp.lang.c Ben Bacarisse <ben.usenet@bsb.me.uk> - 2024-02-07 10:47 +0000
Re: What I've learned in comp.lang.c bart <bc@freeuk.com> - 2024-02-07 11:04 +0000
Re: What I've learned in comp.lang.c David Brown <david.brown@hesbynett.no> - 2024-02-07 14:21 +0100
Re: What I've learned in comp.lang.c bart <bc@freeuk.com> - 2024-02-07 14:24 +0000
Re: What I've learned in comp.lang.c David Brown <david.brown@hesbynett.no> - 2024-02-07 21:30 +0100
Re: What I've learned in comp.lang.c Ben Bacarisse <ben.usenet@bsb.me.uk> - 2024-02-07 15:36 +0000
Re: What I've learned in comp.lang.c bart <bc@freeuk.com> - 2024-02-07 18:05 +0000
Re: What I've learned in comp.lang.c scott@slp53.sl.home (Scott Lurndal) - 2024-02-07 18:26 +0000
Re: What I've learned in comp.lang.c bart <bc@freeuk.com> - 2024-02-07 19:53 +0000
Re: What I've learned in comp.lang.c Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-07 21:38 +0000
Re: What I've learned in comp.lang.c Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-08 00:29 +0000
Re: What I've learned in comp.lang.c David Brown <david.brown@hesbynett.no> - 2024-02-07 21:37 +0100
Re: What I've learned in comp.lang.c bart <bc@freeuk.com> - 2024-02-07 22:52 +0000
Re: What I've learned in comp.lang.c Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-08 01:13 +0000
Re: What I've learned in comp.lang.c bart <bc@freeuk.com> - 2024-02-08 02:09 +0000
Re: What I've learned in comp.lang.c Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-08 03:07 +0000
Re: What I've learned in comp.lang.c bart <bc@freeuk.com> - 2024-02-08 14:17 +0000
Re: What I've learned in comp.lang.c Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-02-08 16:02 -0800
Re: What I've learned in comp.lang.c bart <bc@freeuk.com> - 2024-02-09 00:48 +0000
Re: What I've learned in comp.lang.c David Brown <david.brown@hesbynett.no> - 2024-02-09 08:53 +0100
Re: What I've learned in comp.lang.c Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-02-10 21:55 -0800
Re: What I've learned in comp.lang.c David Brown <david.brown@hesbynett.no> - 2024-02-08 13:01 +0100
Re: What I've learned in comp.lang.c Ben Bacarisse <ben.usenet@bsb.me.uk> - 2024-02-08 11:37 +0000
Re: What I've learned in comp.lang.c Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-08 12:10 +0000
Re: What I've learned in comp.lang.c David Brown <david.brown@hesbynett.no> - 2024-02-08 13:24 +0100
Re: What I've learned in comp.lang.c Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-08 13:03 +0000
Re: What I've learned in comp.lang.c bart <bc@freeuk.com> - 2024-02-08 13:17 +0000
Re: What I've learned in comp.lang.c David Brown <david.brown@hesbynett.no> - 2024-02-08 16:52 +0100
Re: What I've learned in comp.lang.c Ben Bacarisse <ben.usenet@bsb.me.uk> - 2024-02-08 17:17 +0000
Re: What I've learned in comp.lang.c Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-02-09 14:50 -0800
Re: What I've learned in comp.lang.c Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-07 12:44 +0000
Re: What I've learned in comp.lang.c David Brown <david.brown@hesbynett.no> - 2024-02-07 14:49 +0100
Re: What I've learned in comp.lang.c Ben Bacarisse <ben.usenet@bsb.me.uk> - 2024-02-07 16:13 +0000
Re: What I've learned in comp.lang.c Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-07 08:21 -0800
Re: What I've learned in comp.lang.c David Brown <david.brown@hesbynett.no> - 2024-02-07 14:01 +0100
Re: What I've learned in comp.lang.c Richard Harnden <richard.nospam@gmail.invalid> - 2024-02-07 13:21 +0000
Re: What I've learned in comp.lang.c Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-07 13:42 +0000
Re: What I've learned in comp.lang.c David Brown <david.brown@hesbynett.no> - 2024-02-07 16:17 +0100
Re: What I've learned in comp.lang.c Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-07 21:34 +0000
Re: What I've learned in comp.lang.c scott@slp53.sl.home (Scott Lurndal) - 2024-02-07 16:21 +0000
Re: What I've learned in comp.lang.c Michael S <already5chosen@yahoo.com> - 2024-02-08 13:26 +0200
Re: What I've learned in comp.lang.c Ben Bacarisse <ben.usenet@bsb.me.uk> - 2024-02-07 10:04 +0000
Re: What I've learned in comp.lang.c David Brown <david.brown@hesbynett.no> - 2024-02-07 14:51 +0100
Re: What I've learned in comp.lang.c Ben Bacarisse <ben.usenet@bsb.me.uk> - 2024-02-07 15:30 +0000
Re: What I've learned in comp.lang.c Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-07 15:45 +0000
Re: What I've learned in comp.lang.c David Brown <david.brown@hesbynett.no> - 2024-02-07 21:44 +0100
Re: What I've learned in comp.lang.c Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-08 00:33 +0000
Re: What I've learned in comp.lang.c Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-08 01:30 +0000
Re: What I've learned in comp.lang.c Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-08 01:38 +0000
Re: What I've learned in comp.lang.c Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-08 02:21 +0000
Re: What I've learned in comp.lang.c Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-08 03:07 +0000
Re: What I've learned in comp.lang.c Ben Bacarisse <ben.usenet@bsb.me.uk> - 2024-02-08 11:45 +0000
Re: What I've learned in comp.lang.c Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-08 12:15 +0000
Re: What I've learned in comp.lang.c David Brown <david.brown@hesbynett.no> - 2024-02-08 13:29 +0100
Re: What I've learned in comp.lang.c Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-08 12:55 +0000
Re: What I've learned in comp.lang.c David Brown <david.brown@hesbynett.no> - 2024-02-09 09:02 +0100
Re: What I've learned in comp.lang.c scott@slp53.sl.home (Scott Lurndal) - 2024-02-08 16:09 +0000
Re: What I've learned in comp.lang.c Richard Harnden <richard.nospam@gmail.invalid> - 2024-02-08 16:28 +0000
Re: What I've learned in comp.lang.c Ben Bacarisse <ben.usenet@bsb.me.uk> - 2024-02-08 17:13 +0000
Re: What I've learned in comp.lang.c Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-02-08 17:53 -0800
Re: What I've learned in comp.lang.c Michael S <already5chosen@yahoo.com> - 2024-02-05 19:02 +0200
Re: What I've learned in comp.lang.c Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-05 23:28 +0000
Re: What I've learned in comp.lang.c Richard Harnden <richard.nospam@gmail.invalid> - 2024-02-05 23:40 +0000
Re: What I've learned in comp.lang.c Michael S <already5chosen@yahoo.com> - 2024-02-06 01:46 +0200
Re: What I've learned in comp.lang.c David Brown <david.brown@hesbynett.no> - 2024-02-06 09:54 +0100
Re: What I've learned in comp.lang.c "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-02-05 16:03 -0800
Re: What I've learned in comp.lang.c "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-02-05 16:06 -0800
Re: What I've learned in comp.lang.c David Brown <david.brown@hesbynett.no> - 2024-02-06 09:50 +0100
Re: What I've learned in comp.lang.c "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-02-06 01:01 -0800
Re: What I've learned in comp.lang.c Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-06 23:24 +0000
Re: What I've learned in comp.lang.c David Brown <david.brown@hesbynett.no> - 2024-02-07 08:56 +0100
Re: What I've learned in comp.lang.c Michael S <already5chosen@yahoo.com> - 2024-02-07 12:09 +0200
Re: What I've learned in comp.lang.c David Brown <david.brown@hesbynett.no> - 2024-02-07 15:03 +0100
Re: What I've learned in comp.lang.c scott@slp53.sl.home (Scott Lurndal) - 2024-02-07 16:25 +0000
Re: What I've learned in comp.lang.c David Brown <david.brown@hesbynett.no> - 2024-02-07 21:49 +0100
Re: What I've learned in comp.lang.c "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-02-07 13:04 -0800
Re: What I've learned in comp.lang.c Michael S <already5chosen@yahoo.com> - 2024-02-07 23:37 +0200
Re: What I've learned in comp.lang.c David Brown <david.brown@hesbynett.no> - 2024-02-08 08:52 +0100
Re: What I've learned in comp.lang.c Michael S <already5chosen@yahoo.com> - 2024-02-09 15:55 +0200
Re: What I've learned in comp.lang.c David Brown <david.brown@hesbynett.no> - 2024-02-09 15:29 +0100
Re: What I've learned in comp.lang.c Michael S <already5chosen@yahoo.com> - 2024-02-09 16:52 +0200
Re: What I've learned in comp.lang.c David Brown <david.brown@hesbynett.no> - 2024-02-09 17:22 +0100
Re: What I've learned in comp.lang.c Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-10 07:18 +0000
Re: What I've learned in comp.lang.c David Brown <david.brown@hesbynett.no> - 2024-02-10 17:11 +0100
Re: What I've learned in comp.lang.c Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-10 21:23 +0000
Re: What I've learned in comp.lang.c David Brown <david.brown@hesbynett.no> - 2024-02-11 14:01 +0100
Re: What I've learned in comp.lang.c Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-07 21:41 +0000
Re: What I've learned in comp.lang.c bart <bc@freeuk.com> - 2024-02-07 02:18 +0000
Re: What I've learned in comp.lang.c David Brown <david.brown@hesbynett.no> - 2024-02-07 09:30 +0100
Re: What I've learned in comp.lang.c Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-07 09:04 +0000
Re: What I've learned in comp.lang.c Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-07 23:24 +0000
Re: What I've learned in comp.lang.c bart <bc@freeuk.com> - 2024-02-08 01:46 +0000
Re: What I've learned in comp.lang.c Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-08 02:50 +0000
Re: What I've learned in comp.lang.c bart <bc@freeuk.com> - 2024-02-08 11:08 +0000
Re: What I've learned in comp.lang.c Michael S <already5chosen@yahoo.com> - 2024-02-08 13:10 +0200
Re: What I've learned in comp.lang.c Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-08 17:48 +0000
Re: What I've learned in comp.lang.c Michael S <already5chosen@yahoo.com> - 2024-02-08 21:30 +0200
Re: What I've learned in comp.lang.c bart <bc@freeuk.com> - 2024-02-08 20:39 +0000
Re: What I've learned in comp.lang.c "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-02-08 13:39 -0800
Re: What I've learned in comp.lang.c Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-08 14:18 -0800
Re: What I've learned in comp.lang.c gazelle@shell.xmission.com (Kenny McCormack) - 2024-02-08 22:29 +0000
Re: What I've learned in comp.lang.c "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-02-08 14:43 -0800
Re: What I've learned in comp.lang.c David Brown <david.brown@hesbynett.no> - 2024-02-09 09:12 +0100
Re: What I've learned in comp.lang.c Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-02-04 23:36 -0800
Re: What I've learned in comp.lang.c scott@slp53.sl.home (Scott Lurndal) - 2024-02-05 14:52 +0000
Re: What I've learned in comp.lang.c gazelle@shell.xmission.com (Kenny McCormack) - 2024-02-05 22:58 +0000
Re: What I've learned in comp.lang.c Jim Jackson <jj@franjam.org.uk> - 2024-02-05 18:01 +0000
Re: What I've learned in comp.lang.c Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-05 08:29 +0000
Re: What I've learned in comp.lang.c bart <bc@freeuk.com> - 2024-02-07 01:35 +0000
Re: What I've learned in comp.lang.c Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-07 02:26 +0000
Re: What I've learned in comp.lang.c bart <bc@freeuk.com> - 2024-02-07 10:47 +0000
Re: What I've learned in comp.lang.c Dan Purgert <dan@djph.net> - 2024-02-05 11:03 +0000
Re: What I've learned in comp.lang.c David Brown <david.brown@hesbynett.no> - 2024-02-05 13:15 +0100
Re: What I've learned in comp.lang.c Ben Bacarisse <ben.usenet@bsb.me.uk> - 2024-02-05 14:09 +0000
Re: What I've learned in comp.lang.c Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-05 23:29 +0000
Page 1 of 7 [1] 2 3 4 5 6 7 Next page →
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2024-02-05 01:09 +0000 |
| Subject | What I've learned in comp.lang.c |
| Message-ID | <uppcfk$3ui34$1@dont-email.me> |
In no particular order. * Software development can ONLY be done on a Unix-related OS * It is impossible to develop any software, let alone C, on pure Windows * You can spend decades developing and implementing systems languages at the level of C, but you still apparently know nothing of the subject * You can spend a decade developing whole-program compilers and a suitably matched language, and somebody can still lecture you on exactly what a whole-language compiler is, because you've got it wrong * No matter how crazy the interface or behaviour of some Linux utility, no one is ever going to admit there's anything wrong with it * Every single tool I've written, is a toy. * Every single project I've worked on, is a toy (even if it made my company millions) * No one should post or link code here, unless it passes '-std=c99 -pedantic-errors' * Discussing build systems for C, is off-topic * Discussing my C compiler, is off-topic, but discussing gcc is fine * Nobody here apparently knows how to build a program consisting purely of C source files, using only a C compiler. * Simply enumerating the N files and submitting them to the compiler in any of several easy methods seems to be out of the question. Nobody has explained why. * Nearly everyone here is working on massively huge and complex projects, which all take from minutes to hours for a full build. * Hardly anybody here has a project which can be built simply by compiling and linking all the modules. Even Tim Rentsch's simplest project has a dizzying set of special requirements. * Funnily enough, every project I /have/ managed to build with my compilers after eventually getting through the complexity, /has/ reduced down to a simple list of .c files. * The Tiny C compiler, is a toy. Even though you'd have trouble telling, from the behaviour of a binary, whether or not it was built with tcc. * Actually, any C compiler that is not gcc, clang, or possibly MSVC, is a toy. Unless you have to buy it. * There's is nothing wrong with AT&T assembly syntax * There's especially nothing wrong with AT&T syntax written as a series of string literals, with extra % symbols, together with \n and \t escapes. * There is not a single feature of my alternate systems language that is superior to the C equivalent * There is not even a single feature that is worth discussing as a possible feature of C * There is nothing in my decades of implementing such languages (even implementing C), that makes my views on such possible features have any weight at all * Having fast compilation speed of C is of no use to anyone and impresses nobody. * Having code where you naughtily cast a function pointer to or from a function pointer is a no-no. No matter that the whole of C is widely regarded as unsafe. * Nobody here is interested in a simple build system for C. Not even my idea of a README simply listing the files needed, and any special steps, to accompany the usual makefiles. * There is no benefit at all in having a tool like a compiler, be a small, self-contained executable. * Generated C code is not real C code. * I should use makefiles myself for my own language, even though the build-process is always one, simple, indivisable command that usually completes in 1/10th of a second. * Makefiles should be for everything. * There's no problem in having to specify those pesky .c extensions to compiler input files, or adding that -o option * But it's too much work to specify a filename to 'make', or to even remember what your project is called * Linux /does/ use .c and .s extensions to distinguish between file contents * But Linux also uses a.out to mean both an executable and an object file. Huh. * C added a 'text' mode to to convert \n to/from CRLF when Windows came along. * Somebody who's only developed under Unix, and using a plethora of ready-made tools and utilities, is not in a bubble. * But somebody who's developed under a range of other environments spanning eras, is the one who's been in their own bubble. * I was crazy to write '1M' lines of code (I've no idea how much) in my private language * I am apparently ignorant, a moron and might even be a BOT. * I am allowed to have strong opinions, but I will always be wrong. Shall I post this pile of crap or not? I really need to get back to some of those pointless, worthless toy projects of mine. So here goes....
[toc] | [next] | [standalone]
| From | Kaz Kylheku <433-929-6894@kylheku.com> |
|---|---|
| Date | 2024-02-05 05:58 +0000 |
| Message-ID | <20240204191630.146@kylheku.com> |
| In reply to | #381780 |
On 2024-02-05, bart <bc@freeuk.com> wrote: > > In no particular order. > > * Software development can ONLY be done on a Unix-related OS > > * It is impossible to develop any software, let alone C, on pure Windows I've developed on DOS, Windows as well as for DSP chips and some microcontrollers. I find most of the crap that you say is simply wrong. Speaking of Windows, the CL.EXE compiler does not know where its include files are. You literally cannot do "cl program.c". You have to give it options which tell it where the SDK is installed: where the headers and libraries are. The Visual Studio project-file-driven build build system passes all those details to every invocation of CL.EXE. Your project file (called a "solution" nowadays) includes information like the path where your SDK is installed. In the GUI there is some panel where you specify it. If I'm going to be doing programming on Windows today, it's either going be some version of that CL.EXE compiler from Microsoft, or GCC. > * You can spend decades developing and implementing systems languages at > the level of C, but you still apparently know nothing of the subject There is forty years of experience and then there is 8 years, five times over again. > * You can spend a decade developing whole-program compilers and a > suitably matched language, and somebody can still lecture you on exactly > what a whole-language compiler is, because you've got it wrong Writing a compiler is pretty easy, because the bar can be set very low while still calling it a compiler. Whole-program compilers are easier because there are fewer requirements. You have only one kind of deliverable to produce: the executable. You don't have to deal with linkage and produce a linkable format. > * No matter how crazy the interface or behaviour of some Linux utility, > no one is ever going to admit there's anything wrong with it That is false; the stuff has a lot of critics, mostly from the inside now. (Linux outsiders are mostly a lunatic fringe nowadays. The tables have turned.) You don't seem to understand that the interfaces tools that are not directly invoked by people don't matter, as long as they are reliable. And then, interfaces that are exposed to user are hard to change, even if we don't like them, because changes break things. Everyone hates breaking changes more than they hate the particular syntax of a tool. The environment is infinitely customizeable. Users have their private environments which works they way they want. At the command line, you can use aliases and shell functions to give yourself the ideal commands you want. You only have to use the standard commands when writing scripts to be used by others. And even then, you can include functions which work the way you want, and then use your functions. > * Discussing my C compiler, is off-topic, but discussing gcc is fine GCC is maintained by people who know what a C compiler is, and GCC can be asked to be one. You've chosen not to read the C standard, which leaves you unqualified to even write test cases to validate that something is a C compiler. Your idea of writing a C compiler seems to be to pick some random examples of code believed to be C and make them work. (Where "work" means that they compile and show a few behaviors that look like the expected ones.) Basically, you don't present a very credible case that you've actually written a C compiler. > * Nobody here apparently knows how to build a program consisting purely > of C source files, using only a C compiler. > > * Simply enumerating the N files and submitting them to the compiler in > any of several easy methods seems to be out of the question. Nobody has > explained why. > > * Nearly everyone here is working on massively huge and complex > projects, which all take from minutes to hours for a full build. That's the landscape. Nobody is going to pay you for writing small utilities in C. That sort of thing all went to scripting languages. (It happens from time to time as a side task.) I currently work on a a firmware application that compiles to a 100 megabyte (stripped!) executable. > * There is not a single feature of my alternate systems language that is > superior to the C equivalent The worst curve ball someone could throw you would be to be eagerly interested in your language, and ask for guidance in how to get it installed and start working in it. Then you're screwed. As long as you just post to comp.lang.c, you're safe from that. > * Having fast compilation speed of C is of no use to anyone and > impresses nobody. Not as much as fast executable code, unfortunately. If it takes 10 extra seconds of compilation to shave off a 100 milliseconds off a program, it's worth if it millions of copies of that program are used. Most of GCC's run time is spent in optimizing. It's a lot faster with -O0. I just measured a 3.38X difference compiling a project with -O0 versus its usual -O2. This means it's spending over 70% of its time on optimizing. The remaining 30% is still kind of slow. But it's not due to scanning lots of header files. If I run it with the "-fsyntax-only" option so that it parses all the syntax, but doesn't produce output, it gets almost 4X faster (versus -O0, and thus about 13.5X faster compared to -O2). Mode: | -fsyntax-only | -O0 | -O2 | Time: | 1.0 | 4.0 | 13.5 | Thus, about 7.5% is spent on scanning, preprocessing and parsing. 22.2% is spent on the intermediate code processing and target generation activities, and 70.4 on optimization. Is it due to decades of legacy code in GCC? Clang is a newer implementatation, so you might think it's faster than GCC. But it manages only to be about the same. Compilers that blaze through large amounts of code in the blink of an eye are almost certainly dodging on the optimization. And because they don't need the internal /architecture/ to support the kinds optimizations they are not doing, they can speed up the code generation also. There is no need to generate an intermediate representation like SSA; you can pretty much just parse the syntax and emit assembly code in the same pass. Particularly if you only target one architecture. A poorly optimizing retargetable compiler that emits an abstract intermediate code will never be as blazingly fast as something equally poorly optimizing that goes straight to code in one pass. > * Having code where you naughtily cast a function pointer to or from a > function pointer is a no-no. Nobody said that, but it was pointed out that this isn't a feature of the ISO C standard dialect. It's actually a common extension, widely exploited by programs. There is nothing wrong with using it, but people who know C understand that it's not "maximally portable". Most code does not have to anywhere near "maximally portable". > * There is no benefit at all in having a tool like a compiler, be a > small, self-contained executable. Not as much as there used to, decades ago. -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2024-02-04 22:49 -0800 |
| Message-ID | <upq0ee$6bai$2@dont-email.me> |
| In reply to | #381793 |
On 2/4/2024 9:58 PM, Kaz Kylheku wrote: > On 2024-02-05, bart <bc@freeuk.com> wrote: >> >> In no particular order. >> >> * Software development can ONLY be done on a Unix-related OS >> >> * It is impossible to develop any software, let alone C, on pure Windows > > I've developed on DOS, TSR's? > Windows as well as for DSP chips and some > microcontrollers. I find most of the crap that you say is simply wrong. [...]
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <433-929-6894@kylheku.com> |
|---|---|
| Date | 2024-02-05 07:03 +0000 |
| Message-ID | <20240204230152.668@kylheku.com> |
| In reply to | #381796 |
On 2024-02-05, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: > On 2/4/2024 9:58 PM, Kaz Kylheku wrote: >> On 2024-02-05, bart <bc@freeuk.com> wrote: >>> >>> In no particular order. >>> >>> * Software development can ONLY be done on a Unix-related OS >>> >>> * It is impossible to develop any software, let alone C, on pure Windows >> >> I've developed on DOS, > > TSR's? I did make a couple of TSRs back in the day, but only as a hobby. Not in C. -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2024-02-04 23:51 -0800 |
| Message-ID | <upq41j$6t5v$1@dont-email.me> |
| In reply to | #381797 |
On 2/4/2024 11:03 PM, Kaz Kylheku wrote: > On 2024-02-05, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: >> On 2/4/2024 9:58 PM, Kaz Kylheku wrote: >>> On 2024-02-05, bart <bc@freeuk.com> wrote: >>>> >>>> In no particular order. >>>> >>>> * Software development can ONLY be done on a Unix-related OS >>>> >>>> * It is impossible to develop any software, let alone C, on pure Windows >>> >>> I've developed on DOS, >> >> TSR's? > > I did make a couple of TSRs back in the day, but only as a hobby. > > Not in C. > Nice. I only messed around with them a couple of times. There was a cool one, iirc, called key correspondence (KEYCOR), iirc. It was programmable, and could be used with any program. I used it for a reporting system and to control WordPerfect 5.1. I still have it! lol. For legacy purposes.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2024-02-04 23:52 -0800 |
| Message-ID | <upq431$6t5v$2@dont-email.me> |
| In reply to | #381801 |
On 2/4/2024 11:51 PM, Chris M. Thomasson wrote: > On 2/4/2024 11:03 PM, Kaz Kylheku wrote: >> On 2024-02-05, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: >>> On 2/4/2024 9:58 PM, Kaz Kylheku wrote: >>>> On 2024-02-05, bart <bc@freeuk.com> wrote: >>>>> >>>>> In no particular order. >>>>> >>>>> * Software development can ONLY be done on a Unix-related OS >>>>> >>>>> * It is impossible to develop any software, let alone C, on pure >>>>> Windows >>>> >>>> I've developed on DOS, >>> >>> TSR's? >> >> I did make a couple of TSRs back in the day, but only as a hobby. >> >> Not in C. >> > > Nice. I only messed around with them a couple of times. There was a cool > one, iirc, called key correspondence (KEYCOR), iirc. It was > programmable, and could be used with any program. I used it for a > reporting system and to control WordPerfect 5.1. I still have it! lol. > For legacy purposes. Writing WordPerfect 5.1 macros was a fun time.... ;^o
[toc] | [prev] | [next] | [standalone]
| From | Jan van den Broek <balglaas@dds.nl> |
|---|---|
| Date | 2024-02-05 08:36 +0000 |
| Message-ID | <upq6mv$7b1f$1@dont-email.me> |
| In reply to | #381802 |
2024-02-05, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> schrieb:
> On 2/4/2024 11:51 PM, Chris M. Thomasson wrote:
[Schnipp]
>> Nice. I only messed around with them a couple of times. There was a cool
>> one, iirc, called key correspondence (KEYCOR), iirc. It was
>> programmable, and could be used with any program. I used it for a
>> reporting system and to control WordPerfect 5.1. I still have it! lol.
>> For legacy purposes.
>
> Writing WordPerfect 5.1 macros was a fun time.... ;^o
Writing my own macro-compiler was also fun.
--
Jan v/d Broek
balglaas@dds.nl
Look out, here he comes again
The kid with the replaceable head
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2024-02-05 18:23 +0200 |
| Message-ID | <20240205182347.00000d37@yahoo.com> |
| In reply to | #381793 |
On Mon, 5 Feb 2024 05:58:55 -0000 (UTC) Kaz Kylheku <433-929-6894@kylheku.com> wrote: > On 2024-02-05, bart <bc@freeuk.com> wrote: > > > > In no particular order. > > > > * Software development can ONLY be done on a Unix-related OS > > > > * It is impossible to develop any software, let alone C, on pure > > Windows > > I've developed on DOS, Windows as well as for DSP chips and some > microcontrollers. I find most of the crap that you say is simply > wrong. > > Speaking of Windows, the CL.EXE compiler does not know where its > include files are. You literally cannot do "cl program.c". > You have to give it options which tell it where the SDK is installed: > where the headers and libraries are. > It depends on definitions. cl.exe called from random command prompt, either cmd.exe or powershell, does not know. cl.exe called from "x64 Native Tools Command Prompt for VS 2019" that I have installed on the computer that I'm writing this message, knows very well where they are, because when I clicked on the shortcut it was written into environment variables, respectively named Include and Lib. So, from this prompt I can do "cl program.c". In practice, I d likely prefer "cl -W4 -O1 -MD program.c", but that's because I am more than most people concerned about unimportant details. Call it a defect of character. > The Visual Studio project-file-driven build build system passes all > those details to every invocation of CL.EXE. Your project file (called > a "solution" nowadays) includes information like the path where your > SDK is installed. In the GUI there is some panel where you specify > it. > > If I'm going to be doing programming on Windows today, it's either > going be some version of that CL.EXE compiler from Microsoft, or GCC. > Native C language gcc programming under MSYS2 and native C language clang programming under MSYS2 have extremely similar look and feel. I can't think about any technical reasons to prefer one over the other.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2024-02-05 18:32 +0200 |
| Message-ID | <20240205183233.00000632@yahoo.com> |
| In reply to | #381793 |
On Mon, 5 Feb 2024 05:58:55 -0000 (UTC) Kaz Kylheku <433-929-6894@kylheku.com> wrote: > > Is it due to decades of legacy code in GCC? Clang is a newer > implementatation, so you might think it's faster than GCC. But it > manages only to be about the same. > I still believe that "decades of legacy" are the main reason. clang *was* much faster than gcc 10-12 years ago. Since then it accumulated a decade of legacy. And this particular decade mostly consisted of code that was written by people that (a) less experienced than gcc maintainers (b) care about speed of compilation even less than gcc maintainers. Well, for the later, I don't really believe that it is possible, but I need to bring a plausible explanation, don't I?
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-02-05 20:53 +0100 |
| Message-ID | <uprec5$eb3i$2@dont-email.me> |
| In reply to | #381825 |
On 05/02/2024 17:32, Michael S wrote: > On Mon, 5 Feb 2024 05:58:55 -0000 (UTC) > Kaz Kylheku <433-929-6894@kylheku.com> wrote: >> >> Is it due to decades of legacy code in GCC? Clang is a newer >> implementatation, so you might think it's faster than GCC. But it >> manages only to be about the same. >> > > I still believe that "decades of legacy" are the main reason. > clang *was* much faster than gcc 10-12 years ago. Since then it > accumulated a decade of legacy. And this particular decade mostly > consisted of code that was written by people that (a) less experienced > than gcc maintainers (b) care about speed of compilation even less than > gcc maintainers. Well, for the later, I don't really believe that it is > possible, but I need to bring a plausible explanation, don't I? > Early clang was faster than C at compilation and static error checking. And it had much nicer formats and outputs for its warnings. But it wasn't close to gcc for optimisation and generated code efficiency, and had less powerful checking. Over time, clang has gained a lot more optimisation and is now similar to gcc in code generation (each is better at some things), while gcc has sped up some aspects and greatly improved the warning formats. clang is now a similar speed to gcc because it does a similar job. It turns out that doing a lot of analysis and code optimisation takes effort.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <433-929-6894@kylheku.com> |
|---|---|
| Date | 2024-02-05 20:53 +0000 |
| Message-ID | <20240205124031.788@kylheku.com> |
| In reply to | #381848 |
On 2024-02-05, David Brown <david.brown@hesbynett.no> wrote: > On 05/02/2024 17:32, Michael S wrote: >> On Mon, 5 Feb 2024 05:58:55 -0000 (UTC) >> Kaz Kylheku <433-929-6894@kylheku.com> wrote: >>> >>> Is it due to decades of legacy code in GCC? Clang is a newer >>> implementatation, so you might think it's faster than GCC. But it >>> manages only to be about the same. >>> >> >> I still believe that "decades of legacy" are the main reason. >> clang *was* much faster than gcc 10-12 years ago. Since then it >> accumulated a decade of legacy. And this particular decade mostly >> consisted of code that was written by people that (a) less experienced >> than gcc maintainers (b) care about speed of compilation even less than >> gcc maintainers. Well, for the later, I don't really believe that it is >> possible, but I need to bring a plausible explanation, don't I? >> > > Early clang was faster than C at compilation and static error checking. > And it had much nicer formats and outputs for its warnings. But it > wasn't close to gcc for optimisation and generated code efficiency, and > had less powerful checking. > > Over time, clang has gained a lot more optimisation and is now similar > to gcc in code generation (each is better at some things), while gcc has > sped up some aspects and greatly improved the warning formats. > > clang is now a similar speed to gcc because it does a similar job. It > turns out that doing a lot of analysis and code optimisation takes effort. It takes more and more effort for diminishing results. A compiler can spend a lot of time just searching for the conditions that allow a certain optimization, where those conditions turn out to be false most of the time. So that in a large code base, there will be just a couple of "hits" (the conditions are met, and the optimization can take place). Yet all the instruction sequences in every basic block in every file had to be looked at to determine that. Mnay of these conditions are specific to the optimization. Another kind of optimization has its own conditions that don't reuse anything from that one. So the more optimizations you add, the more work it takes just to determine applicability. The optimizer may have to iterate on the program graph. After certain optimizations are applied, the program graph changes. And that may "unlock" more opportunities to do optimizations that were not possible before. But because the program graph changed, its properties have to be recalculated, like liveness of variables/temporaries and whatnot. More time. -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-02-06 09:44 +0100 |
| Message-ID | <upsrh5$qb8m$1@dont-email.me> |
| In reply to | #381849 |
On 05/02/2024 21:53, Kaz Kylheku wrote: > On 2024-02-05, David Brown <david.brown@hesbynett.no> wrote: >> On 05/02/2024 17:32, Michael S wrote: >>> On Mon, 5 Feb 2024 05:58:55 -0000 (UTC) >>> Kaz Kylheku <433-929-6894@kylheku.com> wrote: >>>> >>>> Is it due to decades of legacy code in GCC? Clang is a newer >>>> implementatation, so you might think it's faster than GCC. But it >>>> manages only to be about the same. >>>> >>> >>> I still believe that "decades of legacy" are the main reason. >>> clang *was* much faster than gcc 10-12 years ago. Since then it >>> accumulated a decade of legacy. And this particular decade mostly >>> consisted of code that was written by people that (a) less experienced >>> than gcc maintainers (b) care about speed of compilation even less than >>> gcc maintainers. Well, for the later, I don't really believe that it is >>> possible, but I need to bring a plausible explanation, don't I? >>> >> >> Early clang was faster than C at compilation and static error checking. >> And it had much nicer formats and outputs for its warnings. But it >> wasn't close to gcc for optimisation and generated code efficiency, and >> had less powerful checking. >> >> Over time, clang has gained a lot more optimisation and is now similar >> to gcc in code generation (each is better at some things), while gcc has >> sped up some aspects and greatly improved the warning formats. >> >> clang is now a similar speed to gcc because it does a similar job. It >> turns out that doing a lot of analysis and code optimisation takes effort. > > It takes more and more effort for diminishing results. > Yes. > A compiler can spend a lot of time just searching for the conditions > that allow a certain optimization, where those conditions turn out to be > false most of the time. So that in a large code base, there will be just > a couple of "hits" (the conditions are met, and the optimization can > take place). Yet all the instruction sequences in every basic block in > every file had to be looked at to determine that. This is always the case with optimisations. Each pass might only give a few percent increase in speed - but when you have 50 passes, this adds up to a lot. And some passes (that is, some types of optimisation) can open up new opportunities for if you redo previous passes. And the same applies to static error checking - there is quite an overlap in the kinds of analysis used for optimisations and for static error checking. > > Mnay of these conditions are specific to the optimization. Another > kind of optimization has its own conditions that don't reuse anything > from that one. So the more optimizations you add, the more work it takes > just to determine applicability. > > The optimizer may have to iterate on the program graph. After certain > optimizations are applied, the program graph changes. And that may > "unlock" more opportunities to do optimizations that were not possible > before. But because the program graph changed, its properties have to be > recalculated, like liveness of variables/temporaries and whatnot. > More time. > Yes. For a great lot of code, it is not necessary to squeeze out as much speed as possible. But IMHO it is usually a good idea to have as much static error checking as you reasonably can without too high a risk of false positives. Major compilers aren't really bothered about the speed of compilation of C code - it is usually fast enough that it is of little concern. Those that are building a lot, use make (or other build tools), perhaps ccache, and usually use machines with plenty of cores and plenty of ram. It's C++ that is the concern, especially big projects. And there you /do/ need at least some optimisation effort, because C++ is generally full of little functions that are expected to "disappear" entirely by inlining. So that is where the compiler developer effort goes for compiler speed, analysis, and optimisation. Programmers are notoriously bad at determining which bits of their code need to be efficient. And if they know their compiler is poor at optimising, they do "manual optimisation". They use pointers where arrays would be clearer. They reuse "temp" variables instead of making new ones. They write jumbles of "gotos" instead of breaking code into multiple functions. They write "(x << 3) + x" instead of "x * 9". It is much better to write the clearest source code you can, and let the compiler do its job and generate efficient object code. It's never a bad thing if a compiler is faster. But IMHO it is more important for the compiler to be /better/ - better warnings and checks that catch issues earlier, and better optimisation because that allows people to write code in the clearest, safest and most maintainable way while still getting good results.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2024-02-06 01:03 -0800 |
| Message-ID | <upsslj$qfe4$2@dont-email.me> |
| In reply to | #381903 |
On 2/6/2024 12:44 AM, David Brown wrote: [...] > Programmers are notoriously bad at determining which bits of their code > need to be efficient. This brings me back to a code base I was ask to take a look at. Well, the keyword register was all over the place! Spooky... [...]
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2024-02-06 13:41 +0200 |
| Message-ID | <20240206134152.00004138@yahoo.com> |
| In reply to | #381903 |
On Tue, 6 Feb 2024 09:44:20 +0100 David Brown <david.brown@hesbynett.no> wrote: > > > > A compiler can spend a lot of time just searching for the conditions > > that allow a certain optimization, where those conditions turn out > > to be false most of the time. So that in a large code base, there > > will be just a couple of "hits" (the conditions are met, and the > > optimization can take place). Yet all the instruction sequences in > > every basic block in every file had to be looked at to determine > > that. > > This is always the case with optimisations. Each pass might only > give a few percent increase in speed - but when you have 50 passes, > this adds up to a lot. And some passes (that is, some types of > optimisation) can open up new opportunities for if you redo previous > passes. Except that at least gcc by design never redo previous passes. More so, it does not even try to compare result of optimization with certain pass vs result without this pass and to take better of the two. I don't know if the same applies to clang, I never had conversations with clang maintainers (had plenty with gcc maintainers). However, the bottom line for last 2-3 years is that when I compare speed of gcc-compiled code vs clang-compiled then both can do good job and both can do ordinary stupid things, but clang is much more likely then gcc to do astonishingly stupid things. Like, for example, vectorization that reduces the speed by factor of 3 vs non-vectorized variant. So, most likely, clang also proceeds pass after pass after pass and never ever looks back. Seems like they took the lesson of Lot's wife very seriously. > And the same applies to static error checking - there is > quite an overlap in the kinds of analysis used for optimisations and > for static error checking. >
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-02-06 13:08 +0100 |
| Message-ID | <upt7ff$s5ov$3@dont-email.me> |
| In reply to | #381911 |
On 06/02/2024 12:41, Michael S wrote: > On Tue, 6 Feb 2024 09:44:20 +0100 > David Brown <david.brown@hesbynett.no> wrote: >> >> >>> A compiler can spend a lot of time just searching for the conditions >>> that allow a certain optimization, where those conditions turn out >>> to be false most of the time. So that in a large code base, there >>> will be just a couple of "hits" (the conditions are met, and the >>> optimization can take place). Yet all the instruction sequences in >>> every basic block in every file had to be looked at to determine >>> that. >> >> This is always the case with optimisations. Each pass might only >> give a few percent increase in speed - but when you have 50 passes, >> this adds up to a lot. And some passes (that is, some types of >> optimisation) can open up new opportunities for if you redo previous >> passes. > > Except that at least gcc by design never redo previous passes. More so, > it does not even try to compare result of optimization with certain > pass vs result without this pass and to take better of the two. AFAIUI (I am not a gcc developer), gcc redoes certain types of optimisations after later passes - even if it calls them different pass numbers. For example, constant propagation and dead code elimination is done early on in functions. Then after inlining and IPA passes, it is done again using the new information. I expect you are correct that it does not try to compare the results from pass to pass. I think that would quickly be infeasible. You can't just compare the results of applying optimisation B to base A to see if it is better or worse than before A was, and then decide which to keep before moving to step C. Maybe A was better than AB, but ABC is better than AC. You'd need to keep comparing all sorts of combinations, and it would be a scalability nightmare. > > I don't know if the same applies to clang, I never had > conversations with clang maintainers (had plenty with gcc maintainers). > However, the bottom line for last 2-3 years is that when I compare > speed of gcc-compiled code vs clang-compiled then both can do good > job and both can do ordinary stupid things, but clang is much more > likely then gcc to do astonishingly stupid things. Like, for example, > vectorization that reduces the speed by factor of 3 vs non-vectorized > variant. I see the same, though I have not used clang very seriously for real work. It does, however, seem a bit over-enthusiastic about vectorising code. > So, most likely, clang also proceeds pass after pass after pass and > never ever looks back. Seems like they took the lesson of Lot's wife > very seriously. > > >> And the same applies to static error checking - there is >> quite an overlap in the kinds of analysis used for optimisations and >> for static error checking. >> >
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-02-06 23:23 +0000 |
| Message-ID | <upuf0v$13gvv$1@dont-email.me> |
| In reply to | #381903 |
On Tue, 6 Feb 2024 09:44:20 +0100, David Brown wrote: > They reuse "temp" variables instead of making new ones. I like to limit the scope of my temporary variables. In C, this is as easy as sticking a pair of braces around a few statements.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-02-07 08:54 +0100 |
| Message-ID | <upvcv5$1bcum$1@dont-email.me> |
| In reply to | #381935 |
On 07/02/2024 00:23, Lawrence D'Oliveiro wrote: > On Tue, 6 Feb 2024 09:44:20 +0100, David Brown wrote: > >> They reuse "temp" variables instead of making new ones. > > I like to limit the scope of my temporary variables. In C, this is as easy > as sticking a pair of braces around a few statements. Generally, you want to have the minimum practical scope for your local variables. It's rare that you need to add braces just to make a scope for a variable - usually you have enough braces in loops or conditionals - but it happens. However, the context here was compiler optimisation. Not all compilers have good optimisation. In the embedded world, there are vast numbers of C compilers, many of which are much more limited than the modern and advanced tools most of us use today. These weaker compilers are much rarer now, as are many of the ISAs they served - 32-bit ARM "M" cores are dominant along with gcc. But in the old days, an embedded C programmer had to write their code in a way that suited the compiler if they wanted the best out of their microcontroller - and efficient code means cheaper devices, lower power and longer battery life. Some of these weaker tools would allocate registers to local variables on a first come, first served basis, with no lifetime analysis or reuse inside a function. Thus you re-used your temporary variables. Making some "temp" variables and re-using them was also common for some people in idiomatic C90 code, where all your variables are declared at the top of the function.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2024-02-07 08:59 +0000 |
| Message-ID | <upvgp1$1bs8q$1@dont-email.me> |
| In reply to | #381948 |
On 07/02/2024 07:54, David Brown wrote: > On 07/02/2024 00:23, Lawrence D'Oliveiro wrote: >> On Tue, 6 Feb 2024 09:44:20 +0100, David Brown wrote: >> >>> They reuse "temp" variables instead of making new ones. >> >> I like to limit the scope of my temporary variables. In C, this is as >> easy >> as sticking a pair of braces around a few statements. > > Generally, you want to have the minimum practical scope for your local > variables. It's rare that you need to add braces just to make a scope > for a variable - usually you have enough braces in loops or conditionals > - but it happens. > The two common patterns are to give each variable the minimum scope, or to decare all variables at the start of the function and give them all function scope. The case for minimum scope is the same as the case for scope itself. The variable is accessible where it is used and not elsewhere, which makes it less likely it will be used in error, and means there are fewer names to understand. However there are also strong arguments for ducntion scope. A function is a natural unit. Adn all the varibales used in that unit are listed together and, ideally, commented. So at a glance you can see what is in scope and what is being operated on. And there are only three levels of scope. A varibale is global, or it is file scope, or it is scoped to the function. I tend to prefer function scope for C. However I use a lot of C++ these days, and in C++ local scope is often better, and in some cases even necessary. So I find that I'm tending to use local scope in C more. -- Check out Basic Algorithms and my other books: https://www.lulu.com/spotlight/bgy1mm
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2024-02-07 10:47 +0000 |
| Message-ID | <87y1bwtuss.fsf@bsb.me.uk> |
| In reply to | #381952 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > On 07/02/2024 07:54, David Brown wrote: >> On 07/02/2024 00:23, Lawrence D'Oliveiro wrote: >>> On Tue, 6 Feb 2024 09:44:20 +0100, David Brown wrote: >>> >>>> They reuse "temp" variables instead of making new ones. >>> >>> I like to limit the scope of my temporary variables. In C, this is as >>> easy >>> as sticking a pair of braces around a few statements. >> Generally, you want to have the minimum practical scope for your local >> variables. It's rare that you need to add braces just to make a scope >> for a variable - usually you have enough braces in loops or conditionals >> - but it happens. >> > The two common patterns are to give each variable the minimum scope, or to > decare all variables at the start of the function and give them all > function scope. The term "function scope" has a specific meaning in C. Only labels have function scope. I know you are not very interested in using exact terms, but some people might like to know the details. Since you want to argue for the peculiar (but common) practice of giving names the largest possible scope (without altering their linkage) you need a term for the outer-most block scope, but "function scope" is taken. > The case for minimum scope is the same as the case for scope itself. Someone might well misinterpret the term "minimum scope" since it would require adding lots of otherwise redundant braces. I *think* you mean declaring names at the point of first use. The resulting scope is not minimum because it often extends beyond the point of last use. Other people, not familiar with" modern" C, might interpret the term to mean declaring names at the top of the inner-most appropriate block. > The > variable is accessible where it is used and not elsewhere, which makes it > less likely it will be used in error, and means there are fewer names to > understand. The case for declaration at first use is much stronger than this. It almost always allows for a meaningful initialisation at the same point, so the initialisation does not need to be hunted down a checked. For me, this is a big win. (Yes, some people then insist on a dummy initialisation when the proper one isn't know, but that's a fudge that is, to my mind, even worse.) > However there are also strong arguments for ducntion scope. A function is a > natural unit. Adn all the varibales used in that unit are listed together > and, ideally, commented. So at a glance you can see what is in scope and > what is being operated on. You should not need an inventory of what's being operated on. Any function so complex that I can't tell immediately what declaration corresponds to which name needs to be re-written. I'd argue that this is also a big win for "short scopes". A policy that leads to early triggers for refactoring is worth considering. > And there are only three levels of scope. A > varibale is global, or it is file scope, or it is scoped to the > function. You are mixing up scope and lifetime. C has no "global scope". A name may have external linkage (which is probably what you are referring to), but that is not directly connected to its scope. > I tend to prefer function scope for C. We could call it outer-most block scope rather than re-use a term with an existing, but different, technical meaning. > However I use a lot of C++ these > days, and in C++ local scope is often better, and in some cases even > necessary. So I find that I'm tending to use local scope in C more. Interesting. Is it just that using C++ has given you what you would think of as a bad habit in C, or has using C++ led you to see that your old preference was not the best one? -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2024-02-07 11:04 +0000 |
| Message-ID | <upvo4c$1d64i$1@dont-email.me> |
| In reply to | #381958 |
On 07/02/2024 10:47, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>> However there are also strong arguments for function scope. A function is a
>> natural unit. And all the variables used in that unit are listed together
>> and, ideally, commented. So at a glance you can see what is in scope and
>> what is being operated on. [typos fixed]
>
> You should not need an inventory of what's being operated on. Any
> function so complex that I can't tell immediately what declaration
> corresponds to which name needs to be re-written.
But if you keep functions small, eg. the whole body is visible at the
same time, then there is less need for declarations to clutter up the
code. They can go at the top, so that you can literally can just glance
there.
>> And there are only three levels of scope. A
>> varibale is global, or it is file scope, or it is scoped to the
>> function.
> You are mixing up scope and lifetime. C has no "global scope". A name
> may have external linkage (which is probably what you are referring to),
> but that is not directly connected to its scope.
Funny, I use the same definitions of scope:
int abc; // inter-file scope, may be imported or exported
static int def; // file scope
void F(void) {
int ghi; // function-scope
}
If I look inside my compiler, I can see these sets of enums to describe
scope (not C code):
(function_scope, "Fn"), !within a function (note
import/exported names can be declared in a block scope)
(local_scope, "Loc"), !file-scope/not exported
(imported_scope, "Imp"), !imported from another module
(exported_scope, "Exp") !file-scope/exported
end
Within a function, there is an additional mechanism to deal with block
scopes. Plus another overall to deal with namespaces.
[toc] | [prev] | [next] | [standalone]
Page 1 of 7 [1] 2 3 4 5 6 7 Next page →
Back to top | Article view | comp.lang.c
csiph-web