Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #100318 > unrolled thread
| Started by | BartC <bc@freeuk.com> |
|---|---|
| First post | 2016-12-27 14:08 +0000 |
| Last post | 2016-12-27 11:42 -0600 |
| Articles | 20 on this page of 202 — 18 participants |
Back to article view | Back to comp.lang.c
Octal BartC <bc@freeuk.com> - 2016-12-27 14:08 +0000
Octal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-27 06:19 -0800
Re: Octal BartC <bc@freeuk.com> - 2016-12-27 14:58 +0000
Re: Octal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-27 07:07 -0800
Re: Octal BartC <bc@freeuk.com> - 2016-12-27 15:22 +0000
Re: Octal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-27 07:37 -0800
Re: Octal BartC <bc@freeuk.com> - 2016-12-27 16:24 +0000
Re: Octal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-27 08:30 -0800
Re: Octal supercat@casperkitty.com - 2016-12-27 09:10 -0800
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-27 09:35 -0800
Re: Octal supercat@casperkitty.com - 2016-12-27 10:47 -0800
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-27 12:03 -0800
Re: Octal supercat@casperkitty.com - 2016-12-27 12:27 -0800
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-27 12:44 -0800
Re: Octal supercat@casperkitty.com - 2016-12-27 13:37 -0800
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-27 16:38 -0800
Re: Octal supercat@casperkitty.com - 2016-12-27 17:53 -0800
Re: Octal Robert Wessel <robertwessel2@yahoo.com> - 2016-12-27 20:26 -0600
Re: Octal supercat@casperkitty.com - 2016-12-27 18:48 -0800
Re: Octal Robert Wessel <robertwessel2@yahoo.com> - 2016-12-27 22:20 -0600
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-27 18:41 -0800
Re: Octal supercat@casperkitty.com - 2016-12-27 19:19 -0800
Re: Octal Ian Collins <ian-news@hotmail.com> - 2016-12-29 14:52 +1300
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-28 18:41 -0800
Re: Octal Tim Rentsch <txr@alumni.caltech.edu> - 2016-12-28 16:54 -0800
Re: Octal BartC <bc@freeuk.com> - 2016-12-27 17:44 +0000
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-27 12:17 -0800
Re: Octal BartC <bc@freeuk.com> - 2016-12-27 22:39 +0000
Re: Octal Ian Collins <ian-news@hotmail.com> - 2016-12-28 11:49 +1300
Re: Octal BartC <bc@freeuk.com> - 2016-12-27 23:09 +0000
Re: Octal Ian Collins <ian-news@hotmail.com> - 2016-12-28 12:32 +1300
Re: Octal BartC <bc@freeuk.com> - 2016-12-28 00:51 +0000
Re: Octal Ian Collins <ian-news@hotmail.com> - 2016-12-28 14:00 +1300
Re: Octal BartC <bc@freeuk.com> - 2016-12-28 01:13 +0000
Re: Octal Robert Wessel <robertwessel2@yahoo.com> - 2016-12-27 20:04 -0600
Re: Octal supercat@casperkitty.com - 2016-12-27 18:45 -0800
Re: Octal Tim Rentsch <txr@alumni.caltech.edu> - 2016-12-29 13:35 -0800
Re: Octal supercat@casperkitty.com - 2016-12-29 14:49 -0800
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-29 15:33 -0800
Re: Octal supercat@casperkitty.com - 2016-12-30 12:35 -0800
Re: Octal Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-13 15:19 -0800
Re: Octal Keith Thompson <kst-u@mib.org> - 2017-01-13 15:32 -0800
Re: Octal Ian Collins <ian-news@hotmail.com> - 2017-01-14 12:35 +1300
Re: Octal Keith Thompson <kst-u@mib.org> - 2017-01-13 15:51 -0800
Re: Octal supercat@casperkitty.com - 2017-01-13 18:25 -0800
Re: Octal Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-01-14 06:21 -0800
Re: Octal supercat@casperkitty.com - 2017-01-14 14:00 -0800
Re: Octal Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-15 23:08 -0800
Re: Octal Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-15 23:02 -0800
Re: Octal supercat@casperkitty.com - 2017-01-13 18:52 -0800
Re: Octal Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-15 23:46 -0800
Re: Octal supercat@casperkitty.com - 2017-01-16 01:46 -0800
Re: Octal Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-31 08:33 -0800
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-27 17:19 -0800
Re: Octal raltbos@xs4all.nl (Richard Bos) - 2016-12-28 09:39 +0000
Re: Octal BartC <bc@freeuk.com> - 2016-12-28 11:02 +0000
Re: Octal David Brown <david.brown@hesbynett.no> - 2016-12-28 12:13 +0100
Re: Octal BartC <bc@freeuk.com> - 2016-12-28 11:41 +0000
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-28 09:31 -0800
Re: Octal BartC <bc@freeuk.com> - 2016-12-28 17:39 +0000
Re: Octal David Brown <david.brown@hesbynett.no> - 2016-12-28 22:05 +0100
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-28 12:01 -0800
Re: Octal BartC <bc@freeuk.com> - 2016-12-28 20:05 +0000
Re: Octal asetofsymbols@gmail.com - 2016-12-28 11:20 -0800
Re: Octal Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-28 12:01 +0000
Re: Octal BartC <bc@freeuk.com> - 2016-12-28 12:30 +0000
Re: Octal David Brown <david.brown@hesbynett.no> - 2016-12-28 13:51 +0100
Re: Octal Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-28 16:26 +0000
Re: Octal supercat@casperkitty.com - 2016-12-28 08:40 -0800
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-28 09:41 -0800
Re: Octal BartC <bc@freeuk.com> - 2016-12-28 18:04 +0000
Re: Octal Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-28 19:36 +0000
Re: Octal BartC <bc@freeuk.com> - 2016-12-28 19:42 +0000
Re: Octal Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-29 00:34 +0000
Re: Octal supercat@casperkitty.com - 2016-12-28 11:04 -0800
Re: Octal raltbos@xs4all.nl (Richard Bos) - 2016-12-28 12:09 +0000
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-27 16:46 -0800
Re: Octal BartC <bc@freeuk.com> - 2016-12-28 00:56 +0000
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-27 17:52 -0800
Re: Octal BartC <bc@freeuk.com> - 2016-12-28 11:27 +0000
Re: Octal Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-28 12:09 +0000
Re: Octal supercat@casperkitty.com - 2016-12-28 08:17 -0800
Re: Octal BartC <bc@freeuk.com> - 2016-12-28 17:02 +0000
Re: Octal Ike Naar <ike@iceland.freeshell.org> - 2016-12-28 17:25 +0000
Re: Octal BartC <bc@freeuk.com> - 2016-12-28 17:45 +0000
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-28 10:21 -0800
Re: Octal supercat@casperkitty.com - 2016-12-28 09:27 -0800
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-28 10:23 -0800
Re: Octal supercat@casperkitty.com - 2016-12-28 11:18 -0800
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-28 10:19 -0800
Re: Octal BartC <bc@freeuk.com> - 2016-12-29 15:54 +0000
Re: Octal Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-29 12:57 -0800
Re: Octal Ian Collins <ian-news@hotmail.com> - 2016-12-30 10:01 +1300
Re: Octal David Brown <david.brown@hesbynett.no> - 2016-12-30 10:44 +0100
Re: Octal David Brown <david.brown@hesbynett.no> - 2016-12-29 17:32 +0100
Re: Octal BartC <bc@freeuk.com> - 2016-12-29 17:03 +0000
Re: Octal Robert Wessel <robertwessel2@yahoo.com> - 2016-12-29 16:26 -0600
Re: Octal Ian Collins <ian-news@hotmail.com> - 2016-12-30 11:31 +1300
Re: Octal Robert Wessel <robertwessel2@yahoo.com> - 2016-12-29 16:58 -0600
Re: Octal Ian Collins <ian-news@hotmail.com> - 2016-12-30 11:59 +1300
Re: Octal Ian Collins <ian-news@hotmail.com> - 2016-12-30 09:00 +1300
Re: Octal David Brown <david.brown@hesbynett.no> - 2016-12-30 10:21 +0100
Re: Octal asetofsymbols@gmail.com - 2016-12-30 01:29 -0800
Re: Octal asetofsymbols@gmail.com - 2016-12-30 01:29 -0800
Re: Octal asetofsymbols@gmail.com - 2016-12-30 01:36 -0800
Re: Octal BartC <bc@freeuk.com> - 2016-12-29 11:52 +0000
Re: Octal BartC <bc@freeuk.com> - 2016-12-29 17:10 +0000
Re: Octal supercat@casperkitty.com - 2016-12-29 05:52 -0800
Re: Octal Robert Wessel <robertwessel2@yahoo.com> - 2016-12-28 19:51 -0600
Re: Octal BartC <bc@freeuk.com> - 2016-12-29 21:09 +0000
Re: Octal Ian Collins <ian-news@hotmail.com> - 2016-12-30 10:15 +1300
Re: Octal Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-29 13:53 -0800
Re: Octal David Brown <david.brown@hesbynett.no> - 2016-12-30 12:07 +0100
Re: Octal BartC <bc@freeuk.com> - 2016-12-30 13:04 +0000
Re: Octal Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-30 05:31 -0800
Re: Octal David Brown <david.brown@hesbynett.no> - 2016-12-30 15:00 +0100
Re: Octal BartC <bc@freeuk.com> - 2016-12-30 15:55 +0000
Re: Octal David Brown <david.brown@hesbynett.no> - 2017-01-01 16:00 +0100
Re: Octal Ian Collins <ian-news@hotmail.com> - 2017-01-02 08:33 +1300
Re: Octal Ian Collins <ian-news@hotmail.com> - 2017-01-02 09:02 +1300
Re: Octal Ian Collins <ian-news@hotmail.com> - 2017-01-02 09:38 +1300
Re: Octal Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-01-01 13:59 -0800
Re: Octal Keith Thompson <kst-u@mib.org> - 2017-01-01 14:24 -0800
Re: Octal supercat@casperkitty.com - 2017-01-01 15:51 -0800
Re: Octal Ian Collins <ian-news@hotmail.com> - 2017-01-02 13:09 +1300
Re: Octal supercat@casperkitty.com - 2017-01-01 16:50 -0800
Re: Octal Ian Collins <ian-news@hotmail.com> - 2017-01-02 14:24 +1300
Re: Octal David Brown <david.brown@hesbynett.no> - 2017-01-02 01:53 +0100
Re: Octal Ian Collins <ian-news@hotmail.com> - 2017-01-02 14:15 +1300
Re: Octal Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-02 02:28 -0800
Re: Octal Ian Collins <ian-news@hotmail.com> - 2016-12-31 06:24 +1300
Re: Octal BartC <bc@freeuk.com> - 2016-12-30 17:53 +0000
Re: Octal luser droog <luser.droog@gmail.com> - 2016-12-30 10:01 -0800
Re: Octal Ian Collins <ian-news@hotmail.com> - 2016-12-31 09:57 +1300
Re: Octal supercat@casperkitty.com - 2016-12-30 13:50 -0800
Re: Octal Ian Collins <ian-news@hotmail.com> - 2016-12-31 11:09 +1300
Re: Octal supercat@casperkitty.com - 2016-12-30 14:46 -0800
Re: Octal Ian Collins <ian-news@hotmail.com> - 2016-12-31 12:28 +1300
Re: Octal supercat@casperkitty.com - 2016-12-30 16:01 -0800
Re: Octal Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-30 14:48 -0800
Re: Octal BartC <bc@freeuk.com> - 2016-12-30 22:51 +0000
Re: Octal supercat@casperkitty.com - 2016-12-30 15:20 -0800
Re: Octal Ian Collins <ian-news@hotmail.com> - 2016-12-31 12:34 +1300
Re: Octal BartC <bc@freeuk.com> - 2016-12-30 23:40 +0000
Re: Octal BartC <bc@freeuk.com> - 2016-12-30 22:12 +0000
Re: Octal raltbos@xs4all.nl (Richard Bos) - 2016-12-28 21:38 +0000
Re: Octal BartC <bc@freeuk.com> - 2016-12-29 12:04 +0000
Re: Octal David Brown <david.brown@hesbynett.no> - 2016-12-29 13:42 +0100
Re: Octal Ian Collins <ian-news@hotmail.com> - 2016-12-30 08:59 +1300
Re: Octal supercat@casperkitty.com - 2016-12-29 12:23 -0800
Re: Octal David Brown <david.brown@hesbynett.no> - 2016-12-30 10:56 +0100
Re: Octal BartC <bc@freeuk.com> - 2016-12-28 22:09 +0000
Re: Octal David Brown <david.brown@hesbynett.no> - 2016-12-29 12:27 +0100
Re: Octal BartC <bc@freeuk.com> - 2016-12-28 21:18 +0000
Re: Octal BartC <bc@freeuk.com> - 2016-12-28 20:46 +0000
Re: Octal raltbos@xs4all.nl (Richard Bos) - 2016-12-28 20:55 +0000
Re: Octal Robert Wessel <robertwessel2@yahoo.com> - 2016-12-28 14:54 -0600
Re: Octal BartC <bc@freeuk.com> - 2016-12-29 15:44 +0000
Re: Octal BartC <bc@freeuk.com> - 2016-12-28 19:39 +0000
Re: Octal Robert Wessel <robertwessel2@yahoo.com> - 2016-12-28 15:04 -0600
Re: Octal raltbos@xs4all.nl (Richard Bos) - 2016-12-28 19:52 +0000
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-29 09:36 -0800
Re: Octal BartC <bc@freeuk.com> - 2016-12-29 18:02 +0000
Re: Octal BartC <bc@freeuk.com> - 2016-12-30 16:17 +0000
Re: Octal David Brown <david.brown@hesbynett.no> - 2017-01-01 16:09 +0100
Re: Octal BartC <bc@freeuk.com> - 2016-12-28 20:02 +0000
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-28 12:32 -0800
Re: Octal Richard Heathfield <rjh@cpax.org.uk> - 2016-12-29 13:45 +0000
Re: Octal Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-28 17:16 +0000
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-28 10:04 -0800
Re: Octal Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-02 02:26 -0800
Re: Octal Keith Thompson <kst-u@mib.org> - 2017-01-02 12:35 -0800
Re: Octal Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-12 23:22 -0800
Re: Octal Keith Thompson <kst-u@mib.org> - 2017-01-13 10:04 -0800
Re: Octal Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-14 00:45 -0800
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-28 09:59 -0800
Re: Octal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-27 09:45 -0800
Re: Octal David Brown <david.brown@hesbynett.no> - 2016-12-27 17:14 +0100
Re: Octal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-27 08:23 -0800
Re: Octal David Brown <david.brown@hesbynett.no> - 2016-12-28 10:37 +0100
Re: Octal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-28 03:07 -0800
Re: Octal David Brown <david.brown@hesbynett.no> - 2016-12-28 12:25 +0100
Re: Octal Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-28 11:58 +0000
Re: Octal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-28 04:35 -0800
Re: Octal Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-28 17:31 +0000
Re: Octal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-28 09:38 -0800
Re: Octal Robert Wessel <robertwessel2@yahoo.com> - 2016-12-28 15:12 -0600
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-28 12:01 -0800
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-28 09:20 -0800
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-28 13:39 -0800
Re: Octal David Brown <david.brown@hesbynett.no> - 2016-12-29 12:29 +0100
Re: Octal David Brown <david.brown@hesbynett.no> - 2016-12-28 22:20 +0100
Re: Octal Noob <root@127.0.0.1> - 2016-12-28 13:02 +0100
Re: Octal David Brown <david.brown@hesbynett.no> - 2016-12-28 13:30 +0100
Re: Octal BartC <bc@freeuk.com> - 2016-12-28 13:25 +0000
Re: Octal Manfred <noname@invalid.add> - 2016-12-27 15:19 +0100
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-27 08:37 -0800
Re: Octal Manfred <noname@invalid.add> - 2016-12-27 18:43 +0100
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-27 12:07 -0800
Re: Octal Manfred <noname@invalid.add> - 2016-12-27 18:21 +0100
Re: Octal David Brown <david.brown@hesbynett.no> - 2016-12-27 15:28 +0100
Re: Octal BGB <cr88192@hotmail.com> - 2016-12-27 11:42 -0600
Page 6 of 11 — ← Prev page 1 … 4 5 [6] 7 8 … 11 Next page →
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2016-12-30 09:00 +1300 |
| Message-ID | <ecl8b6Fpuo9U3@mid.individual.net> |
| In reply to | #100532 |
On 12/30/16 06:03 AM, BartC wrote: > On 29/12/2016 16:32, David Brown wrote: >> On 29/12/16 16:54, BartC wrote: > >>> Compiling one of my programs from scratch on an early Raspberry Pi takes >>> about 5 minutes using gcc -O3. That's about 100 lines per second, on a >>> 700MHz processor. >> >> The earliest Raspberry Pi's were very slow, and had particularly slow >> "disks". But so what? > > The same machine, with the same 'slow' disks, can compile bytecode at up > to 50K lines per second (and I expected up to 100K lps, but am at the > mercy of gcc's code generator until I can investigate for myself). > > A 700MHz 32-bit machine with solid-state disks should be a supercomputer > compared with what many of us were using in the 80s, or even the 90s. I wouldn't class an SD card as "solid-state disks"! -- Ian
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-12-30 10:21 +0100 |
| Message-ID | <o458so$7dt$1@dont-email.me> |
| In reply to | #100532 |
On 29/12/16 18:03, BartC wrote: > On 29/12/2016 16:32, David Brown wrote: >> Yes, well, different people have different needs. But it gets silly >> when you repeatedly condemn gcc as big and slow when you don't actually >> understand it and why it is different from a tool like TCC. If TCC is >> better for /your/ needs, then that's great - use TCC. Just don't >> imagine that /your/ needs and priorities apply to anyone else. > > Some interesting views coming out on this thread. It seems that even if > a compiler and build system processed an infinite number of lines per > second, and had compile/build times of 0.0 seconds, then people would > still prefer to stick with their old lumbering versions! > If you provided me with a compiler that was a 100 times faster than gcc at compilation and generated code that was just as efficient at run-time, would I use it? No, I would not use it. It would have to be at least as good as gcc in all the other points I mentioned - because compilation speed is usually not an issue for me. Would I /prefer/ that gcc compiled faster? Absolutely - but not if it meant losing other features. Is that really so hard to understand? > And if those tools are a bit too slow, then buy a much faster computer > to run them on! (re. your cross-compiling comment). I am a /professional/. Maybe you are just programming as a hobby. But if compilation speed were affecting my productivity, then I /would/ simply buy a faster computer. As long as that is an option, and not excessively expensive, then that /is/ a valid way to deal with slow compilation speed - certainly it beats changing to a poorer quality or more limited tool. (Other options, such as re-arranging source code or build systems, using ccache, pre-compiled headers, etc., are also possible.) > > I condemn gcc because whenever /I/ use it, it /is/ slow. But I have to > admit it does the job (eventually). >
[toc] | [prev] | [next] | [standalone]
| From | asetofsymbols@gmail.com |
|---|---|
| Date | 2016-12-30 01:29 -0800 |
| Message-ID | <db1d5040-0dc4-4944-ae7f-9c7a2ca222d5@googlegroups.com> |
| In reply to | #100636 |
The problem is hll way... Build hll on hlls... So CPU cicle and disk are missing in that tower of Babel... Instead the base of one compiler or one Os (as executable) or one big program Has to have code cpu run in 80% cpu time written in pure assembly The remain can be C, C++ Python or some hll
[toc] | [prev] | [next] | [standalone]
| From | asetofsymbols@gmail.com |
|---|---|
| Date | 2016-12-30 01:29 -0800 |
| Message-ID | <98e50ded-5dce-4b13-8d7d-4cdd5693de37@googlegroups.com> |
| In reply to | #100636 |
The problem is hll way... Build hll on hlls... So CPU cicle and disk are missing in that tower of Babel... Instead the base of one compiler or one Os (as executable) or one big program Has to have code cpu run in 80% cpu time written in pure assembly The remain can be C, C++ Python or some hll
[toc] | [prev] | [next] | [standalone]
| From | asetofsymbols@gmail.com |
|---|---|
| Date | 2016-12-30 01:36 -0800 |
| Message-ID | <7b482504-77ef-4697-a100-7fe987dd387f@googlegroups.com> |
| In reply to | #100638 |
For example if one hll compiler has basic instructions for example +-*/ ecc are pure assembly routines And because these operation are more CPU cicle consuming, can happen that the program it generate run more time in assembly routines that the other hll ones
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-12-29 11:52 +0000 |
| Message-ID | <o42tbn$ct0$1@dont-email.me> |
| In reply to | #100455 |
On 29/12/2016 01:51, Robert Wessel wrote:
> On Wed, 28 Dec 2016 20:46:01 +0000, BartC <bc@freeuk.com> wrote:
>> (And FWIW the project I'm having a go at might be between 10 and 100
>> times faster at compiling than gcc; but might be 20-50% slower in code
>> quality. And it will be nowhere near 99% conformance.)
>
>
> Compile times are not that much of an issue for us now, so 10 or 100
> times faster, while nice, would not really be a major consideration.
> But a 20-50% slowdown in generated code would be a pretty big hit.
My experience is very different. I use gcc and it's very slow; even
waiting 2 seconds to compile one module seems an age, and to compile
everything - I usually have to find something else to do. And when I
come back I've lost the thread of what I was in the middle of.
In short, it's a nuisance.
> OTOH, if you can keep compile times the same (or even double or triple
> them) and get a 20-50% *increase* in performance (of the compiled
> code), we'd likely be willing to sacrifice a fair bit to get that.
A 20% increase in runtime is not significant when you are developing and
building several times a minute, and testing one small aspect. But the
100-300% increase I might get with Tiny C would be (so I tend to use
that to verify something quickly).
But this 20-50% is for programs that are largely self-contained and
computationally intensive. For anything with normal I/O or that involves
graphics or user interaction, or that uses external libraries, the
differences are not significant.
------------------------------
(Case study: interpreter running jpeg decoder; all 64-bits:
Tiny C 2.8 seconds
My code 1.7 seconds
gcc -O3 1.4 seconds
My code 0.6 seconds with ASM module.
The last figure is 130% /faster/ than gcc, with one ASM module switched
in out of 28. Although not all apps can benefit in the same way as code
paths are more distributed.)
(My project is anyway rather specialised: it is a whole-project compiler
which is intended to build and run an entire application from scratch
with a barely perceptible delay. And having information about all
functions in memory at the same time, it also opens up new optimisation
possibilities.)
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-12-29 17:10 +0000 |
| Message-ID | <o43fuo$g9u$1@dont-email.me> |
| In reply to | #100471 |
On 29/12/2016 13:52, supercat@casperkitty.com wrote: > On Thursday, December 29, 2016 at 5:52:59 AM UTC-6, Bart wrote: >> (Case study: interpreter running jpeg decoder; all 64-bits: >> >> Tiny C 2.8 seconds >> My code 1.7 seconds >> gcc -O3 1.4 seconds >> My code 0.6 seconds with ASM module. >> >> The last figure is 130% /faster/ than gcc, with one ASM module switched >> in out of 28. Although not all apps can benefit in the same way as code >> paths are more distributed.) > > Many programs spend the vast majority of their time executing a small > fraction of the code. Any time the compiler spends optimizing the > remainder in anything other than resource-constrained embedded systems > will generally be wasted (space can be an issue even for code that may > have a 1% chance of executing at all in the course of a product's lifetime, > and certain rarely-taken paths may be performance critical if code needs > to meet certain timing deadlines even when they occur). > > Out of curiosity, how would Tiny C have done if you'd incorporated that > same ASM routine into it? Also, have you made any effort to write the > code in a way favorable to Tiny C? I wonder how its times would fare > then? I did do an experiment but with gcc. Thinking that a combination of ASM and fast gcc code would be even better. But the results were disappointing. Faster I think, but not enough to make it worthwhile maintaining two ASM modules (as my ABI is different from gcc's), or having a more complicated one that works on both (but which would still only work under Win64). With TCC, it would certainly have closed the gap (and might have been faster than gcc-only). But for a production version, you have to go with the fastest option. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-12-29 05:52 -0800 |
| Message-ID | <dcaabdc5-6ec2-4a47-97dd-bc0daef899fe@googlegroups.com> |
| In reply to | #100471 |
On Thursday, December 29, 2016 at 5:52:59 AM UTC-6, Bart wrote: > (Case study: interpreter running jpeg decoder; all 64-bits: > > Tiny C 2.8 seconds > My code 1.7 seconds > gcc -O3 1.4 seconds > My code 0.6 seconds with ASM module. > > The last figure is 130% /faster/ than gcc, with one ASM module switched > in out of 28. Although not all apps can benefit in the same way as code > paths are more distributed.) Many programs spend the vast majority of their time executing a small fraction of the code. Any time the compiler spends optimizing the remainder in anything other than resource-constrained embedded systems will generally be wasted (space can be an issue even for code that may have a 1% chance of executing at all in the course of a product's lifetime, and certain rarely-taken paths may be performance critical if code needs to meet certain timing deadlines even when they occur). Out of curiosity, how would Tiny C have done if you'd incorporated that same ASM routine into it? Also, have you made any effort to write the code in a way favorable to Tiny C? I wonder how its times would fare then?
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2016-12-28 19:51 -0600 |
| Message-ID | <rlq86clqjpnni50kcjot8dbhg1upqs8mjl@4ax.com> |
| In reply to | #100455 |
On Wed, 28 Dec 2016 20:46:01 +0000, BartC <bc@freeuk.com> wrote: >On 28/12/2016 20:32, Keith Thompson wrote: >> BartC <bc@freeuk.com> writes: >>> On 28/12/2016 19:52, Richard Bos wrote: >>>> BartC <bc@freeuk.com> wrote: >>>>> On 28/12/2016 18:19, Keith Thompson wrote: >>>>>> So you're going to implement a C preprocessor, but you're not interested >>>>>> in what the Standard says. Interesting choice. >>>>> >>>>> Suppose you had a choice of two compilers. They work identically except >>>>> that one reports the 0x123e+1 as an error and other doesn't. >>>>> >>>>> The one that doesn't, that doesn't quite follow the Standard 100%, is >>>>> ten times faster than the other. >>>> >>>> Suppose I had car, and a teleportation device that made my ears itch, >>>> wouldn't I prefer the teleporter to the car and disregard the itch? >>>> >>>> Suppose I had a trillion dollars, wouldn't I prefer that to the current >>>> situation? >>>> >>>> Suppose you stopped making up idiotic scenarios? >>> >>> Are you suggesting my scenario is far-fetched? >>> >>> If so, in what way? >> >> I don't believe you're serious. > >Suppose there /was/ such a choice; what would you do? > >Put another way, how much slowdown and inconvenience would you be >willing to put up with just to achieve that final 1% of conformance in >matters which are unlikely to be of any practical benefit? > >Or, if you were responsible for managing such a project and a deadline >was looming, would you be happy to put out a 99% conforming product by >that deadline, or would you spend an extra year to complete it (even >though all your customers will buy your competitors' 99% products)? > >What I'm getting at is that sometimes you have to compromise. > >(And FWIW the project I'm having a go at might be between 10 and 100 >times faster at compiling than gcc; but might be 20-50% slower in code >quality. And it will be nowhere near 99% conformance.) Compile times are not that much of an issue for us now, so 10 or 100 times faster, while nice, would not really be a major consideration. But a 20-50% slowdown in generated code would be a pretty big hit. OTOH, if you can keep compile times the same (or even double or triple them) and get a 20-50% *increase* in performance (of the compiled code), we'd likely be willing to sacrifice a fair bit to get that.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-12-29 21:09 +0000 |
| Message-ID | <o43tve$cuv$1@dont-email.me> |
| In reply to | #100455 |
On 29/12/2016 19:59, Ian Collins wrote: > On 12/30/16 01:42 AM, David Brown wrote: >> I, and many others, find a lot of other features of gcc important. In >> no particular order, and in addition to your two points, these include: >> >> * Strong compile-time checking and warnings > > Which is were gcc spends a lot of its time. I used to compare the time > gcc took to compile with the time taken by my other compiler + lint. That's great. But then you change one line of a 5000-line module, and it has to check the other 4999 lines all over again. Sometimes you're trying a hundred different things and don't want an in-depth analysis each time, and of parts that haven't changed, or you haven't revised yet. And you don't want to wade through hundreds of harmless warnings trying to find the one that's relevant. It must be like driving all the way to the big out of town supermarket to buy a pint of milk. It's a lot easier to walk down to the corner shop, even if the milk costs a bit more. I think David Brown will always drive to the supermarket! -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2016-12-30 10:15 +1300 |
| Message-ID | <eclcntFpuo9U8@mid.individual.net> |
| In reply to | #100479 |
On 12/30/16 10:09 AM, BartC wrote: > On 29/12/2016 19:59, Ian Collins wrote: >> On 12/30/16 01:42 AM, David Brown wrote: > >>> I, and many others, find a lot of other features of gcc important. In >>> no particular order, and in addition to your two points, these include: >>> >>> * Strong compile-time checking and warnings >> >> Which is were gcc spends a lot of its time. I used to compare the time >> gcc took to compile with the time taken by my other compiler + lint. > > That's great. But then you change one line of a 5000-line module, and it > has to check the other 4999 lines all over again. There's a lesson there: don't write 5000 line modules! > Sometimes you're trying a hundred different things and don't want an > in-depth analysis each time, and of parts that haven't changed, or you > haven't revised yet. And you don't want to wade through hundreds of > harmless warnings trying to find the one that's relevant. Which is one reason why I tend to develop with the other compiler (Sun cc). The Solaris kernel build process uses two passes, the compile and the lint, which could be skipped. I tend to prefer this approach, there are still things lint finds that compilers don't. -- Ian
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-12-29 13:53 -0800 |
| Message-ID | <4f03acf7-e5e0-4c71-ac69-e0e30b61ce18@googlegroups.com> |
| In reply to | #100482 |
On Thursday, December 29, 2016 at 9:15:50 PM UTC, Ian Collins wrote: > > There's a lesson there: don't write 5000 line modules! > MiniBasic is about 4000 lines. In a single C source file. It's far more useful that way, as it hangs together as people share it over the net. I actually wrote a much faster version that tokenised input, but never released it, simply because it needed a hash table and other bits of machinery for support, it was no longer user-modifiable as a simple challenge.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-12-30 12:07 +0100 |
| Message-ID | <o45f38$qo6$1@dont-email.me> |
| In reply to | #100479 |
On 29/12/16 22:09, BartC wrote: > On 29/12/2016 19:59, Ian Collins wrote: >> On 12/30/16 01:42 AM, David Brown wrote: > >>> I, and many others, find a lot of other features of gcc important. In >>> no particular order, and in addition to your two points, these include: >>> >>> * Strong compile-time checking and warnings >> >> Which is were gcc spends a lot of its time. I used to compare the time >> gcc took to compile with the time taken by my other compiler + lint. > > That's great. But then you change one line of a 5000-line module, and it > has to check the other 4999 lines all over again. First, you write code in sensible sizes. Second, you use a build system that only re-compiles what it has to - so only the file you have changed needs re-compiled. And third, so what if it takes a couple of seconds in the background for the compilation to finish? If you have a big project, you might want to separate the link stage from the compilation stages, since a big link takes time and it is often not convenient to structure your code for partial linking. But compilation of the file you are working on, while working on it, is rarely an issue. > > Sometimes you're trying a hundred different things and don't want an > in-depth analysis each time, and of parts that haven't changed, or you > haven't revised yet. And you don't want to wade through hundreds of > harmless warnings trying to find the one that's relevant. I don't have hundreds of "harmless" warnings in my projects - even though I enable a large array of warning messages (not just "-Wall -Wextra"). I don't get /any/ warning messages when I build my projects (once the mistakes are fixed, of course!). A warning message is an indication that the compiler thinks there could be differences in understanding and interpretation of the code between the writer, readers, the compiler, or perhaps the compiler with different options. To me, that means something needs to be fixed in my code. > > It must be like driving all the way to the big out of town supermarket > to buy a pint of milk. It's a lot easier to walk down to the corner > shop, even if the milk costs a bit more. > No, it is more like buying the milk at the supermarket when I am there anyway, and not treating the corner shop as ten times better than the supermarket just because it is ten times closer. > I think David Brown will always drive to the supermarket! >
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-12-30 13:04 +0000 |
| Message-ID | <o45ltq$h8n$1@dont-email.me> |
| In reply to | #100644 |
On 30/12/2016 11:07, David Brown wrote: > On 29/12/16 22:09, BartC wrote: >> On 29/12/2016 19:59, Ian Collins wrote: >>> On 12/30/16 01:42 AM, David Brown wrote: >> >>>> I, and many others, find a lot of other features of gcc important. In >>>> no particular order, and in addition to your two points, these include: >>>> >>>> * Strong compile-time checking and warnings >>> >>> Which is were gcc spends a lot of its time. I used to compare the time >>> gcc took to compile with the time taken by my other compiler + lint. >> >> That's great. But then you change one line of a 5000-line module, and it >> has to check the other 4999 lines all over again. > > First, you write code in sensible sizes. Second, you use a build system > that only re-compiles what it has to - so only the file you have changed > needs re-compiled. And third, so what if it takes a couple of seconds > in the background for the compilation to finish? > > If you have a big project, you might want to separate the link stage > from the compilation stages, since a big link takes time and it is often > not convenient to structure your code for partial linking. But > compilation of the file you are working on, while working on it, is > rarely an issue. Seems to be a lot of pandering to the compiler to me: - Having to keep file sizes small - Having to structure the project differently - Having to use an external manager smart enough to know when not to compile modules - Having to use a separate faster machine to compile on when the target would be too slow Just my view... > >> >> Sometimes you're trying a hundred different things and don't want an >> in-depth analysis each time, and of parts that haven't changed, or you >> haven't revised yet. And you don't want to wade through hundreds of >> harmless warnings trying to find the one that's relevant. > > I don't have hundreds of "harmless" warnings in my projects - even > though I enable a large array of warning messages (not just "-Wall > -Wextra"). I don't get /any/ warning messages when I build my projects > (once the mistakes are fixed, of course!). Not even 'Unused parameter'? (Which can happen if you have a suite of functions needing the same interface.) Or do you instead have to keep adding more and more options to turn those off? (No that won't work because then it can't trap a genuine case where a parameter isn't used.) When I use gcc, it keeps silent on things I /want/ it to tell me about: declarations of global names that are different across modules. Or inadvertently using what I know is a pointer to one object as a pointer to several (by using p[i] instead of *p). > A warning message is an indication that the compiler thinks there could > be differences in understanding and interpretation of the code between > the writer, readers, the compiler, or perhaps the compiler with > different options. To me, that means something needs to be fixed in my > code. You also use Python; does that give the same kinds of warnings as gcc? And if not, how do you manage? -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-12-30 05:31 -0800 |
| Message-ID | <63523d2c-a416-4603-9278-bb6bf01b1048@googlegroups.com> |
| In reply to | #100650 |
On Friday, December 30, 2016 at 1:04:27 PM UTC, Bart wrote: > > Not even 'Unused parameter'? (Which can happen if you have a suite of > functions needing the same interface.) Or do you instead have to keep > adding more and more options to turn those off? (No that won't work > because then it can't trap a genuine case where a parameter isn't used.) > > When I use gcc, it keeps silent on things I /want/ it to tell me about: > declarations of global names that are different across modules. Or > inadvertently using what I know is a pointer to one object as a pointer > to several (by using p[i] instead of *p). > The problem, as doubtless you are aware, is that warnings are things that are easy for the compiler to check, not mistakes the programmer is likely to make. They're often useful on a first pass where, for example, you might define a function with the wrong interface, taking an unnecessary flag you don't use. However it's just as likely that flag is in for later expansion. You don't want the same warning popping up. And the workarounds, like "args used" comments, are often intrusive and compiler-specific.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-12-30 15:00 +0100 |
| Message-ID | <o45p7b$soo$1@dont-email.me> |
| In reply to | #100650 |
On 30/12/16 14:04, BartC wrote:
> On 30/12/2016 11:07, David Brown wrote:
>> On 29/12/16 22:09, BartC wrote:
>>> On 29/12/2016 19:59, Ian Collins wrote:
>>>> On 12/30/16 01:42 AM, David Brown wrote:
>>>
>>>>> I, and many others, find a lot of other features of gcc important. In
>>>>> no particular order, and in addition to your two points, these
>>>>> include:
>>>>>
>>>>> * Strong compile-time checking and warnings
>>>>
>>>> Which is were gcc spends a lot of its time. I used to compare the time
>>>> gcc took to compile with the time taken by my other compiler + lint.
>>>
>>> That's great. But then you change one line of a 5000-line module, and it
>>> has to check the other 4999 lines all over again.
>>
>> First, you write code in sensible sizes. Second, you use a build system
>> that only re-compiles what it has to - so only the file you have changed
>> needs re-compiled. And third, so what if it takes a couple of seconds
>> in the background for the compilation to finish?
>>
>> If you have a big project, you might want to separate the link stage
>> from the compilation stages, since a big link takes time and it is often
>> not convenient to structure your code for partial linking. But
>> compilation of the file you are working on, while working on it, is
>> rarely an issue.
>
> Seems to be a lot of pandering to the compiler to me:
>
> - Having to keep file sizes small
That is pandering to good design, not the compiler. In a quick check of
a current project, almost all of my files are under 1000 lines, with a
couple that are between 1000 and 2000 lines (plus an automatically
generated C file that is about 6000 lines). It is about what makes
sense to the developer, and 5000 line files are rarely a good idea.
> - Having to structure the project differently
Again, that is pandering to good development style.
> - Having to use an external manager smart enough to
> know when not to compile modules
"make" has existing for about 30 years or so. It is not hard to use.
But if it is beyond you, most IDE's will do a reasonable enough job.
> - Having to use a separate faster machine to compile on
> when the target would be too slow
My targets are usually microcontrollers. It is true that a 120 MHz
processor and 256KB ram would once have been considered a powerful
workstation, but I think it is not unreasonable to do my compilation on
a PC.
And when I am working on embedded Linux systems, I prefer to use my
desktop with two big screens, plenty of horsepower for the IDE and
tools, etc., rather than a small board which may not even have a screen
connection. I really cannot see that it is a burden to type "make" in a
terminal with a shell running on my desktop, rather than typing "make"
in a terminal (on the same desktop screen) connected to the embedded
system by ssh. And since the relevant directories on the PC will be
mounted over the network on the embedded system, there is no copying of
files to be done - I just run the program directly.
>
> Just my view...
It would be better if you had an informed opinion, rather than one
created out of ignorance and misunderstanding.
>
>>
>>>
>>> Sometimes you're trying a hundred different things and don't want an
>>> in-depth analysis each time, and of parts that haven't changed, or you
>>> haven't revised yet. And you don't want to wade through hundreds of
>>> harmless warnings trying to find the one that's relevant.
>>
>> I don't have hundreds of "harmless" warnings in my projects - even
>> though I enable a large array of warning messages (not just "-Wall
>> -Wextra"). I don't get /any/ warning messages when I build my projects
>> (once the mistakes are fixed, of course!).
>
> Not even 'Unused parameter'?
int foo(int a) {
(void) a;
return 123;
}
Alternatively (though I prefer the first version) :
int foo(int a __attribute__((unused))) {
return 123;
}
(Of course, if it is not obvious why the parameter is not needed, then
there will be comments. And if it is just a temporary stub, there will
be a TODO comment.)
> (Which can happen if you have a suite of
> functions needing the same interface.) Or do you instead have to keep
> adding more and more options to turn those off? (No that won't work
> because then it can't trap a genuine case where a parameter isn't used.)
>
> When I use gcc, it keeps silent on things I /want/ it to tell me about:
> declarations of global names that are different across modules.
That can only happen if you don't use proper discipline about declaring
global names in headers and #including them in files that use them and
the file that defines them. But I believe you have made it clear before
that you don't like to use common best practices for that sort of thing.
I also use the following warnings:
-Wredundant-decls -Wmissing-declarations -Wnested-externs
-Wmissing-prototypes -Wstrict-prototypes
This means that every function must be /either/ defined as "static"
(with an optional forward declaration), /or/ declared exactly once
before the definition. By making a habit of putting all such
declarations in a header file that matches the C file, with an extern
qualifier, I am always sure that my functions are either clearly
exported from the C file, or clearly internal to it.
(Other people like to do things differently - that's the way /I/ do it
normally.)
> Or
> inadvertently using what I know is a pointer to one object as a pointer
> to several (by using p[i] instead of *p).
In C, it is common for code not to have any way of knowing if a pointer
points to one object or many. So the compiler cannot automate this kind
of checking.
However, C /does/ have a tool to help you. It is called an "identifier"
- you are allowed to give things /names/ that make it clear to the
reader and the writer what is going on. Thus you can write:
void peelGrape(grape *aGrape)
{
...
}
void squashSomeGrapes(grape *bunchOfGrapes, int noOfGrapes)
{
...
}
If you don't know what your pointers point to, then frankly, C is too
difficult a language for you.
>
>
>> A warning message is an indication that the compiler thinks there could
>> be differences in understanding and interpretation of the code between
>> the writer, readers, the compiler, or perhaps the compiler with
>> different options. To me, that means something needs to be fixed in my
>> code.
>
> You also use Python; does that give the same kinds of warnings as gcc?
> And if not, how do you manage?
>
Most of my Python code is relatively simple or does not have the same
kind of quality requirements as my C code. If I have written some test
code in Python and it has a bug, I can usually simply fix the bug and
update the test code. But if my C code is in a microcontroller that is
encased in concrete and mounted at the bottom of the ocean (yes, I have
made cards for such places), I have to do everything possible to avoid
the risk of bugs.
On larger Python programs, I really miss having such static error
checking. pylint can help, as can modern Python type annotations, but I
would think twice about using it for bigger systems. I am not sure what
the best alternative is (maybe Go, maybe modern C++, maybe Python with
stricter annotations), as the issue has not come up recently, but it is
something I would investigate before making a decision.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-12-30 15:55 +0000 |
| Message-ID | <o45vv9$mtk$1@dont-email.me> |
| In reply to | #100659 |
On 30/12/2016 14:00, David Brown wrote:
> On 30/12/16 14:04, BartC wrote:
>> Not even 'Unused parameter'?
>
> int foo(int a) {
> (void) a;
> return 123;
Ugly.
> Alternatively (though I prefer the first version) :
>
> int foo(int a __attribute__((unused))) {
I take it back, that wasn't ugly; this is! (And more pandering BTW.)
> That can only happen if you don't use proper discipline about declaring
> global names in headers and #including them in files that use them and
> the file that defines them. But I believe you have made it clear before
> that you don't like to use common best practices for that sort of thing.
Warnings are about detecting possible errors. Using best practices
doesn't preclude making mistakes.
> If you don't know what your pointers point to, then frankly, C is too
> difficult a language for you.
That's a rather snide comment. I could just as well say that if you need
a compiler with so many kinds of warnings to highlight where you've gone
wrong, then perhaps C is not for /you/!
You're picking and choosing the things that programmers could
conceivably get wrong, to conveniently match those that a compiler can
detect. But if it's something it can't detect, then the programmer must
be incompetent.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-01-01 16:00 +0100 |
| Message-ID | <o4b5fm$ul5$1@dont-email.me> |
| In reply to | #100666 |
On 30/12/16 16:55, BartC wrote:
> On 30/12/2016 14:00, David Brown wrote:
>> On 30/12/16 14:04, BartC wrote:
>
>>> Not even 'Unused parameter'?
>>
>> int foo(int a) {
>> (void) a;
>> return 123;
>
> Ugly.
It is less ugly than incorrect code - and code that does not use the
parameters is, IME at least, usually wrong or at least an indication of
inefficiency somewhere. It is not /always/ wrong, of course, but usually.
I used to use macros for this kind of thing - something like:
#define Unused(x) (void) (x)
The idea was that it would be a little more explicit than "(void) a;".
But I think the "cast to void" is clear enough, and a comment can be
used to explain the reason.
>
>> Alternatively (though I prefer the first version) :
>>
>> int foo(int a __attribute__((unused))) {
>
> I take it back, that wasn't ugly; this is! (And more pandering BTW.)
I agree that this is uglier, but it is a valid alternative.
>
>> That can only happen if you don't use proper discipline about declaring
>> global names in headers and #including them in files that use them and
>> the file that defines them. But I believe you have made it clear before
>> that you don't like to use common best practices for that sort of thing.
>
> Warnings are about detecting possible errors. Using best practices
> doesn't preclude making mistakes.
Of course it does not preclude mistakes - but it reduces the likelihood
of some kinds of mistakes, and surely that is a good thing? I find that
good use of compiler warnings pretty much eliminates almost all the
types of error that you complain about that are easy to make in C.
>
>> If you don't know what your pointers point to, then frankly, C is too
>> difficult a language for you.
>
> That's a rather snide comment. I could just as well say that if you need
> a compiler with so many kinds of warnings to highlight where you've gone
> wrong, then perhaps C is not for /you/!
Perhaps it was /too/ snide. But I really do not think it is too much to
ask that you know what your variables, parameters, etc., are doing when
you are programming.
>
> You're picking and choosing the things that programmers could
> conceivably get wrong, to conveniently match those that a compiler can
> detect. But if it's something it can't detect, then the programmer must
> be incompetent.
>
No, I am using the available tools as best I can, to reduce the risk of
errors or to enforce a style that reduces the risk. For the majority of
warnings that gcc can give me, the warnings are /never/ triggered in my
code. But I still like to keep them enabled - in effect, they become a
proof that those types of errors are not a problem.
As compilers improve, their static warnings improve - and that is a good
thing. It makes it easier to avoid or find errors. Other types of
errors can be eliminated (or nearly eliminated) by appropriate
programming discipline and habits, such as writing small functions and
keeping your local variables in small scopes to make it easy to see what
they do, or using appropriate names, identifiers, comments, and
documentation so that you know what your pointers point to before you
use them.
And of course, there are some types of errors that are harder to avoid -
few programmers are able to write perfect bug-free code on their first
drafts.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-01-02 08:33 +1300 |
| Message-ID | <ect3siFq0soU1@mid.individual.net> |
| In reply to | #100776 |
On 01/ 2/17 04:00 AM, David Brown wrote:
> On 30/12/16 16:55, BartC wrote:
>> On 30/12/2016 14:00, David Brown wrote:
>>> On 30/12/16 14:04, BartC wrote:
>>
>>>> Not even 'Unused parameter'?
>>>
>>> int foo(int a) {
>>> (void) a;
>>> return 123;
>>
>> Ugly.
>
> It is less ugly than incorrect code - and code that does not use the
> parameters is, IME at least, usually wrong or at least an indication of
> inefficiency somewhere. It is not /always/ wrong, of course, but usually.
I wonder why C hasn't adopted the simple rule from C++: if a parameter
isn't going to be used, don't give it a name.
--
Ian
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-01-02 09:02 +1300 |
| Message-ID | <ect5i5Fq0soU2@mid.individual.net> |
| In reply to | #100805 |
On 01/ 2/17 08:54 AM, Stefan Ram wrote:
> Ian Collins <ian-news@hotmail.com> writes:
>> I wonder why C hasn't adopted the simple rule from C++: if a parameter
>> isn't going to be used, don't give it a name.
>
> There's a style checker for C++ in clang, and when I write:
>
> int f( int ){}
>
> , it tells me:
>
> warning: all parameters should be named in a function
> [readability-named-parameter]
It should be telling that control reaches end of non-void function...
cat /tmp/x.cc; clang++ -c /tmp/x.cc -Wall -Wextra; clang++ --version
int f( int ) { return 0; }
void g( int ) {}
clang version 4.0.0-svn287013-1~exp1 (trunk)
--
Ian
[toc] | [prev] | [next] | [standalone]
Page 6 of 11 — ← Prev page 1 … 4 5 [6] 7 8 … 11 Next page →
Back to top | Article view | comp.lang.c
csiph-web