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 8 of 11 — ← Prev page 1 … 6 7 [8] 9 10 11 Next page →
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-12-30 22:51 +0000 |
| Message-ID | <o46oar$pdq$1@dont-email.me> |
| In reply to | #100706 |
On 30/12/2016 22:09, Ian Collins wrote: > On 12/31/16 10:50 AM, supercat@casperkitty.com wrote: >> On Friday, December 30, 2016 at 11:25:00 AM UTC-6, Ian Collins wrote: >>> On 12/31/16 02:04 AM, BartC wrote: >>>> Seems to be a lot of pandering to the compiler to me: >>>> >>>> - Having to keep file sizes small >>> >>> Pandering to good design. >> >> There is a lot to be said for being able to simply feed a single file >> to a >> compiler and hit "go", without having to configure projects, make >> files, or >> anything else, especially if a compiler is fast enough that executable >> files >> can be considered "disposable". > > There's a nothing good to be said about having to merge several other > people's changes with yours in said single file... You have 40 people all contributing to the same executable? Who gets to run it? -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-12-30 15:20 -0800 |
| Message-ID | <10de4006-5f84-4279-a8af-ac1337c8bfb5@googlegroups.com> |
| In reply to | #100712 |
On Friday, December 30, 2016 at 4:51:40 PM UTC-6, Bart wrote: > You have 40 people all contributing to the same executable? > > Who gets to run it? At any point in time, person A will be running the combination of the newest version of his module and some slightly-older versions of B's and C's modules. Person B will be running the combination of the newest version of his module and some version of A's and C's modules. Person C will be running the combination of the newest version of his module and and some version of A's and B's code. Combining the newest version of A's, B's, and C's modules will be fairly easy (just put all the files in the right place and hit go), and with luck everything will work perfectly. Splitting off parts of a program that are genuinely independent is useful. Things get problematical if two parts each require incompatible versions of a third. If the ways in which the two parts use the third are independent of each other, having each part include its own preferred version of the third might not be space-efficient, but it may avoid a lot of compatibility problems.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2016-12-31 12:34 +1300 |
| Message-ID | <eco97aFq02kU2@mid.individual.net> |
| In reply to | #100713 |
On 12/31/16 12:20 PM, supercat@casperkitty.com wrote: > On Friday, December 30, 2016 at 4:51:40 PM UTC-6, Bart wrote: >> You have 40 people all contributing to the same executable? >> >> Who gets to run it? For some reason this post didn't show up for me.. Everyone, including the build machines gets to run it! -- Ian
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-12-30 23:40 +0000 |
| Message-ID | <o46r6s$6tf$1@dont-email.me> |
| In reply to | #100713 |
On 30/12/2016 23:20, supercat@casperkitty.com wrote: > On Friday, December 30, 2016 at 4:51:40 PM UTC-6, Bart wrote: >> You have 40 people all contributing to the same executable? >> >> Who gets to run it? > > At any point in time, person A will be running the combination of the > newest version of his module and some slightly-older versions of B's > and C's modules. Person B will be running the combination of the > newest version of his module and some version of A's and C's modules. > Person C will be running the combination of the newest version of his > module and and some version of A's and B's code. > > Combining the newest version of A's, B's, and C's modules will be fairly > easy (just put all the files in the right place and hit go), and with > luck everything will work perfectly. > > Splitting off parts of a program that are genuinely independent is useful. > Things get problematical if two parts each require incompatible versions of > a third. If the ways in which the two parts use the third are independent > of each other, having each part include its own preferred version of the > third might not be space-efficient, but it may avoid a lot of compatibility > problems. This sounds a bit like the problems I've had with hierarchical import modules [not in C]. If A imports B and C, and B imports C, everything is fine. C can be developed independently (or by someone else, or it can be accessed as a binary file in a dynamic library so does not even need recompiling). Until C needs to import something from A or B. (I've found a way of solving this, but it needs all A, B and C to be compiled together. Hence the need for speed.) But ideally a project is split into separate areas with clear demarcations. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-12-30 22:12 +0000 |
| Message-ID | <o46m2h$hbt$2@dont-email.me> |
| In reply to | #100702 |
On 30/12/2016 21:50, supercat@casperkitty.com wrote: > On Friday, December 30, 2016 at 11:25:00 AM UTC-6, Ian Collins wrote: >> On 12/31/16 02:04 AM, BartC wrote: >>> Seems to be a lot of pandering to the compiler to me: >>> >>> - Having to keep file sizes small >> >> Pandering to good design. > > There is a lot to be said for being able to simply feed a single file to a > compiler and hit "go", without having to configure projects, make files, or > anything else, especially if a compiler is fast enough that executable files > can be considered "disposable". > Finally somebody gets it.
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2016-12-28 21:38 +0000 |
| Message-ID | <5864306d.21892234@news.xs4all.nl> |
| In reply to | #100455 |
BartC <bc@freeuk.com> wrote: > On 28/12/2016 20:55, Richard Bos wrote: > > BartC <bc@freeuk.com> wrote: > > >> Suppose there /was/ such a choice; what would you do? > > > > Suppose there were a choice for you to stop trolling, would you? > > > > Evidently not. > > Um, YOU'RE the one who brought up teleportation and trillions of dollars. > > *I'M* talking about compromises between C compilers and how much it is > worth detecting a very unlikely construct. No, you're talking about magic 900% increases in efficiency. You're making random "statistics" up for the sake of getting people to disagree with you; i.o.w., you're trolling. Richard
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-12-29 12:04 +0000 |
| Message-ID | <o42u2a$f8e$1@dont-email.me> |
| In reply to | #100484 |
On 29/12/2016 11:27, David Brown wrote: > On 28/12/16 23:09, BartC wrote: >> So compilers can certainly be considerably faster then gcc (although >> it's unlikely that gcc's sluggishness is entirely due to its rigid >> adherence to the Standard; more it's size and structure.). > > So you don't think it could be anything to do with the vast array of > features that gcc has, or its flexibility? There is a great deal more > to a compiler than just the number of lines it chews through per second, > or the run-time speed of a few sample programs on a single sample computer. I don't care for that vast array of features. I'm only interested in two: * The speed of its generated code * And that gcc is available everywhere and is stable and well-tested When I write portable C code, I would rather not have to stipulate a compiler, so would avoid relying on special features only available in gcc, or depending on attributes and pragmas only available in gcc, or having a successful build conditional on compile options only available with gcc. (Wouldn't it be funny if the slow speed of gcc was simply due to someone forgetting to turn on optimisation when compiling it! As it would mean that those defending its speed because it does X, Y and Z are just speculating, and in reality don't actually know.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-12-29 13:42 +0100 |
| Message-ID | <o4309h$mk0$1@dont-email.me> |
| In reply to | #100486 |
On 29/12/16 13:04, BartC wrote:
> On 29/12/2016 11:27, David Brown wrote:
>> On 28/12/16 23:09, BartC wrote:
>
>>> So compilers can certainly be considerably faster then gcc (although
>>> it's unlikely that gcc's sluggishness is entirely due to its rigid
>>> adherence to the Standard; more it's size and structure.).
>>
>> So you don't think it could be anything to do with the vast array of
>> features that gcc has, or its flexibility? There is a great deal more
>> to a compiler than just the number of lines it chews through per second,
>> or the run-time speed of a few sample programs on a single sample
>> computer.
>
> I don't care for that vast array of features. I'm only interested in two:
>
> * The speed of its generated code
> * And that gcc is available everywhere and is stable and well-tested
>
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
* Support for the latest standards
* Support for C and C++
* Many useful extensions and added features
* Strong debugging support
* Support for run-time checks ("sanitizers")
* Support for a wide range of target processors
* Powerful inline assembly
* Supported as /the/ standard compiler by many microcontroller manufacturers
* Part of a solid toolchain and development environment
* Works on both Linux and Windows
Different people have different needs from their toolchains. And if you
have very limited needs, it might be annoying to have to "pay" in speed
and size for features you don't want. But I think most programmers look
for more from their compilers than just the speed of compiling a single
test program. That is why TCC is an interesting tool, and is used in
some niches where minimal compiler size is important, but it is not
viewed as a mainstream C compiler for normal usage, and it is certainly
not a realistic alternative to gcc for most people.
> When I write portable C code, I would rather not have to stipulate a
> compiler, so would avoid relying on special features only available in
> gcc, or depending on attributes and pragmas only available in gcc, or
> having a successful build conditional on compile options only available
> with gcc.
>
> (Wouldn't it be funny if the slow speed of gcc was simply due to someone
> forgetting to turn on optimisation when compiling it! As it would mean
> that those defending its speed because it does X, Y and Z are just
> speculating, and in reality don't actually know.)
>
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2016-12-30 08:59 +1300 |
| Message-ID | <ecl88tFpuo9U2@mid.individual.net> |
| In reply to | #100528 |
On 12/30/16 01:42 AM, David Brown wrote: > On 29/12/16 13:04, BartC wrote: >> On 29/12/2016 11:27, David Brown wrote: >>> On 28/12/16 23:09, BartC wrote: >> >>>> So compilers can certainly be considerably faster then gcc (although >>>> it's unlikely that gcc's sluggishness is entirely due to its rigid >>>> adherence to the Standard; more it's size and structure.). >>> >>> So you don't think it could be anything to do with the vast array of >>> features that gcc has, or its flexibility? There is a great deal more >>> to a compiler than just the number of lines it chews through per second, >>> or the run-time speed of a few sample programs on a single sample >>> computer. >> >> I don't care for that vast array of features. I'm only interested in two: >> >> * The speed of its generated code >> * And that gcc is available everywhere and is stable and well-tested >> > > 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. -- Ian
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-12-29 12:23 -0800 |
| Message-ID | <eeacfd18-db63-46ed-9658-e4b1b4460b3a@googlegroups.com> |
| In reply to | #100600 |
On Thursday, December 29, 2016 at 1:59:33 PM UTC-6, Ian Collins wrote: > 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. Having a compiler perform cheap forms of semantic analysis and give warnings associated with them on every build cycle makes sense. Having to repeat expensive forms of semantic analysis on every build cycle would seem to make far less sense. Only a small fraction of the semantic inferences a compiler might make while looking through code end up facilitating any useful optimizations. Rather than having a compiler perform its full semantic analysis every time it is run, it would seem more helpful to instead have a tool which could be run less frequently, and which could say "It seems as though this variable is probably never going to exceed 19531 here, and if a compiler could assume that it would allow for some useful optimization." and then offer an easy means of inserting directives to either say "The compiler may assume this variable is less than 19531" or "This variable might be greater than 19531 and the compiler must not assume otherwise" [the latter would serve both as human-readable documentation and as of a way of declining the suggestion]. A tool which suggested places to invite inferences would not need to limit itself to optimizations which the Standard would allow even without explicit invitations. Compilers which focus their optimizations efforts on places where they have been explicitly invented could be more effective and yet also faster, since they wouldn't have to waste time on parts of the semantic analysis that don't end up being useful.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-12-30 10:56 +0100 |
| Message-ID | <o45at5$dct$1@dont-email.me> |
| In reply to | #100615 |
On 29/12/16 21:23, supercat@casperkitty.com wrote: > On Thursday, December 29, 2016 at 1:59:33 PM UTC-6, Ian Collins wrote: >> 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. > > Having a compiler perform cheap forms of semantic analysis and give warnings > associated with them on every build cycle makes sense. Having to repeat > expensive forms of semantic analysis on every build cycle would seem to make > far less sense. For themajority of the times I type "make" (or press the shortcut key in my IDE), I am interested primarily in the semantic analysis. Actual code generation is only needed when I want to check the quality of the output by reading the assembly, when I want to checking things like code sizes, and when I want to try running the latest code. Since I would much rather catch mistakes at compile time than run-time, I run static analysis builds on a regular basis while programming, even when the code is far from ready to run on the target. > > Only a small fraction of the semantic inferences a compiler might make while > looking through code end up facilitating any useful optimizations. It is not about optimisation. It is about helping the developer write correct code.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-12-28 22:09 +0000 |
| Message-ID | <o41d3c$e4u$1@dont-email.me> |
| In reply to | #100484 |
On 28/12/2016 21:38, Richard Bos wrote: > BartC <bc@freeuk.com> wrote: > >> On 28/12/2016 20:55, Richard Bos wrote: >>> BartC <bc@freeuk.com> wrote: >> >>>> Suppose there /was/ such a choice; what would you do? >>> >>> Suppose there were a choice for you to stop trolling, would you? >>> >>> Evidently not. >> >> Um, YOU'RE the one who brought up teleportation and trillions of dollars. >> >> *I'M* talking about compromises between C compilers and how much it is >> worth detecting a very unlikely construct. > > No, you're talking about magic 900% increases in efficiency. You're > making random "statistics" up for the sake of getting people to disagree > with you; i.o.w., you're trolling. Not at all. On my machine gcc seems to work at somewhere between 3K and 12Klps (lines per second). On the same machine Tiny C compiles at somewhere north of 100Klps (a long way north). The factor is easily 10x or more. But here the compromise is related to the poor quality code of TCC (I've no idea about its conformance). So compilers can certainly be considerably faster then gcc (although it's unlikely that gcc's sluggishness is entirely due to its rigid adherence to the Standard; more it's size and structure.). (Earlier this year I was working on fast 2-pass byte-code compilers (I clocked one at up to 1.4Mlps). I'm now looking at whether I can apply similar techniques to a 3/4-pass version that can compile C source code. If anything, that 900% increase -- from gcc's speed -- is conservative! But the first consideration is whether it can compile my C programs at all; adherence to the minutiae of the Standard can come later, if it doesn't impact on throughput too much.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-12-29 12:27 +0100 |
| Message-ID | <o42rrr$85s$1@dont-email.me> |
| In reply to | #100516 |
On 28/12/16 23:09, BartC wrote: > On 28/12/2016 21:38, Richard Bos wrote: >> BartC <bc@freeuk.com> wrote: >> >>> On 28/12/2016 20:55, Richard Bos wrote: >>>> BartC <bc@freeuk.com> wrote: >>> >>>>> Suppose there /was/ such a choice; what would you do? >>>> >>>> Suppose there were a choice for you to stop trolling, would you? >>>> >>>> Evidently not. >>> >>> Um, YOU'RE the one who brought up teleportation and trillions of >>> dollars. >>> >>> *I'M* talking about compromises between C compilers and how much it is >>> worth detecting a very unlikely construct. >> >> No, you're talking about magic 900% increases in efficiency. You're >> making random "statistics" up for the sake of getting people to disagree >> with you; i.o.w., you're trolling. > > Not at all. > > On my machine gcc seems to work at somewhere between 3K and 12Klps > (lines per second). On the same machine Tiny C compiles at somewhere > north of 100Klps (a long way north). The factor is easily 10x or more. > > But here the compromise is related to the poor quality code of TCC (I've > no idea about its conformance). > > So compilers can certainly be considerably faster then gcc (although > it's unlikely that gcc's sluggishness is entirely due to its rigid > adherence to the Standard; more it's size and structure.). So you don't think it could be anything to do with the vast array of features that gcc has, or its flexibility? There is a great deal more to a compiler than just the number of lines it chews through per second, or the run-time speed of a few sample programs on a single sample computer.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-12-28 21:18 +0000 |
| Message-ID | <o41a4f$3gt$1@dont-email.me> |
| In reply to | #100455 |
On 28/12/2016 20:55, Richard Bos wrote: > BartC <bc@freeuk.com> wrote: > >> Suppose there /was/ such a choice; what would you do? > > Suppose there were a choice for you to stop trolling, would you? > > Evidently not. Um, YOU'RE the one who brought up teleportation and trillions of dollars. *I'M* talking about compromises between C compilers and how much it is worth detecting a very unlikely construct. Which one of us is the troll? -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-12-28 20:46 +0000 |
| Message-ID | <o4187g$rqe$1@dont-email.me> |
| In reply to | #100455 |
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.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2016-12-28 20:55 +0000 |
| Message-ID | <58642673.19338234@news.xs4all.nl> |
| In reply to | #100489 |
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: > >>>> 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? Suppose there were a choice for you to stop trolling, would you? Evidently not. Richard
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2016-12-28 14:54 -0600 |
| Message-ID | <1j986c1aapj7eofesba9js5q5cr0qiva0l@4ax.com> |
| In reply to | #100455 |
On Wed, 28 Dec 2016 19:52:31 GMT, raltbos@xs4all.nl (Richard Bos) wrote: >BartC <bc@freeuk.com> wrote: > >> On 28/12/2016 18:19, Keith Thompson wrote: >> > BartC <bc@freeuk.com> writes: >> >> >> But there is no way my pp would generate "+++" and then "++","+" from >> >> that example, no matter what the Standard says! Nor "0x123E+3" as a >> >> single token.) >> > >> > 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? If you had a teleporter *and* a trillion dollars, you could hire someone to scratch your ears.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-12-29 15:44 +0000 |
| Message-ID | <o43auh$s4s$1@dont-email.me> |
| In reply to | #100455 |
On 29/12/2016 13:45, Richard Heathfield wrote: > On 28/12/16 20:32, Keith Thompson wrote: >> BartC <bc@freeuk.com> writes: >>> On 28/12/2016 19:52, Richard Bos wrote: > <snip> >>>> >>>> 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. > > Then for pity's sake killfile him. Then maybe we can restore a little > sanity to this newsgroup. And a happy new year to you too.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-12-28 19:39 +0000 |
| Message-ID | <o414ad$d91$1@dont-email.me> |
| In reply to | #100455 |
On 28/12/2016 18:19, Keith Thompson wrote: > BartC <bc@freeuk.com> writes: >> But there is no way my pp would generate "+++" and then "++","+" from >> that example, no matter what the Standard says! Nor "0x123E+3" as a >> single token.) > > 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. Would you just dismiss the non-conforming one because it's fractionally off full conformance? Or would you just say the hell with it? (And double your productivity.) After all you can always run your code through the other compiler when it's complete. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2016-12-28 15:04 -0600 |
| Message-ID | <ek986ch5resi9brmpul6568guhnd1478vj@4ax.com> |
| In reply to | #100525 |
On Wed, 28 Dec 2016 19:39:18 +0000, BartC <bc@freeuk.com> wrote: >On 28/12/2016 18:19, Keith Thompson wrote: >> BartC <bc@freeuk.com> writes: > >>> But there is no way my pp would generate "+++" and then "++","+" from >>> that example, no matter what the Standard says! Nor "0x123E+3" as a >>> single token.) >> >> 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. > >Would you just dismiss the non-conforming one because it's fractionally >off full conformance? Or would you just say the hell with it? (And >double your productivity.) After all you can always run your code >through the other compiler when it's complete. On the assumption that all compilers have bugs, I'd treat the later compiler (all other things being equal) as just having one additional bug in a somewhat obscure corner. In practice, should I find that bug, I'd expect the vendor to acknowledge it. I could see the vendor assigning a really low priority to fixing it (it's rather obscure, after all, and it's trivially easy to work around, *without* introducing any portability problems), but I do expect them to accept that it's incorrect behavior. I can even live with the vendor saying, "yeah, it's a problem, but it's going to take a while to fix it because..." (consider MS's issue with two-phase lookup in C++). OTOH, I would be more than a bit put off and concerned if the vendor's response was, "the standard is stupid, I did it my way". After all, the vendor has probably said somewhere that they've implemented a C compiler conforming to some version of the C standard. "Conforming to the standard except when I didn't like it" isn't really comforting.
[toc] | [prev] | [next] | [standalone]
Page 8 of 11 — ← Prev page 1 … 6 7 [8] 9 10 11 Next page →
Back to top | Article view | comp.lang.c
csiph-web