Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #106884 > unrolled thread
| Started by | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| First post | 2017-03-24 11:25 +0100 |
| Last post | 2017-03-30 00:50 -0700 |
| Articles | 20 on this page of 287 — 34 participants |
Back to article view | Back to comp.lang.c
Even more problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-24 11:25 +0100
Re: Even more problems with lcc-win BartC <bc@freeuk.com> - 2017-03-24 11:04 +0000
Re: Even more problems with lcc-win Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-03-24 11:44 +0000
Re: Even more problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-24 12:59 +0100
Re: Even more problems with lcc-win Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-03-24 14:06 +0000
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-24 13:01 +0100
Re: Even more problems with lcc-win BartC <bc@freeuk.com> - 2017-03-24 12:39 +0000
Re: Even more problems with lcc-win scott@slp53.sl.home (Scott Lurndal) - 2017-03-24 13:17 +0000
Re: Even more problems with lcc-win BartC <bc@freeuk.com> - 2017-03-24 13:38 +0000
Re: Even more problems with lcc-win scott@slp53.sl.home (Scott Lurndal) - 2017-03-24 13:50 +0000
Re: Even more problems with lcc-win BartC <bc@freeuk.com> - 2017-03-24 14:06 +0000
Re: Even more problems with lcc-win scott@slp53.sl.home (Scott Lurndal) - 2017-03-24 14:20 +0000
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-24 15:49 +0100
Re: Even more problems with lcc-win Gareth Owen <gwowen@gmail.com> - 2017-03-24 16:35 +0000
Re: Even more problems with lcc-win BartC <bc@freeuk.com> - 2017-03-24 14:51 +0000
Re: Even more problems with lcc-win Noob <root@127.0.0.1> - 2017-03-24 23:36 +0100
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-24 15:43 +0100
Re: Even more problems with lcc-win BartC <bc@freeuk.com> - 2017-03-24 17:57 +0000
Re: Even more problems with lcc-win scott@slp53.sl.home (Scott Lurndal) - 2017-03-24 18:13 +0000
Re: Even more problems with lcc-win Richard Heathfield <rjh@cpax.org.uk> - 2017-03-24 18:32 +0000
Re: Even more problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-03-24 12:11 -0700
Re: Even more problems with lcc-win BartC <bc@freeuk.com> - 2017-03-24 19:56 +0000
Re: Even more problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-03-24 13:48 -0700
Re: Even more problems with lcc-win BartC <bc@freeuk.com> - 2017-03-24 21:17 +0000
Re: Even more problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-24 22:40 +0100
Re: Even more problems with lcc-win BartC <bc@freeuk.com> - 2017-03-24 21:56 +0000
Re: Even more problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-25 01:14 +0100
Re: Even more problems with lcc-win BartC <bc@freeuk.com> - 2017-03-25 01:19 +0000
Re: Even more problems with lcc-win BartC <bc@freeuk.com> - 2017-03-25 01:30 +0000
Re: Even more problems with lcc-win supercat@casperkitty.com - 2017-03-25 12:46 -0700
Re: Even more problems with lcc-win BartC <bc@freeuk.com> - 2017-03-25 20:10 +0000
Re: Even more problems with lcc-win gordonb.l3ybu@burditt.org (Gordon Burditt) - 2017-03-27 03:34 -0500
Re: Even more problems with lcc-win BartC <bc@freeuk.com> - 2017-03-27 11:41 +0100
Re: Even more problems with lcc-win gordonb.15yss@burditt.org (Gordon Burditt) - 2017-03-27 14:48 -0500
Re: Even more problems with lcc-win supercat@casperkitty.com - 2017-03-27 13:31 -0700
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-03-27 22:22 +0100
Re: Even more problems with lcc-win supercat@casperkitty.com - 2017-03-27 15:05 -0700
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-03-27 23:22 +0100
Re: Even more problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-28 00:35 +0200
Re: Even more problems with lcc-win Tim Rentsch <txr@alumni.caltech.edu> - 2017-04-16 19:09 -0700
Re: Even more problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-04-21 21:01 +0200
Re: Even more problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-04-21 12:33 -0700
Re: Even more problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-04-21 21:44 +0200
Re: Even more problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-04-21 13:37 -0700
Re: Even more problems with lcc-win Tim Rentsch <txr@alumni.caltech.edu> - 2017-04-27 13:03 -0700
Re: Even more problems with lcc-win supercat@casperkitty.com - 2017-04-21 13:15 -0700
Re: Even more problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-04-21 13:35 -0700
Re: Even more problems with lcc-win supercat@casperkitty.com - 2017-04-21 15:30 -0700
Re: Even more problems with lcc-win Robert Wessel <robertwessel2@yahoo.com> - 2017-04-21 18:44 -0500
Re: Even more problems with lcc-win raltbos@xs4all.nl (Richard Bos) - 2017-04-22 21:08 +0000
Re: Even more problems with lcc-win supercat@casperkitty.com - 2017-04-23 10:26 -0700
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-04-23 19:08 +0100
Re: Even more problems with lcc-win supercat@casperkitty.com - 2017-04-23 14:26 -0700
Re: Even more problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-04-23 16:52 -0700
Re: Even more problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-04-23 16:31 -0700
Re: Even more problems with lcc-win supercat@casperkitty.com - 2017-04-23 20:42 -0700
Re: Even more problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-04-23 22:32 -0700
Re: Even more problems with lcc-win scott@slp53.sl.home (Scott Lurndal) - 2017-04-24 13:37 +0000
Re: Even more problems with lcc-win Tim Rentsch <txr@alumni.caltech.edu> - 2017-04-27 07:13 -0700
Re: Even more problems with lcc-win supercat@casperkitty.com - 2017-04-27 07:54 -0700
Re: Even more problems with lcc-win Robert Wessel <robertwessel2@yahoo.com> - 2017-04-27 18:20 -0500
Re: Even more problems with lcc-win Tim Rentsch <txr@alumni.caltech.edu> - 2017-04-30 14:23 -0700
Re: Even more problems with lcc-win supercat@casperkitty.com - 2017-04-30 18:18 -0700
Re: Even more problems with lcc-win Robert Wessel <robertwessel2@yahoo.com> - 2017-05-01 12:12 -0500
Re: Even more problems with lcc-win supercat@casperkitty.com - 2017-05-01 11:14 -0700
Re: Even more problems with lcc-win Robert Wessel <robertwessel2@yahoo.com> - 2017-05-01 13:29 -0500
Re: Even more problems with lcc-win supercat@casperkitty.com - 2017-03-27 16:00 -0700
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-03-28 13:24 +0100
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-28 15:20 +0200
Re: Even more problems with lcc-win BartC <bc@freeuk.com> - 2017-03-28 16:50 +0100
Re: Even more problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-03-28 09:28 -0700
Re: Even more problems with lcc-win BartC <bc@freeuk.com> - 2017-03-28 19:45 +0100
Re: Even more problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-03-28 12:06 -0700
Re: Even more problems with lcc-win Richard Heathfield <rjh@cpax.org.uk> - 2017-03-28 20:14 +0100
Re: Even more problems with lcc-win BartC <bc@freeuk.com> - 2017-03-28 20:24 +0100
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-28 21:33 +0200
Re: Even more problems with lcc-win supercat@casperkitty.com - 2017-03-28 13:10 -0700
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-28 22:15 +0200
Re: Even more problems with lcc-win scott@slp53.sl.home (Scott Lurndal) - 2017-03-29 13:23 +0000
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-28 21:29 +0200
Re: Even more problems with lcc-win BartC <bc@freeuk.com> - 2017-03-28 20:47 +0100
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-28 22:46 +0200
Re: Even more problems with lcc-win BartC <bc@freeuk.com> - 2017-03-28 23:46 +0100
Re: Even more problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-29 00:53 +0200
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-03-29 02:00 +0100
Re: Even more problems with lcc-win mertesthomas@gmail.com - 2017-03-29 05:05 -0700
Re: Even more problems with lcc-win "James R. Kuyper" <jameskuyper@verizon.net> - 2017-03-29 10:57 -0400
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-29 17:06 +0200
Re: Even more problems with lcc-win mertesthomas@gmail.com - 2017-03-29 08:39 -0700
Re: Even more problems with lcc-win Gareth Owen <gwowen@gmail.com> - 2017-03-30 18:29 +0100
Re: Even more problems with lcc-win supercat@casperkitty.com - 2017-03-28 23:44 -0700
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-03-29 12:33 +0100
Re: Even more problems with lcc-win supercat@casperkitty.com - 2017-03-29 08:54 -0700
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-03-29 17:38 +0100
Re: Even more problems with lcc-win scott@slp53.sl.home (Scott Lurndal) - 2017-03-29 16:42 +0000
Re: Even more problems with lcc-win supercat@casperkitty.com - 2017-03-29 10:28 -0700
Re: Even more problems with lcc-win scott@slp53.sl.home (Scott Lurndal) - 2017-03-29 20:09 +0000
Re: Even more problems with lcc-win supercat@casperkitty.com - 2017-03-29 13:29 -0700
Re: Even more problems with lcc-win scott@slp53.sl.home (Scott Lurndal) - 2017-03-30 13:18 +0000
Re: Even more problems with lcc-win supercat@casperkitty.com - 2017-03-30 08:22 -0700
Re: Even more problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-30 00:20 +0200
Re: Even more problems with lcc-win supercat@casperkitty.com - 2017-03-29 15:38 -0700
Re: Even more problems with lcc-win scott@slp53.sl.home (Scott Lurndal) - 2017-03-30 13:19 +0000
Re: Even more problems with lcc-win Robert Wessel <robertwessel2@yahoo.com> - 2017-03-28 18:29 -0500
Re: Even more problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-29 01:36 +0200
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-29 22:36 +0200
Re: Even more problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-29 23:50 +0200
Re: Even more problems with lcc-win Ian Collins <ian-news@hotmail.com> - 2017-03-30 10:57 +1300
Re: Even more problems with lcc-win David Kleinecke <dkleinecke@gmail.com> - 2017-03-29 15:10 -0700
Re: Even more problems with lcc-win Ian Collins <ian-news@hotmail.com> - 2017-03-30 11:15 +1300
Re: Even more problems with lcc-win David Kleinecke <dkleinecke@gmail.com> - 2017-03-30 09:22 -0700
Re: Even more problems with lcc-win GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-03-30 18:50 +0200
Re: Even more problems with lcc-win David Kleinecke <dkleinecke@gmail.com> - 2017-03-31 09:31 -0700
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-30 10:26 +0200
Re: Even more problems with lcc-win scott@slp53.sl.home (Scott Lurndal) - 2017-03-30 13:23 +0000
Re: Even more problems with lcc-win Robert Wessel <robertwessel2@yahoo.com> - 2017-03-30 12:01 -0500
Re: Even more problems with lcc-win raltbos@xs4all.nl (Richard Bos) - 2017-04-02 13:51 +0000
Re: Even more problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-04-02 23:04 +0200
Re: Even more problems with lcc-win raltbos@xs4all.nl (Richard Bos) - 2017-04-03 17:45 +0000
Re: Even more problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-04-03 22:09 +0200
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-03-29 23:24 +0100
Re: Even more problems with lcc-win supercat@casperkitty.com - 2017-03-29 15:52 -0700
Re: Even more problems with lcc-win Ian Collins <ian-news@hotmail.com> - 2017-03-30 12:26 +1300
Re: Even more problems with lcc-win GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-03-30 12:00 +0200
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-30 12:43 +0200
Re: Even more problems with lcc-win GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-03-30 13:38 +0200
Re: Even more problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-30 14:21 +0200
Re: Even more problems with lcc-win antispam@math.uni.wroc.pl - 2017-03-31 04:30 +0000
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-31 09:39 +0200
Re: Even more problems with lcc-win jadill33@gmail.com - 2017-03-30 07:12 -0700
Re: Even more problems with lcc-win Robert Wessel <robertwessel2@yahoo.com> - 2017-03-30 12:10 -0500
Re: Even more problems with lcc-win scott@slp53.sl.home (Scott Lurndal) - 2017-03-29 13:25 +0000
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-03-29 14:55 +0100
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-29 16:11 +0200
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-03-29 16:40 +0100
Re: Even more problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-29 18:14 +0200
Re: Even more problems with lcc-win Gareth Owen <gwowen@gmail.com> - 2017-03-30 18:32 +0100
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-03-30 20:53 +0100
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-04-21 00:36 +0100
Re: Even more problems with lcc-win Thiago Adams <thiago.adams@gmail.com> - 2017-04-24 05:41 -0700
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-04-24 15:14 +0100
Re: Even more problems with lcc-win antispam@math.uni.wroc.pl - 2017-04-26 14:02 +0000
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-04-26 16:04 +0100
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-04-27 12:24 +0100
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-04-27 14:43 +0100
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-29 23:21 +0200
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-03-29 23:58 +0100
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-30 11:10 +0200
Re: Even more problems with lcc-win antispam@math.uni.wroc.pl - 2017-03-30 00:09 +0000
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-03-30 01:51 +0100
Re: Even more problems with lcc-win antispam@math.uni.wroc.pl - 2017-03-30 01:58 +0000
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-03-30 12:24 +0100
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-30 14:29 +0200
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-03-30 14:36 +0100
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-30 16:23 +0200
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-04-01 11:59 +0100
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-04-01 14:41 +0100
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-04-03 11:08 +0200
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-04-03 12:02 +0100
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-04-03 14:32 +0200
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-04-03 14:40 +0100
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-04-03 16:47 +0200
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-04-07 16:56 +0100
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-04-07 18:06 +0100
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-04-07 20:02 +0200
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-04-07 19:49 +0100
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-04-08 13:26 +0200
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-04-08 13:33 +0100
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-04-08 16:27 +0200
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-04-08 22:28 +0100
Re: Even more problems with lcc-win Ian Collins <ian-news@hotmail.com> - 2017-04-09 13:54 +1200
Re: Even more problems with lcc-win Gareth Owen <gwowen@gmail.com> - 2017-04-09 07:55 +0100
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-04-09 10:24 +0100
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-04-09 10:45 +0100
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-04-09 10:53 +0100
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-04-09 14:03 +0200
Re: Even more problems with lcc-win supercat@casperkitty.com - 2017-04-10 16:17 -0700
Re: Even more problems with lcc-win raltbos@xs4all.nl (Richard Bos) - 2017-04-14 10:24 +0000
Re: Even more problems with lcc-win supercat@casperkitty.com - 2017-04-14 12:29 -0700
Re: Even more problems with lcc-win raltbos@xs4all.nl (Richard Bos) - 2017-04-09 13:04 +0000
Re: Even more problems with lcc-win Gareth Owen <gwowen@gmail.com> - 2017-04-08 14:13 +0100
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-04-08 14:33 +0100
Re: Even more problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-04-08 07:36 +0200
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-04-08 10:22 +0100
Re: Even more problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-04-07 11:11 -0700
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-04-07 19:28 +0100
Re: Even more problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-04-07 11:44 -0700
Re: Even more problems with lcc-win jameskuyper@verizon.net - 2017-04-08 08:00 -0700
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-04-07 12:29 +0100
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-04-07 13:46 +0200
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-04-07 14:10 +0100
Re: Even more problems with lcc-win antispam@math.uni.wroc.pl - 2017-03-30 21:59 +0000
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-03-31 00:19 +0100
Re: Even more problems with lcc-win me <crisdunbar@gmail.com> - 2017-03-30 17:53 -0700
Re: Even more problems with lcc-win GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-03-31 11:34 +0200
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-30 12:35 +0200
Re: Even more problems with lcc-win mertesthomas@gmail.com - 2017-03-30 04:38 -0700
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-03-30 13:14 +0100
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-30 14:38 +0200
Re: Even more problems with lcc-win Ian Collins <ian-news@hotmail.com> - 2017-03-31 08:52 +1300
Re: Even more problems with lcc-win raltbos@xs4all.nl (Richard Bos) - 2017-04-02 13:58 +0000
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-04-02 17:02 +0200
Re: Even more problems with lcc-win raltbos@xs4all.nl (Richard Bos) - 2017-04-03 17:50 +0000
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-04-03 23:10 +0200
Re: Even more problems with lcc-win Ian Collins <ian-news@hotmail.com> - 2017-04-03 07:20 +1200
Optimized? (Was: Even more problems with lcc-win) gazelle@shell.xmission.com (Kenny McCormack) - 2017-04-02 19:39 +0000
Re: Even more problems with lcc-win "James R. Kuyper" <jameskuyper@verizon.net> - 2017-04-02 15:59 -0400
Re: Even more problems with lcc-win supercat@casperkitty.com - 2017-04-02 14:11 -0700
Re: Even more problems with lcc-win Ian Collins <ian-news@hotmail.com> - 2017-04-03 17:08 +1200
Re: Even more problems with lcc-win scott@slp53.sl.home (Scott Lurndal) - 2017-04-03 13:42 +0000
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-03-30 13:06 +0100
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-30 14:58 +0200
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-03-30 14:50 +0100
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-30 16:27 +0200
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-03-30 16:57 +0100
Re: Even more problems with lcc-win mertesthomas@gmail.com - 2017-03-30 14:31 -0700
Re: Even more problems with lcc-win Robert Wessel <robertwessel2@yahoo.com> - 2017-03-28 15:54 -0500
Re: Even more problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-03-28 08:07 -0700
Re: Even more problems with lcc-win gordonb.uls6t@burditt.org (Gordon Burditt) - 2017-03-29 18:17 -0500
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-03-30 19:20 +0100
Re: Even more problems with lcc-win scott@slp53.sl.home (Scott Lurndal) - 2017-03-30 18:49 +0000
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-03-30 20:07 +0100
Re: Even more problems with lcc-win gordonb.b709o@burditt.org (Gordon Burditt) - 2017-04-16 03:45 -0500
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-04-16 16:34 +0100
Re: Even more problems with lcc-win Noob <root@127.0.0.1> - 2017-04-16 20:27 +0200
Re: Even more problems with lcc-win supercat@casperkitty.com - 2017-04-16 12:16 -0700
Re: Even more problems with lcc-win Robert Wessel <robertwessel2@yahoo.com> - 2017-04-17 02:29 -0500
Re: Even more problems with lcc-win Jerry Stuckle <jstucklex@attglobal.net> - 2017-03-27 19:01 -0400
Re: Even more problems with lcc-win raltbos@xs4all.nl (Richard Bos) - 2017-03-25 21:45 +0000
Re: Even more problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-25 23:19 +0100
Re: Even more problems with lcc-win "James R. Kuyper" <jameskuyper@verizon.net> - 2017-03-25 19:10 -0400
Re: Even more problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-26 00:54 +0100
Re: Even more problems with lcc-win jameskuyper@verizon.net - 2017-03-25 19:48 -0700
Re: Even more problems with lcc-win mertesthomas@gmail.com - 2017-03-26 05:12 -0700
Re: Even more problems with lcc-win supercat@casperkitty.com - 2017-03-26 14:00 -0700
Re: Even more problems with lcc-win gordonb.zdxct@burditt.org (Gordon Burditt) - 2017-03-27 02:03 -0500
Re: Even more problems with lcc-win Robert Wessel <robertwessel2@yahoo.com> - 2017-03-24 22:39 -0500
Re: Even more problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-25 09:13 +0100
Re: Even more problems with lcc-win BartC <bc@freeuk.com> - 2017-03-25 11:24 +0000
Re: Even more problems with lcc-win Ian Collins <ian-news@hotmail.com> - 2017-03-26 08:42 +1300
Re: Even more problems with lcc-win BartC <bc@freeuk.com> - 2017-03-25 19:51 +0000
Re: Even more problems with lcc-win Ian Collins <ian-news@hotmail.com> - 2017-03-26 09:10 +1300
Re: Even more problems with lcc-win BartC <bc@freeuk.com> - 2017-03-25 20:24 +0000
Re: Even more problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-03-25 13:43 -0700
Re: Even more problems with lcc-win Ian Collins <ian-news@hotmail.com> - 2017-03-26 10:30 +1300
Re: Even more problems with lcc-win Jean-Marc Bourguet <jm@bourguet.org> - 2017-03-26 10:23 +0200
Re: Even more problems with lcc-win supercat@casperkitty.com - 2017-03-24 15:08 -0700
Re: Even more problems with lcc-win BartC <bc@freeuk.com> - 2017-03-24 22:43 +0000
Re: Even more problems with lcc-win supercat@casperkitty.com - 2017-03-24 15:55 -0700
Re: Even more problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-03-24 16:27 -0700
Re: Even more problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-25 01:17 +0100
Re: Even more problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-25 01:18 +0100
Re: Even more problems with lcc-win scott@slp53.sl.home (Scott Lurndal) - 2017-03-27 15:06 +0000
Re: Even more problems with lcc-win BartC <bc@freeuk.com> - 2017-03-27 16:37 +0100
Re: Even more problems with lcc-win scott@slp53.sl.home (Scott Lurndal) - 2017-03-27 16:25 +0000
Re: Even more problems with lcc-win scott@slp53.sl.home (Scott Lurndal) - 2017-03-27 17:57 +0000
Re: Even more problems with lcc-win BartC <bc@freeuk.com> - 2017-03-27 19:12 +0100
Re: Even more problems with lcc-win Robert Wessel <robertwessel2@yahoo.com> - 2017-03-27 14:19 -0500
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-24 19:25 +0100
Re: Even more problems with lcc-win supercat@casperkitty.com - 2017-03-24 08:10 -0700
Re: Even more problems with lcc-win scott@slp53.sl.home (Scott Lurndal) - 2017-03-24 13:01 +0000
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-24 15:50 +0100
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-24 13:07 +0100
Re: Even more problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-24 15:48 +0100
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-24 16:26 +0100
Re: Even more problems with lcc-win Gareth Owen <gwowen@gmail.com> - 2017-03-24 16:32 +0000
Re: Even more problems with lcc-win James Kuyper <jameskuyper@verizon.net> - 2017-03-24 12:53 -0400
Re: Even more problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-24 18:24 +0100
Re: Even more problems with lcc-win scott@slp53.sl.home (Scott Lurndal) - 2017-03-24 17:29 +0000
Re: Even more problems with lcc-win jameskuyper@verizon.net - 2017-03-24 10:55 -0700
Re: Even more problems with lcc-win supercat@casperkitty.com - 2017-03-24 10:47 -0700
Re: Even more problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-03-24 09:37 -0700
Re: Even more problems with lcc-win Les Cargill <lcargill99@comcast.com> - 2017-03-25 15:07 -0500
Re: Even more problems with lcc-win mertesthomas@gmail.com - 2017-03-29 09:56 -0700
Re: Even more problems with lcc-win supercat@casperkitty.com - 2017-03-29 10:39 -0700
Re: Even more problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-03-29 12:22 -0700
Re: Even more problems with lcc-win mertesthomas@gmail.com - 2017-03-29 15:10 -0700
Re: Even more problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-03-29 16:58 -0700
Re: Even more problems with Seed7 jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-30 01:02 +0200
Re: Even more problems with Seed7 Robert Wessel <robertwessel2@yahoo.com> - 2017-03-30 01:05 -0500
Re: Even more problems with Seed7 Robert Wessel <robertwessel2@yahoo.com> - 2017-03-30 01:19 -0500
Re: Even more problems with Seed7 mertesthomas@gmail.com - 2017-04-02 04:19 -0700
Re: Even more problems with lcc-win mertesthomas@gmail.com - 2017-03-30 00:34 -0700
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-30 13:05 +0200
Re: Even more problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-31 00:00 +0200
Re: Even more problems with lcc-win mertesthomas@gmail.com - 2017-04-02 00:28 -0700
Re: Even more problems with lcc-win mertesthomas@gmail.com - 2017-03-30 00:50 -0700
Page 9 of 15 — ← Prev page 1 … 7 8 [9] 10 11 … 15 Next page →
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-04-03 14:40 +0100 |
| Message-ID | <XgsEA.818972$vF2.762591@fx46.am4> |
| In reply to | #107667 |
On 03/04/2017 13:32, David Brown wrote: > On 03/04/17 13:02, bartc wrote: > As an example, you wrote this recently: > >> >> To illustrate that, this morning it just managed to compile and run >> Hello, World (not quite effortless yet as it has to work via >> https://pastebin.com/fCCCGHsd). >> >> Current size of my project is 0.2MB. Clang, by contrast, was 50MB yet >> was unable to compile the same program [it depends on other compilers >> to supply essential content and functionality]. > > If you had simply written that your compiler has reached the point where > it can compile "Hello, world!", then I would see that as an achievement > - a serious step in the road towards a working compiler. > > But your second paragraph makes it clear that you see small size as > being the important feature Actually I needed to make very little effort there. My programs just happen to be small (partly because I write everything myself). There are also much smaller C compilers some of which are deliberately so. (in most circumstances, and for virtually > all uses of a C compiler, it is not relevant). And your jab at clang is > intended to show how bad other compilers are in comparison to yours - > but in fact is parading your wilful ignorance, your misunderstandings > about what a compiler actually is, your inability to read guidelines and > information, and your total and complete unwillingness to learn anything > from what people in this newsgroup tell you. The jab at clang is justified. There are two main problems (with clang under Windows): (1) By itself, it can't compile Hello World. Because it piggybacks onto another compiler. (I think this used to be gcc, and now it might be MSVC. The fact is I couldn't get a recent download working) (2) It doesn't tell you this. (I used clang for a year or two not realising it was quietly using the headers, libraries and utilities from gcc.) Another which I point out is that clang is a hefty 50MB executable. Quite tidy actually, and for those one or two years I actually believed it was that size because it included everything needed, including headers and linking tools. That it doesn't, makes you wonder what can possibly be inside it to be that big. Now I /know/ that a compiler can be 1% the size but still work. > It demonstrates either stupidity, or maliciousness. It demonstrates frustration that someone downloads a compiler that turns out to be a front end to another that you are expected to have, but which they don't tell you about. > (It is perfectly reasonable to say that you think clang would be easier > to work with on Windows if it were packaged along with a library and > other tools. But you only need to say it once - and you need to say it > to the folks who package clang for Windows.) If /they/ were to say it even once, instead off zero times, that would have been a help! (But, for 300-400MB total installation, how many KB would be needed to have provided a bunch of standard headers?!) [I may reply to other points at a later date.] -- bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-04-03 16:47 +0200 |
| Message-ID | <obtn52$96d$1@dont-email.me> |
| In reply to | #107669 |
On 03/04/17 15:40, bartc wrote: > On 03/04/2017 13:32, David Brown wrote: >> On 03/04/17 13:02, bartc wrote: > >> As an example, you wrote this recently: >> >>> >>> To illustrate that, this morning it just managed to compile and run >>> Hello, World (not quite effortless yet as it has to work via >>> https://pastebin.com/fCCCGHsd). >>> >>> Current size of my project is 0.2MB. Clang, by contrast, was 50MB yet >>> was unable to compile the same program [it depends on other compilers >>> to supply essential content and functionality]. >> >> If you had simply written that your compiler has reached the point where >> it can compile "Hello, world!", then I would see that as an achievement >> - a serious step in the road towards a working compiler. >> >> But your second paragraph makes it clear that you see small size as >> being the important feature > > Actually I needed to make very little effort there. My programs just > happen to be small (partly because I write everything myself). There are > also much smaller C compilers some of which are deliberately so. > > (in most circumstances, and for virtually >> all uses of a C compiler, it is not relevant). And your jab at clang is >> intended to show how bad other compilers are in comparison to yours - >> but in fact is parading your wilful ignorance, your misunderstandings >> about what a compiler actually is, your inability to read guidelines and >> information, and your total and complete unwillingness to learn anything >> from what people in this newsgroup tell you. > > The jab at clang is justified. There are two main problems (with clang > under Windows): > > (1) By itself, it can't compile Hello World. Because it piggybacks onto > another compiler. (I think this used to be gcc, and now it might be > MSVC. The fact is I couldn't get a recent download working) > It is a compiler, not a full C implementation. A C compiler does not have a library or a assembler or a linker. (llvm does, I believe have an experimental linker - but I don't think it has an assembler. But it does not have a library.) It expects to use the system assembler, linker and library. You can perhaps blame the llvm folks for not being entirely clear - after all, the describe LLVM as "The LLVM Compiler Infrastructure" and "a collection of modular and reusable compiler and toolchain technologies". And clang is "a C language family frontend for LLVM". It seems fairly clear to me that the llvm.org site is for developing the project, rather than for providing a full C implementation ready for simple installation on Windows. And it does not take a lot of searching to see that you need MSVC or gcc (or perhaps another toolchain, or manual installation of binutils and a C library) to supply the other parts of the toolchain. LLVM supplies parts of a toolchain - not a complete toolchain. > (2) It doesn't tell you this. (I used clang for a year or two not > realising it was quietly using the headers, libraries and utilities from > gcc.) I haven't found the information hard to find. But I can agree that it should be clearer, especially on the download page. An alternative is simply to do as gcc does - don't provide binaries for download. That is even clearer. > > Another which I point out is that clang is a hefty 50MB executable. > Quite tidy actually, and for those one or two years I actually believed > it was that size because it included everything needed, including > headers and linking tools. > > That it doesn't, makes you wonder what can possibly be inside it to be > that big. Now I /know/ that a compiler can be 1% the size but still work. > I can imagine a lot of stuff that takes space in an compiler. Just having a quick look, I note that the binaries include support for a range of target architectures, a range of front-end languages (C++ is vastly more complex than C, as is Objective-C), library versions of the tools as well as executables, etc. Why it is /so/ big, I don't know, because I haven't looked at the details - but I expect that it is a combination of the tools doing a lot of work, and the developers understanding that disk space is cheap. >> It demonstrates either stupidity, or maliciousness. > > It demonstrates frustration that someone downloads a compiler that turns > out to be a front end to another that you are expected to have, but > which they don't tell you about. Surely you cannot still be frustrated? This was explained to you long ago, when you first complained. Get over it. > >> (It is perfectly reasonable to say that you think clang would be easier >> to work with on Windows if it were packaged along with a library and >> other tools. But you only need to say it once - and you need to say it >> to the folks who package clang for Windows.) > > If /they/ were to say it even once, instead off zero times, that would > have been a help! (But, for 300-400MB total installation, how many KB > would be needed to have provided a bunch of standard headers?!) > I don't imagine that the size is relevant. But to provide a C library for Windows, they would have to either write one, copy one, or bundle an independent one. (The same goes for the assembler, linker, archiver, and common utilities.) Writing one is obviously a lot of work. Copying one means they then have responsibility for their copy, and there is a clash of licenses. Bundling one, such as mingw64's library and tools, is a pain for those that already have a compiler (and a good many people trying clang on Windows will already have a gcc such as mingw64 and/or MSVC), and again makes the llvm folk responsible for packaging these. It's simply easier to say "install MSVC or mingw". > [I may reply to other points at a later date.] > OK.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-04-07 16:56 +0100 |
| Message-ID | <UEOFA.404344$8b6.9529@fx19.am4> |
| In reply to | #107672 |
On 03/04/2017 15:47, David Brown wrote:
> On 03/04/17 15:40, bartc wrote:
[About clang on Windows]
>> (1) By itself, it can't compile Hello World. Because it piggybacks onto
>> another compiler. (I think this used to be gcc, and now it might be
>> MSVC. The fact is I couldn't get a recent download working)
>>
>
> It is a compiler, not a full C implementation.
What does a compiler do, and what should be its output?
> A C compiler does not
> have a library or a assembler or a linker.
Does it have a set of standard include files? If not, where do they come
from? Wikipedia tells me clang is a front-end to LLVM. So, does LLVM
provided the includes files? If not, where are they?
See, it's taken a straightforward concept that everyone understands - a
program to, at the very least, turn C source into an object file or even
some asm source - and completely destroyed it.
> (llvm does, I believe have
> an experimental linker
How hard is a linker to write?
- but I don't think it has an assembler. But it
> does not have a library.) It expects to use the system assembler,
> linker and library.
So what happened to using LLVM as the 'back-end'? Or does LLVM now have
a dependency on those system utilties?
> You can perhaps blame the llvm folks for not being entirely clear -
I looked at LLVM nearly a decade ago; there were 44 *sets* of
documentation even then. A small and simple system, it is not.
(From golang.org:
"We considered using LLVM for gc but we felt it was too large and slow
to meet our performance goals.")
>> (2) It doesn't tell you this. (I used clang for a year or two not
>> realising it was quietly using the headers, libraries and utilities from
>> gcc.)
>
> I haven't found the information hard to find. But I can agree that it
> should be clearer, especially on the download page. An alternative is
> simply to do as gcc does - don't provide binaries for download. That is
> even clearer.
So how do you run it? A newcomer to C who wants a free compiler to get
started on, has to have the experience and know-how to compile a project
of tens of thousands of lines? And with what?
>> That it doesn't, makes you wonder what can possibly be inside it to be
>> that big. Now I /know/ that a compiler can be 1% the size but still work.
> I can imagine a lot of stuff that takes space in an compiler. Just
> having a quick look, I note that the binaries include support for a
> range of target architectures, a range of front-end languages (C++ is
> vastly more complex than C, as is Objective-C), library versions of the
> tools as well as executables, etc. Why it is /so/ big, I don't know,
> because I haven't looked at the details - but I expect that it is a
> combination of the tools doing a lot of work, and the developers
> understanding that disk space is cheap.
I just downloaded it again. The 32-bit version (of Clang for Windows
binaries) had download problems. The 64-bit version is now a 900MB
installation with over 700MB of executables. clang.exe is now 67MB.
The only inkling that something was wrong was on a console pop-up saying
it couldn't connect to MS Studio or something - press any key. Then it
said 'successfully installed'.
But it can't compile hello.c because it can't find stdio.h. If I use the
-I switch to point to some headers belong to some other compilers
including MSVC, it will find some problem with all of them.
If I reduce the program to just:
extern int printf(char*,...);
int main(void) {
printf("Hello World!\n");
}
it complains about a incompatible declaration of printf warning.
However it eventually worked when I tried gcc's headers; it produced
hello.o.
But now what? If I type:
gcc hello.o
gcc says:
"hello.o: file not recognized: File format not recognized"
> I don't imagine that the size is relevant. But to provide a C library
> for Windows, they would have to either write one, copy one, or bundle an
> independent one. (The same goes for the assembler, linker, archiver,
> and common utilities.) Writing one is obviously a lot of work
I don't agree:
(1) If someone can write 700MB' worth of programs, then an assembler and
linker, and even a C library, should be a piece of cake.
(2) Windows comes with an existing C library called msvcrt.dll.
> It's simply easier to say "install MSVC or mingw".
It's even easier to just install those and use them; why bother with
clang at all? And where would we all be if the developers of MSVC, mingw
and other compilers took the same approach, requiring people to download
another compiler to provide the missing bits?!
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-04-07 18:06 +0100 |
| Message-ID | <2GPFA.825815$qK5.647755@fx45.am4> |
| In reply to | #107819 |
On 07/04/2017 16:56, bartc wrote: [clang] > So how do you run it? A newcomer to C who wants a free compiler to get > started on, has to have the experience and know-how to compile a project > of tens of thousands of lines? If only. I meant tens of thousands of /files/. (Actually I don't know how many files are in the clang source; I guess it gets mixed up with LLVM, which I now recall uses C++, just to make life that little bit simpler! But gcc sources are nearly 100,000 files.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-04-07 20:02 +0200 |
| Message-ID | <oc8k2f$gbd$1@dont-email.me> |
| In reply to | #107819 |
On 07/04/17 17:56, bartc wrote:
> On 03/04/2017 15:47, David Brown wrote:
>> On 03/04/17 15:40, bartc wrote:
>
> [About clang on Windows]
>
>>> (1) By itself, it can't compile Hello World. Because it piggybacks onto
>>> another compiler. (I think this used to be gcc, and now it might be
>>> MSVC. The fact is I couldn't get a recent download working)
>>>
>>
>> It is a compiler, not a full C implementation.
>
> What does a compiler do, and what should be its output?
>
A compiler takes source code in a high level format, and generates
output code in a lower level format. Often that means going from a
common programming language to assembly, but it could be to machine code
directly, or some sort of byte code or other intermediary format.
Sometimes the source language is also really a intermediary byte code.
>> A C compiler does not
>> have a library or a assembler or a linker.
>
> Does it have a set of standard include files? If not, where do they come
> from? Wikipedia tells me clang is a front-end to LLVM. So, does LLVM
> provided the includes files? If not, where are they?
Compilers will often provide /some/ include files. The C standard
library (and the standard C++ library) will also provide include files.
I don't imagine LLVM provides them, but I am sure clang has a few. But
those will be specific to the compiler, rather than host system include
files like windows.h.
>
> See, it's taken a straightforward concept that everyone understands - a
> program to, at the very least, turn C source into an object file or even
> some asm source - and completely destroyed it.
>
>> (llvm does, I believe have
>> an experimental linker
>
> How hard is a linker to write?
>
In the case of llvm - it is a significant effort, because it is a major
part of the optimisation. C (and C++) files pass through clang to
generate intermediary files. These are analysed and optimised by llvm
passes, before going over to the linker. The linker joins these files
together, then passes them back to other parts of llvm for more
optimisation - cross file inlining, function cloning, analysis, etc.
Then they end up back at the linker some time later.
Also, linkers such as the one in llvm (and the "gold" linker in
binutils) are multi-threaded systems designed to scale with large
numbers of processors and huge numbers of files. They don't just chug
along through a few files with some thousand-odd symbols - they are made
so they also run on systems with dozens of cores and tens of GB of ram,
with hundreds of thousands of files to link and cross-optimise.
> - but I don't think it has an assembler. But it
>> does not have a library.) It expects to use the system assembler,
>> linker and library.
>
> So what happened to using LLVM as the 'back-end'? Or does LLVM now have
> a dependency on those system utilties?
As far as I know, llvm has always had a dependency on an external
assembler. But that's an easy tool to get. And it also depends on
external libraries.
>
>> You can perhaps blame the llvm folks for not being entirely clear -
>
> I looked at LLVM nearly a decade ago; there were 44 *sets* of
> documentation even then. A small and simple system, it is not.
>
It was never meant to be a small and simple system.
> (From golang.org:
>
> "We considered using LLVM for gc but we felt it was too large and slow
> to meet our performance goals.")
>
>>> (2) It doesn't tell you this. (I used clang for a year or two not
>>> realising it was quietly using the headers, libraries and utilities from
>>> gcc.)
>>
>> I haven't found the information hard to find. But I can agree that it
>> should be clearer, especially on the download page. An alternative is
>> simply to do as gcc does - don't provide binaries for download. That is
>> even clearer.
>
> So how do you run it? A newcomer to C who wants a free compiler to get
> started on, has to have the experience and know-how to compile a project
> of tens of thousands of lines? And with what?
You have a look on google. Usually, a good choice is something with a
pre-packaged IDE, like Code::Blocks or Eclipse. The ever-helpful
Wikipedia has a list:
<https://en.wikipedia.org/wiki/Comparison_of_integrated_development_environments#C.2FC.2B.2B>
>
>>> That it doesn't, makes you wonder what can possibly be inside it to be
>>> that big. Now I /know/ that a compiler can be 1% the size but still
>>> work.
>
>> I can imagine a lot of stuff that takes space in an compiler. Just
>> having a quick look, I note that the binaries include support for a
>> range of target architectures, a range of front-end languages (C++ is
>> vastly more complex than C, as is Objective-C), library versions of the
>> tools as well as executables, etc. Why it is /so/ big, I don't know,
>> because I haven't looked at the details - but I expect that it is a
>> combination of the tools doing a lot of work, and the developers
>> understanding that disk space is cheap.
>
> I just downloaded it again. The 32-bit version (of Clang for Windows
> binaries) had download problems. The 64-bit version is now a 900MB
> installation with over 700MB of executables. clang.exe is now 67MB.
>
> The only inkling that something was wrong was on a console pop-up saying
> it couldn't connect to MS Studio or something - press any key. Then it
> said 'successfully installed'.
>
> But it can't compile hello.c because it can't find stdio.h. If I use the
> -I switch to point to some headers belong to some other compilers
> including MSVC, it will find some problem with all of them.
>
> If I reduce the program to just:
>
> extern int printf(char*,...);
>
> int main(void) {
> printf("Hello World!\n");
> }
>
> it complains about a incompatible declaration of printf warning.
>
> However it eventually worked when I tried gcc's headers; it produced
> hello.o.
>
> But now what? If I type:
>
> gcc hello.o
>
> gcc says:
>
> "hello.o: file not recognized: File format not recognized"
>
>
>> I don't imagine that the size is relevant. But to provide a C library
>> for Windows, they would have to either write one, copy one, or bundle an
>> independent one. (The same goes for the assembler, linker, archiver,
>> and common utilities.) Writing one is obviously a lot of work
>
> I don't agree:
>
> (1) If someone can write 700MB' worth of programs, then an assembler and
> linker, and even a C library, should be a piece of cake.
>
> (2) Windows comes with an existing C library called msvcrt.dll.
>
>> It's simply easier to say "install MSVC or mingw".
>
> It's even easier to just install those and use them; why bother with
> clang at all? And where would we all be if the developers of MSVC, mingw
> and other compilers took the same approach, requiring people to download
> another compiler to provide the missing bits?!
>
You use clang if you want to use clang. It is a much better C compiler
than MS has - that's why MS has moved to bundling it with their tools as
a C compiler. But use whatever tools you want.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-04-07 19:49 +0100 |
| Message-ID | <WaRFA.672089$3a3.612012@fx43.am4> |
| In reply to | #107829 |
On 07/04/2017 19:02, David Brown wrote: > On 07/04/17 17:56, bartc wrote: >> What does a compiler do, and what should be its output? > > A compiler takes source code in a high level format, and generates > output code in a lower level format. So clang by itself - the version packaged for Windows - fails on that point. Unless the code makes no use of standard headers. >> How hard is a linker to write? >> > > In the case of llvm - it is a significant effort, because it is a major > part of the optimisation. C (and C++) files pass through clang to > generate intermediary files. These are analysed and optimised by llvm > passes, before going over to the linker. ... But if clang uses linkers of either gcc or MSVC, will /they/ do all that processing? > Also, linkers such as the one in llvm (and the "gold" linker in > binutils) are multi-threaded systems designed to scale with large > numbers of processors and huge numbers of files. They don't just chug > along through a few files with some thousand-odd symbols - they are made > so they also run on systems with dozens of cores and tens of GB of ram, > with hundreds of thousands of files to link and cross-optimise. And by striving to be so ambitious, the end result is that there is no viable linker at all. Or if there is, I've no idea how it's supposed to work. Until that works properly (although I would be scared to invoke such a monster), they could have provided a simpler linker as an interim measure. (I've used one called Golink; it's 47KB in size (kilobytes, if people can remember those), and seems to work apart from treating pointers to shared-library functions in a funny way. Hence my question: how hard is it to write a linker?) >> I looked at LLVM nearly a decade ago; there were 44 *sets* of >> documentation even then. A small and simple system, it is not. > It was never meant to be a small and simple system. Exactly, there is room for C implementations that are considerably smaller, simpler and faster without being proportionately poorer in generated code. But you might expect the bigger ones to at least work! -- bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-04-08 13:26 +0200 |
| Message-ID | <ocah6n$ims$1@dont-email.me> |
| In reply to | #107834 |
On 07/04/17 20:49, bartc wrote: > On 07/04/2017 19:02, David Brown wrote: >> On 07/04/17 17:56, bartc wrote: > >>> What does a compiler do, and what should be its output? >> >> A compiler takes source code in a high level format, and generates >> output code in a lower level format. > > So clang by itself - the version packaged for Windows - fails on that > point. Unless the code makes no use of standard headers. Yes, in the same way that a car fails to be a transportation device. After all, it is useless without a driver, petrol, roads, etc. Actually, clang by itself is /not/ a compiler - it is merely a front-end to a compiler, and requires the rest of llvm to be a compiler. > >>> How hard is a linker to write? >>> >> >> In the case of llvm - it is a significant effort, because it is a major >> part of the optimisation. C (and C++) files pass through clang to >> generate intermediary files. These are analysed and optimised by llvm >> passes, before going over to the linker. ... > > But if clang uses linkers of either gcc or MSVC, will /they/ do all that > processing? I am not an expert in clang, and I don't know how it can interact with other linkers. > >> Also, linkers such as the one in llvm (and the "gold" linker in >> binutils) are multi-threaded systems designed to scale with large >> numbers of processors and huge numbers of files. They don't just chug >> along through a few files with some thousand-odd symbols - they are made >> so they also run on systems with dozens of cores and tens of GB of ram, >> with hundreds of thousands of files to link and cross-optimise. > > And by striving to be so ambitious, the end result is that there is no > viable linker at all. Or if there is, I've no idea how it's supposed to > work. > As always, other people seem to manage fine. > Until that works properly (although I would be scared to invoke such a > monster), they could have provided a simpler linker as an interim measure. > > (I've used one called Golink; it's 47KB in size (kilobytes, if people > can remember those), and seems to work apart from treating pointers to > shared-library functions in a funny way. Hence my question: how hard is > it to write a linker?) Writing a /simple/ linker, for a single host OS, a single choice of target, with no optimisations, no sophisticated linker control language, simple input file formats, etc., can be a fairly straightforward task. It is all about what sort of features you want. The clang/llvm folks had no interest in writing a linker like that - why bother, when they could just as easily use the existing flexible and advanced binutils linker? They only wrote their own linker because they wanted more features beyond those of binutils. > >>> I looked at LLVM nearly a decade ago; there were 44 *sets* of >>> documentation even then. A small and simple system, it is not. > >> It was never meant to be a small and simple system. > > Exactly, there is room for C implementations that are considerably > smaller, simpler and faster without being proportionately poorer in > generated code. But you might expect the bigger ones to at least work! > The bigger ones /do/ work for other people. And yes, there is room for C implementations such as you describe. Jacob's tools are a fine example - they strike a very different balance than clang/llvm, gcc or MSVC.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-04-08 13:33 +0100 |
| Message-ID | <JL4GA.594227$0k4.381564@fx37.am4> |
| In reply to | #107857 |
On 08/04/2017 12:26, David Brown wrote: > On 07/04/17 20:49, bartc wrote: > Writing a /simple/ linker, for a single host OS, a single choice of > target, with no optimisations, no sophisticated linker control language, What does even an /unsophisticated/ linker control language do when it's at home? > simple input file formats, The best ones. Why would you deliberately use complex ones? etc., can be a fairly straightforward task. > It is all about what sort of features you want. > > The clang/llvm folks had no interest in writing a linker like that - why > bother, when they could just as easily use the existing flexible and > advanced binutils linker? They only wrote their own linker because they > wanted more features beyond those of binutils. So they wanted to write something totally impossible instead. What /is/ a linker except something to join up lots of object files into an executable or a shared library? Or some single code image or other that you want to stick in a rom. The aims are extremely simple, but some people are obviously intent on taking the extremely simple and making it extremely complex! At the minute, my using clang is the equivalent of buying a typewriter to address envelopes, but finding it doesn't work because the business end expects to be attached to an offset printing press that I have to provide. > target, with no optimisations I assume you are talking about link-time optimisations. But there are alternatives, such as doing this stuff at compile-time when all the information can already be available. Compilers can already be given N source files to compile into one executable, so all the information is already in memory. It's also possible to get the same effects by aggregating all sources into one file then compiling that (something which has been scorned that here). (Actually, my programs in C source form are already like that, then link-time optimisation would have no effect.) -- bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-04-08 16:27 +0200 |
| Message-ID | <ocarr3$k2t$1@dont-email.me> |
| In reply to | #107863 |
On 08/04/17 14:33, bartc wrote: > On 08/04/2017 12:26, David Brown wrote: >> On 07/04/17 20:49, bartc wrote: > >> Writing a /simple/ linker, for a single host OS, a single choice of >> target, with no optimisations, no sophisticated linker control language, > > What does even an /unsophisticated/ linker control language do when it's > at home? > >> simple input file formats, > > The best ones. Why would you deliberately use complex ones? > > etc., can be a fairly straightforward task. >> It is all about what sort of features you want. >> >> The clang/llvm folks had no interest in writing a linker like that - why >> bother, when they could just as easily use the existing flexible and >> advanced binutils linker? They only wrote their own linker because they >> wanted more features beyond those of binutils. > > So they wanted to write something totally impossible instead. > > What /is/ a linker except something to join up lots of object files into > an executable or a shared library? Or some single code image or other > that you want to stick in a rom. > > The aims are extremely simple, but some people are obviously intent on > taking the extremely simple and making it extremely complex! > > At the minute, my using clang is the equivalent of buying a typewriter > to address envelopes, but finding it doesn't work because the business > end expects to be attached to an offset printing press that I have to > provide. A better analogy is that /you/ only ever have need of a simple typewriter. You don't know how it works, but you know how a pencil works - and you think a typewriter is just like a pencil with keys on top. Since you can't imagine needing to do anything more sophisticated than putting an address on an envelop, you see an offset printing press as just a huge, slow typewriter and because /you/ can't figure out how to use it, you assume the people who designed it are idiots. > >> target, with no optimisations > > I assume you are talking about link-time optimisations. But there are > alternatives, such as doing this stuff at compile-time when all the > information can already be available. Compilers can already be given N > source files to compile into one executable, so all the information is > already in memory. You think that, because first you don't understand the sort of optimisations that can be done at link-time (without considering link-time code generation), and secondly, you don't understand about scaling. There are certainly C implementations that do handle this altogether in one lump - doing compilation, linking, and assembly of all files at a time. That makes sense for small and limited systems, and is not uncommon in compilers for very small embedded micros. But that does not scale well - for larger projects, you need to be able to compile files independently. I know you believe that compilers should run at the rate of millions of lines of code per second, that no project has any excuse for requiring more than a dozen C files, and that C++ is so complex that no one understands it and therefore no one should use it. But that is not the way the world works. People compile and then link. For larger projects, especially with link-time code generation, they will also do partial links - combining bits of files and doing some cross-module optimisation, so that less work needs to be repeated when changing the source for parts of the project. However, in this particular case, I was talking about linker optimisations other than link-time code generation. There are a number of optimisations that can be done at this stage, such as combining identical sections (very useful for C++ template code, if you have one section per function), combining identical strings, and arranging code order to improve locality of reference. Sometimes instructions can be changed to give smaller or faster branches once code layout is known (though this is more likely to be part of the assembler). > > It's also possible to get the same effects by aggregating all sources > into one file then compiling that (something which has been scorned that > here). (Actually, my programs in C source form are already like that, > then link-time optimisation would have no effect.) >
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-04-08 22:28 +0100 |
| Message-ID | <XBcGA.594385$0k4.115523@fx37.am4> |
| In reply to | #107868 |
On 08/04/2017 15:27, David Brown wrote: > On 08/04/17 14:33, bartc wrote: > You think that, because first you don't understand the sort of > optimisations that can be done at link-time (without considering > link-time code generation), and secondly, you don't understand about > scaling. May I remind you of that 1Mloc test a month or two back? gcc would have taken 2-3 minutes to compile it - or would have done if it hadn't run out of memory. The same code was dispatched by Tiny C in 1.5 seconds. While another version that someone posted caused gcc to actually crash. Good luck with using it for those super-sized projects... It seems to me actually that small, fast tools are of much more benefit for big applications than big cumbersome ones. After all, if you need to test an app thousands of times, how many of those tests needs to be at the maximum possible speed with the best possible code? > People compile and > then link. I've also used compile and link. But whenever I've had to create my own tools, they're always much faster and effortless than any of those professional ones. Funny that. For larger projects, especially with link-time code > generation, they will also do partial links - combining bits of files > and doing some cross-module optimisation, so that less work needs to be > repeated when changing the source for parts of the project. Is optimisation of this kind really essential for every single build? I remember writing graphics code - if an element didn't look quite right, I would edit-compile-run until it looked better. For that purpose you want a near-instant edit-compile-run cycle, and you aren't interested in optimisation. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-04-09 13:54 +1200 |
| Message-ID | <ektij5F7g4pU1@mid.individual.net> |
| In reply to | #107900 |
On 04/ 9/17 09:28 AM, bartc wrote: > On 08/04/2017 15:27, David Brown wrote: >> On 08/04/17 14:33, bartc wrote: > >> You think that, because first you don't understand the sort of >> optimisations that can be done at link-time (without considering >> link-time code generation), and secondly, you don't understand about >> scaling. > > May I remind you of that 1Mloc test a month or two back? One big file isn't scaling, many smaller files being worked on by many developers is. For a team size > 1 the single big file approach is totally impractical. > It seems to me actually that small, fast tools are of much more benefit > for big applications than big cumbersome ones. The terms "small, fast" and "big cumbersome" are relative. For most of us the compilers we use are small and fast enough for what we do. Sure they could be faster, but I for one value the quality and scope of diagnostics from a compiler over speed (which is why I prefer clang these days, especially for C++). A simple, fast compiler that lacks decent diagnostics would, in the context of a development project, be slower than a slower compiler with better diagnostics. > After all, if you need to test an app thousands of times, how many of > those tests needs to be at the maximum possible speed with the best > possible code? Hardly any, but you still have to link which is often the bottleneck on a large project. >> People compile and >> then link. > > I've also used compile and link. But whenever I've had to create my own > tools, they're always much faster and effortless than any of those > professional ones. Funny that. So how long do they take to cross-compile and link a kernel? A sort while back that is what I was doing many times a day... > For larger projects, especially with link-time code >> generation, they will also do partial links - combining bits of files >> and doing some cross-module optimisation, so that less work needs to be >> repeated when changing the source for parts of the project. > > Is optimisation of this kind really essential for every single build? No, but with decent incremental linker you may as well do it. > I remember writing graphics code - if an element didn't look quite > right, I would edit-compile-run until it looked better. For that purpose > you want a near-instant edit-compile-run cycle, and you aren't > interested in optimisation. For a project where that is viable, just about any modern tool set would be plenty fast enough. -- Ian
[toc] | [prev] | [next] | [standalone]
| From | Gareth Owen <gwowen@gmail.com> |
|---|---|
| Date | 2017-04-09 07:55 +0100 |
| Message-ID | <8737dioysj.fsf@gmail.com> |
| In reply to | #107909 |
Ian Collins <ian-news@hotmail.com> writes: > On 04/ 9/17 09:28 AM, bartc wrote: >> On 08/04/2017 15:27, David Brown wrote: >>> On 08/04/17 14:33, bartc wrote: >> >>> You think that, because first you don't understand the sort of >>> optimisations that can be done at link-time (without considering >>> link-time code generation), and secondly, you don't understand about >>> scaling. >> >> May I remind you of that 1Mloc test a month or two back? > > One big file isn't scaling, many smaller files being worked on by many > developers is. The problem there wasn't even one big file. It was one big function. One big file was absolutely fine. But bartc is a proven idiot - multiple times over - and honestly I have no idea why so many non-idiots are still arguing with him. He's 'fir' with better grammar.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-04-09 10:24 +0100 |
| Message-ID | <k5nGA.925102$vF2.121475@fx46.am4> |
| In reply to | #107919 |
On 09/04/2017 07:55, Gareth Owen wrote: > Ian Collins <ian-news@hotmail.com> writes: > >> On 04/ 9/17 09:28 AM, bartc wrote: >>> On 08/04/2017 15:27, David Brown wrote: >>>> On 08/04/17 14:33, bartc wrote: >>> >>>> You think that, because first you don't understand the sort of >>>> optimisations that can be done at link-time (without considering >>>> link-time code generation), and secondly, you don't understand about >>>> scaling. >>> >>> May I remind you of that 1Mloc test a month or two back? >> >> One big file isn't scaling, many smaller files being worked on by many >> developers is. > > The problem there wasn't even one big file. It was one big function. > One big file was absolutely fine. Read the thread again. Another test had 125,000 functions. I ran that test again today, 62.5K functions as I'm using a smaller machine, and gcc took 75 times as long as the fastest, with two failing to finish. > But bartc is a proven idiot - > multiple times over - and honestly I have no idea why so many non-idiots > are still arguing with him. He's 'fir' with better grammar. His contributions to the group are still more interesting than yours despite the language.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-04-09 10:45 +0100 |
| Message-ID | <4pnGA.771086$w46.135068@fx39.am4> |
| In reply to | #107909 |
On 09/04/2017 02:54, Ian Collins wrote: > On 04/ 9/17 09:28 AM, bartc wrote: >> May I remind you of that 1Mloc test a month or two back? > > One big file isn't scaling, many smaller files being worked on by many > developers is. Such a test can help diagnose problems in a compiler, and not just performance ones. (In any sort of application really although David Brown appears to think any stress tests are worthless if they do involve real data.) (I was testing a 0.5Mloc file of 60K functions today and found one such problem in my compiler. Code-gen time is normally a bit faster than parsing, but here it was much slower. Turns out there was a per-function initialisation function called where most of the init-code need only have been done once per file. Nonsense test data, but it did the trick. On real data it would have been harder to spot with a normal mix of functions.) > For a team size > 1 the single big file approach is totally impractical. I'm not saying everything always needs to be in one file! That is just one technique for distributing a finished application. But it can show up problems when testing and comparing compilers. >> I've also used compile and link. But whenever I've had to create my own >> tools, they're always much faster and effortless than any of those >> professional ones. Funny that. > > So how long do they take to cross-compile and link a kernel? A sort > while back that is what I was doing many times a day... Is a kernel that impossibly complex program where even gcc had to be modified to be able to compile? I don't know how long they would take. Based on my track record, probably a lot less time than traditional tools. But if this is that project you once mentioned consisting of hundreds of very small files, then the first task would be to try and do something about the file-handling bottleneck. That's if that /is/ the bottleneck (it certainly would be with my code). Otherwise, the equation is simple: how many bytes of input are there, and how many bytes of output? That will give an idea of what ought to be a reasonable processing time, and you can work from there. (However, if I'd been involved from the start, such a program wouldn't have ended up that complex in the first place.) -- bartc
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-04-09 10:53 +0100 |
| Message-ID | <FwnGA.415888$8b6.280594@fx19.am4> |
| In reply to | #107923 |
On 09/04/2017 10:45, bartc wrote: > (In any sort of application really although David > Brown appears to think any stress tests are worthless if they do involve > real data.) "don't involve" not "do involve"! (In case David decides to sue me for libel.)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-04-09 14:03 +0200 |
| Message-ID | <ocd7o2$88e$1@dont-email.me> |
| In reply to | #107924 |
On 09/04/17 11:53, bartc wrote: > On 09/04/2017 10:45, bartc wrote: > >> (In any sort of application really although David >> Brown appears to think any stress tests are worthless if they do involve >> real data.) > > "don't involve" not "do involve"! > > (In case David decides to sue me for libel.) > I didn't notice that typo, so no worries there. I think stress tests are worthless unless they have a relation to real use or real data. That does not mean they be real code and real data - they just have to be realistic, or to show the effect of real use. To go for a car analogy, if you are making a new car it makes a lot of sense to stress-test it by driving around a test track for days on end - even though no one would ever do that in real life. But it makes little sense to do the test in first gear, with the handbrake on, while continuously opening and closing the windows. And even with the continuous run round the track, you have to be careful how you interpret the results (lifetime, fuel usage, speed, whatever) - it can give you /some/ ideas about /some/ aspects of the car's functionality, but it is far from being a complete way to judge the worth of the car.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-04-10 16:17 -0700 |
| Message-ID | <e4ce8e3a-87d1-4e23-9fb5-69964dfe66c6@googlegroups.com> |
| In reply to | #107926 |
On Sunday, April 9, 2017 at 7:03:13 AM UTC-5, David Brown wrote: > To go for a car analogy, if you are making a new car it makes a lot of > sense to stress-test it by driving around a test track for days on end - > even though no one would ever do that in real life. But it makes little > sense to do the test in first gear, with the handbrake on, while > continuously opening and closing the windows. When a car is used in such conditions, it should be acceptable for it to waste gas and require much more frequent replacement of the brake pads or or shoes than would otherwise be necessary. On the other hand, it should probably not be acceptable for a car used in such fashion to catch fire, or have the overheating rear brakes disable the front brakes. It might thus not be unreasonable to test the car under the conditions you describe for the purpose of ensuring those latter things don't happen. > And even with the continuous run round the track, you have to be careful > how you interpret the results (lifetime, fuel usage, speed, whatever) - > it can give you /some/ ideas about /some/ aspects of the car's > functionality, but it is far from being a complete way to judge the > worth of the car. Certain aspects of performance should be expected to be dismal, but others should behave normally. If a car has been traveling for awhile at 35mph with the parking brake on, it would be unreasonable to expect the same kind of braking performance as when the brakes weren't overheated, but the increase in stopping distance should be nearer to 2x than 20x.
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2017-04-14 10:24 +0000 |
| Message-ID | <58f0a314.2352515@news.xs4all.nl> |
| In reply to | #108024 |
supercat@casperkitty.com wrote: > On Sunday, April 9, 2017 at 7:03:13 AM UTC-5, David Brown wrote: > > To go for a car analogy, if you are making a new car it makes a lot of > > sense to stress-test it by driving around a test track for days on end - > > even though no one would ever do that in real life. But it makes little > > sense to do the test in first gear, with the handbrake on, while > > continuously opening and closing the windows. > > When a car is used in such conditions, it should be acceptable for it to > waste gas and require much more frequent replacement of the brake pads or > or shoes than would otherwise be necessary. On the other hand, it should > probably not be acceptable for a car used in such fashion to catch fire, Too bad, then, that this occasionally does happen. Richard
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-04-14 12:29 -0700 |
| Message-ID | <25016669-c2c0-4611-9c61-70ee263c7bc3@googlegroups.com> |
| In reply to | #108119 |
On Friday, April 14, 2017 at 5:24:08 AM UTC-5, Richard Bos wrote: > supercat wrote: > > On Sunday, April 9, 2017 at 7:03:13 AM UTC-5, David Brown wrote: > > > To go for a car analogy, if you are making a new car it makes a lot of > > > sense to stress-test it by driving around a test track for days on end - > > > even though no one would ever do that in real life. But it makes little > > > sense to do the test in first gear, with the handbrake on, while > > > continuously opening and closing the windows. > > > > When a car is used in such conditions, it should be acceptable for it to > > waste gas and require much more frequent replacement of the brake pads or > > or shoes than would otherwise be necessary. On the other hand, it should > > probably not be acceptable for a car used in such fashion to catch fire, > > Too bad, then, that this occasionally does happen. Indeed, but not all the things that happen in this world should be considered acceptable. Sometimes brake calipers can stick or transmissions might fail in such fashion as to be stuck in first, and while operation under such conditions would waste gas and greatly accelerate wear, it may be helpful to know to what extent if any it would place the vehicles' occupants at risk.
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2017-04-09 13:04 +0000 |
| Message-ID | <58ea3092.688234@news.xs4all.nl> |
| In reply to | #107909 |
Ian Collins <ian-news@hotmail.com> wrote: > On 04/ 9/17 09:28 AM, bartc wrote: > > On 08/04/2017 15:27, David Brown wrote: > >> On 08/04/17 14:33, bartc wrote: > > > >> You think that, because first you don't understand the sort of > >> optimisations that can be done at link-time (without considering > >> link-time code generation), and secondly, you don't understand about > >> scaling. > > > > May I remind you of that 1Mloc test a month or two back? > > One big file isn't scaling, many smaller files being worked on by many > developers is. > > For a team size > 1 the single big file approach is totally impractical. I've always found it equally impractical with team size == 1. Certainly when you make them as ludicrously big as 1Mloc. > For a project where that is viable, just about any modern tool set would > be plenty fast enough. I've certainly always found this to be the case. But then, I prefer to think about my code before I compile it, and not compile it seven hundred and ninety four times a day. Richard
[toc] | [prev] | [next] | [standalone]
Page 9 of 15 — ← Prev page 1 … 7 8 [9] 10 11 … 15 Next page →
Back to top | Article view | comp.lang.c
csiph-web