Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #129945 > unrolled thread
| Started by | Real Troll <real.troll@trolls.com> |
|---|---|
| First post | 2018-04-30 02:10 +0000 |
| Last post | 2018-05-01 13:46 +0000 |
| Articles | 20 on this page of 208 — 30 participants |
Back to article view | Back to comp.lang.c
The case AGAINST C Real Troll <real.troll@trolls.com> - 2018-04-30 02:10 +0000
Re: The case AGAINST C cross@spitfire.i.gajendra.net (Dan Cross) - 2018-04-30 03:14 +0000
Re: The case AGAINST C Tim Rentsch <txr@alumni.caltech.edu> - 2018-04-30 05:48 -0700
Re: The case AGAINST C bartc <bc@freeuk.com> - 2018-04-30 14:58 +0100
Re: The case AGAINST C Davs <johndemeert0@gmail.com> - 2018-05-07 04:18 -0700
Re: The case AGAINST C Steve Carroll <frelwizzen@gmail.com> - 2018-05-07 05:26 -0700
Re: The case AGAINST C Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2018-05-07 11:21 -0400
Re: The case AGAINST C Steve Carroll <frelwizzen@gmail.com> - 2018-05-07 09:21 -0700
Re: The case AGAINST C Robert Wessel <robertwessel2@yahoo.com> - 2018-05-07 12:13 -0500
Re: The case AGAINST C Steve Carroll <frelwizzen@gmail.com> - 2018-05-07 10:24 -0700
Re: The case AGAINST C Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2018-05-07 13:27 -0400
Re: The case AGAINST C scott@slp53.sl.home (Scott Lurndal) - 2018-05-07 17:33 +0000
Re: The case AGAINST C Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2018-05-07 13:50 -0400
Re: The case AGAINST C Steve Carroll <frelwizzen@gmail.com> - 2018-05-07 10:56 -0700
Re: The case AGAINST C David Brown <david.brown@hesbynett.no> - 2018-05-08 09:26 +0200
Re: The case AGAINST C David Brown <david.brown@hesbynett.no> - 2018-05-08 09:19 +0200
Re: The case AGAINST C Steve Carroll <frelwizzen@gmail.com> - 2018-05-08 00:42 -0700
Re: The case AGAINST C supercat@casperkitty.com - 2018-05-08 06:54 -0700
Re: The case AGAINST C Steve Carroll <frelwizzen@gmail.com> - 2018-05-08 07:24 -0700
Re: The case AGAINST C David Brown <david.brown@hesbynett.no> - 2018-05-08 17:15 +0200
Re: The case AGAINST C supercat@casperkitty.com - 2018-05-08 09:31 -0700
Re: The case AGAINST C David Brown <david.brown@hesbynett.no> - 2018-05-08 18:48 +0200
Re: The case AGAINST C supercat@casperkitty.com - 2018-05-08 10:33 -0700
Re: The case AGAINST C David Brown <david.brown@hesbynett.no> - 2018-05-08 23:36 +0200
Re: The case AGAINST C supercat@casperkitty.com - 2018-05-08 15:08 -0700
Re: The case AGAINST C David Brown <david.brown@hesbynett.no> - 2018-05-09 00:56 +0200
Re: The case AGAINST C supercat@casperkitty.com - 2018-05-08 16:17 -0700
Re: The case AGAINST C Geoff <geoff@invalid.invalid> - 2018-05-08 11:09 -0700
Re: The case AGAINST C David Brown <david.brown@hesbynett.no> - 2018-05-08 23:43 +0200
Re: The case AGAINST C supercat@casperkitty.com - 2018-05-08 15:24 -0700
Re: The case AGAINST C David Brown <david.brown@hesbynett.no> - 2018-05-09 00:58 +0200
Re: The case AGAINST C supercat@casperkitty.com - 2018-05-09 08:11 -0700
Re: The case AGAINST C Steve Carroll <frelwizzen@gmail.com> - 2018-05-09 08:51 -0700
Re: The case AGAINST C Steve Carroll <frelwizzen@gmail.com> - 2018-05-09 11:45 -0700
Re: The case AGAINST C Steve Carroll <frelwizzen@gmail.com> - 2018-05-09 13:03 -0700
Re: The case AGAINST C David Brown <david.brown@hesbynett.no> - 2018-05-09 23:40 +0200
Re: The case AGAINST C supercat@casperkitty.com - 2018-05-09 15:48 -0700
Re: The case AGAINST C David Brown <david.brown@hesbynett.no> - 2018-05-10 13:48 +0200
Re: The case AGAINST C supercat@casperkitty.com - 2018-05-10 08:28 -0700
Re: The case AGAINST C David Brown <david.brown@hesbynett.no> - 2018-05-11 10:06 +0200
Re: The case AGAINST C Steve Carroll <frelwizzen@gmail.com> - 2018-05-11 02:22 -0700
Re: The case AGAINST C Steve Carroll <frelwizzen@gmail.com> - 2018-05-11 05:29 -0700
Re: The case AGAINST C scott@slp53.sl.home (Scott Lurndal) - 2018-05-11 13:31 +0000
Re: The case AGAINST C David Brown <david.brown@hesbynett.no> - 2018-05-11 15:47 +0200
Re: The case AGAINST C supercat@casperkitty.com - 2018-05-11 09:16 -0700
Re: The case AGAINST C David Brown <david.brown@hesbynett.no> - 2018-05-12 17:43 +0200
Re: The case AGAINST C supercat@casperkitty.com - 2018-05-12 14:06 -0700
Re: The case AGAINST C Steve Carroll <frelwizzen@gmail.com> - 2018-05-10 00:13 -0700
Re: The case AGAINST C Steve Carroll <frelwizzen@gmail.com> - 2018-05-10 01:31 -0700
Re: The case AGAINST C Wouter Verhelst <w@uter.be> - 2018-05-11 18:01 +0200
Re: The case AGAINST C Geoff <geoff@invalid.invalid> - 2018-05-10 08:30 -0700
Re: The case AGAINST C Wouter Verhelst <w@uter.be> - 2018-05-09 09:29 +0200
Re: The case AGAINST C Geoff <geoff@invalid.invalid> - 2018-05-10 08:41 -0700
Re: The case AGAINST C Steve Carroll <frelwizzen@gmail.com> - 2018-05-11 04:43 -0700
Re: The case AGAINST C Richard Damon <Richard@Damon-Family.org> - 2018-05-08 21:24 -0400
Re: The case AGAINST C David Brown <david.brown@hesbynett.no> - 2018-05-09 09:10 +0200
Re: The case AGAINST C Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-05-08 19:52 +0000
Re: The case AGAINST C David Brown <david.brown@hesbynett.no> - 2018-05-08 23:48 +0200
Re: The case AGAINST C Tim Rentsch <txr@alumni.caltech.edu> - 2018-04-29 22:07 -0700
Re: The case AGAINST C bartc <bc@freeuk.com> - 2018-04-30 12:22 +0100
Re: The case AGAINST C Melzzzzz <Melzzzzz@zzzzz.com> - 2018-04-30 12:08 +0000
Re: The case AGAINST C bartc <bc@freeuk.com> - 2018-04-30 13:38 +0100
Re: The case AGAINST C Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-30 06:05 -0700
Re: The case AGAINST C supercat@casperkitty.com - 2018-04-30 07:39 -0700
Re: The case AGAINST C Ed Kellett <e@kellett.im> - 2018-04-30 15:53 +0100
Re: The case AGAINST C supercat@casperkitty.com - 2018-04-30 08:14 -0700
Re: The case AGAINST C Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-30 21:26 -0700
Re: The case AGAINST C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-04-30 09:00 -0700
Re: The case AGAINST C Steven Petruzzellis <frelwizzen@gmail.com> - 2018-05-01 04:58 -0700
Re: The case AGAINST C bartc <bc@freeuk.com> - 2018-04-30 18:07 +0100
Re: The case AGAINST C fir <profesor.fir@gmail.com> - 2018-05-01 05:33 -0700
Re: The case AGAINST C fir <profesor.fir@gmail.com> - 2018-05-01 05:58 -0700
Re: The case AGAINST C fir <profesor.fir@gmail.com> - 2018-05-01 06:27 -0700
Re: The case AGAINST C bartc <bc@freeuk.com> - 2018-05-01 14:37 +0100
Re: The case AGAINST C Melzzzzz <Melzzzzz@zzzzz.com> - 2018-05-01 13:41 +0000
Re: The case AGAINST C bartc <bc@freeuk.com> - 2018-05-01 16:48 +0100
Re: The case AGAINST C Steven Petruzzellis <frelwizzen@gmail.com> - 2018-05-01 10:11 -0700
Re: The case AGAINST C fir <profesor.fir@gmail.com> - 2018-05-01 11:00 -0700
Re: The case AGAINST C bartc <bc@freeuk.com> - 2018-05-01 19:26 +0100
Re: The case AGAINST C supercat@casperkitty.com - 2018-05-01 11:40 -0700
Re: The case AGAINST C fir <profesor.fir@gmail.com> - 2018-05-01 12:53 -0700
Re: The case AGAINST C bartc <bc@freeuk.com> - 2018-05-01 22:03 +0100
Re: The case AGAINST C Ian Collins <ian-news@hotmail.com> - 2018-05-02 09:10 +1200
Re: The case AGAINST C supercat@casperkitty.com - 2018-05-01 14:21 -0700
Re: The case AGAINST C Ian Collins <ian-news@hotmail.com> - 2018-05-02 09:26 +1200
Re: The case AGAINST C supercat@casperkitty.com - 2018-05-01 15:23 -0700
Re: The case AGAINST C scott@slp53.sl.home (Scott Lurndal) - 2018-05-02 14:07 +0000
Re: The case AGAINST C Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-05-03 06:28 +0000
Re: The case AGAINST C bartc <bc@freeuk.com> - 2018-05-01 23:03 +0100
Re: The case AGAINST C fir <profesor.fir@gmail.com> - 2018-05-02 04:52 -0700
Re: The case AGAINST C fir <profesor.fir@gmail.com> - 2018-05-02 05:12 -0700
Re: The case AGAINST C Steven Petruzzellis <frelwizzen@gmail.com> - 2018-05-02 05:34 -0700
Re: The case AGAINST C scott@slp53.sl.home (Scott Lurndal) - 2018-05-02 14:08 +0000
Re: The case AGAINST C Steven Petruzzellis <frelwizzen@gmail.com> - 2018-05-02 07:39 -0700
Re: The case AGAINST C bartc <bc@freeuk.com> - 2018-05-02 17:13 +0100
Re: The case AGAINST C Steven Petruzzellis <frelwizzen@gmail.com> - 2018-05-02 11:01 -0700
Re: The case AGAINST C bartc <bc@freeuk.com> - 2018-05-02 21:51 +0100
Re: The case AGAINST C Ian Collins <ian-news@hotmail.com> - 2018-05-03 08:52 +1200
Re: The case AGAINST C bartc <bc@freeuk.com> - 2018-05-02 22:42 +0100
Re: The case AGAINST C Ian Collins <ian-news@hotmail.com> - 2018-05-03 09:57 +1200
Re: The case AGAINST C bartc <bc@freeuk.com> - 2018-05-02 23:22 +0100
Re: The case AGAINST C Ian Collins <ian-news@hotmail.com> - 2018-05-03 10:29 +1200
Re: The case AGAINST C bartc <bc@freeuk.com> - 2018-05-03 00:14 +0100
Re: The case AGAINST C fir <profesor.fir@gmail.com> - 2018-05-03 03:59 -0700
Re: The case AGAINST C fir <profesor.fir@gmail.com> - 2018-05-03 04:15 -0700
Re: The case AGAINST C bartc <bc@freeuk.com> - 2018-05-03 12:50 +0100
Re: The case AGAINST C Steven Petruzzellis <frelwizzen@gmail.com> - 2018-05-03 13:36 -0700
Of course I get it... (Was: The case AGAINST C) gazelle@shell.xmission.com (Kenny McCormack) - 2018-05-03 08:44 +0000
Re: The case AGAINST C Dan Purgert <dan@djph.net> - 2018-05-03 12:42 +0000
Re: The case AGAINST C fir <profesor.fir@gmail.com> - 2018-05-03 05:52 -0700
Re: The case AGAINST C Dan Purgert <dan@djph.net> - 2018-05-03 12:56 +0000
Re: The case AGAINST C fir <profesor.fir@gmail.com> - 2018-05-03 05:58 -0700
Re: The case AGAINST C bartc <bc@freeuk.com> - 2018-05-03 14:36 +0100
Re: The case AGAINST C already5chosen@yahoo.com - 2018-05-03 13:27 -0700
Re: The case AGAINST C bartc <bc@freeuk.com> - 2018-05-03 22:43 +0100
Re: The case AGAINST C already5chosen@yahoo.com - 2018-05-03 15:17 -0700
Re: The case AGAINST C bartc <bc@freeuk.com> - 2018-05-04 00:50 +0100
Re: The case AGAINST C Steven Petruzzellis <frelwizzen@gmail.com> - 2018-05-03 15:41 -0700
Re: The case AGAINST C David Brown <david.brown@hesbynett.no> - 2018-05-04 11:36 +0200
Re: The case AGAINST C supercat@casperkitty.com - 2018-05-04 08:52 -0700
Re: The case AGAINST C scott@slp53.sl.home (Scott Lurndal) - 2018-05-04 17:28 +0000
Re: The case AGAINST C supercat@casperkitty.com - 2018-05-04 12:06 -0700
Re: The case AGAINST C David Brown <david.brown@hesbynett.no> - 2018-05-05 18:45 +0200
Re: The case AGAINST C scott@slp53.sl.home (Scott Lurndal) - 2018-05-06 18:43 +0000
Re: The case AGAINST C David Brown <david.brown@hesbynett.no> - 2018-05-06 23:35 +0200
Re: The case AGAINST C scott@slp53.sl.home (Scott Lurndal) - 2018-05-07 13:23 +0000
Re: The case AGAINST C Steve Carroll <frelwizzen@gmail.com> - 2018-05-07 06:30 -0700
Re: The case AGAINST C David Brown <david.brown@hesbynett.no> - 2018-05-07 16:25 +0200
Re: The case AGAINST C Steve Carroll <frelwizzen@gmail.com> - 2018-05-07 07:32 -0700
Re: The case AGAINST C Keith Thompson <kst-u@mib.org> - 2018-05-04 09:09 -0700
Re: The case AGAINST C bartc <bc@freeuk.com> - 2018-05-04 18:12 +0100
Global variables bartc <bc@freeuk.com> - 2018-05-06 14:07 +0100
Re: Global variables David Brown <david.brown@hesbynett.no> - 2018-05-06 20:03 +0200
Re: Global variables Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2018-05-06 15:21 -0400
Re: Global variables Keith Thompson <kst-u@mib.org> - 2018-05-06 13:07 -0700
Re: Global variables Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2018-05-06 16:13 -0400
Re: Global variables David Brown <david.brown@hesbynett.no> - 2018-05-06 23:39 +0200
Re: Global variables Richard Damon <Richard@Damon-Family.org> - 2018-05-06 17:50 -0400
Re: Global variables David Brown <david.brown@hesbynett.no> - 2018-05-06 23:57 +0200
Re: Global variables Richard Damon <Richard@Damon-Family.org> - 2018-05-06 19:56 -0400
Re: Global variables Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-05-07 03:21 +0100
Re: Global variables David Brown <david.brown@hesbynett.no> - 2018-05-07 09:09 +0200
Re: Global variables Keith Thompson <kst-u@mib.org> - 2018-05-07 08:49 -0700
Re: Global variables bartc <bc@freeuk.com> - 2018-05-06 20:55 +0100
Re: Global variables David Brown <david.brown@hesbynett.no> - 2018-05-06 23:51 +0200
Re: Global variables Keith Thompson <kst-u@mib.org> - 2018-05-06 15:40 -0700
Re: Global variables bartc <bc@freeuk.com> - 2018-05-06 23:54 +0100
Re: Global variables Ian Collins <ian-news@hotmail.com> - 2018-05-07 15:12 +1200
Re: Global variables David Brown <david.brown@hesbynett.no> - 2018-05-07 09:03 +0200
Re: Global variables Tim Rentsch <txr@alumni.caltech.edu> - 2018-05-18 20:23 -0700
Re: Global variables Steve Carroll <frelwizzen@gmail.com> - 2018-05-18 20:44 -0700
Re: Global variables David Brown <david.brown@hesbynett.no> - 2018-05-19 17:22 +0200
Re: Global variables supercat@casperkitty.com - 2018-05-19 11:56 -0700
Re: Global variables supercat@casperkitty.com - 2018-05-06 16:28 -0700
Re: Global variables Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2018-05-06 14:19 -0400
Re: Global variables bartc <bc@freeuk.com> - 2018-05-06 20:16 +0100
Re: Global variables David Brown <david.brown@hesbynett.no> - 2018-05-06 23:09 +0200
Re: Global variables bartc <bc@freeuk.com> - 2018-05-06 23:41 +0100
Re: The case AGAINST C Keith Thompson <kst-u@mib.org> - 2018-05-03 09:13 -0700
Re: The case AGAINST C Dan Purgert <dan@djph.net> - 2018-05-03 17:29 +0000
Re: The case AGAINST C gazelle@shell.xmission.com (Kenny McCormack) - 2018-05-03 19:24 +0000
Re: The case AGAINST C Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-05-04 05:46 +0000
Re: The case AGAINST C Dan Purgert <dan@djph.net> - 2018-05-04 10:55 +0000
Re: The case AGAINST C Steven Petruzzellis <frelwizzen@gmail.com> - 2018-05-04 04:03 -0700
Re: The case AGAINST C bartc <bc@freeuk.com> - 2018-05-04 12:31 +0100
Re: The case AGAINST C already5chosen@yahoo.com - 2018-05-04 05:10 -0700
Re: The case AGAINST C bartc <bc@freeuk.com> - 2018-05-04 13:24 +0100
Re: The case AGAINST C fir <profesor.fir@gmail.com> - 2018-05-04 06:26 -0700
Re: The case AGAINST C fir <profesor.fir@gmail.com> - 2018-05-04 06:35 -0700
Re: The case AGAINST C fir <profesor.fir@gmail.com> - 2018-05-04 07:06 -0700
Re: The case AGAINST C fir <profesor.fir@gmail.com> - 2018-05-04 07:19 -0700
Re: The case AGAINST C Steven Petruzzellis <frelwizzen@gmail.com> - 2018-05-04 06:37 -0700
Re: The case AGAINST C fir <profesor.fir@gmail.com> - 2018-05-04 08:19 -0700
Re: The case AGAINST C Steven Petruzzellis <frelwizzen@gmail.com> - 2018-05-04 12:07 -0700
Re: The case AGAINST C bartc <bc@freeuk.com> - 2018-05-04 16:31 +0100
Re: The case AGAINST C fir <profesor.fir@gmail.com> - 2018-05-04 08:41 -0700
Re: The case AGAINST C fir <profesor.fir@gmail.com> - 2018-05-04 09:50 -0700
Re: The case AGAINST C fir <profesor.fir@gmail.com> - 2018-05-04 10:04 -0700
Re: The case AGAINST C fir <profesor.fir@gmail.com> - 2018-05-04 13:51 -0700
Re: The case AGAINST C fir <profesor.fir@gmail.com> - 2018-05-04 14:30 -0700
Re: The case AGAINST C Steven Petruzzellis <frelwizzen@gmail.com> - 2018-05-04 15:14 -0700
Re: The case AGAINST C Robert Wessel <robertwessel2@yahoo.com> - 2018-05-04 11:18 -0500
Re: The case AGAINST C Keith Thompson <kst-u@mib.org> - 2018-05-04 09:05 -0700
Re: The case AGAINST C bartc <bc@freeuk.com> - 2018-05-04 17:55 +0100
Re: The case AGAINST C Keith Thompson <kst-u@mib.org> - 2018-05-04 10:54 -0700
Re: The case AGAINST C bartc <bc@freeuk.com> - 2018-05-04 19:18 +0100
Re: The case AGAINST C Keith Thompson <kst-u@mib.org> - 2018-05-04 11:24 -0700
Re: The case AGAINST C David Brown <david.brown@hesbynett.no> - 2018-05-06 16:45 +0200
Re: The case AGAINST C jameskuyper@alumni.caltech.edu - 2018-05-04 11:51 -0700
Re: The case AGAINST C supercat@casperkitty.com - 2018-05-04 12:15 -0700
Re: The case AGAINST C bartc <bc@freeuk.com> - 2018-05-04 21:56 +0100
Re: The case AGAINST C David Brown <david.brown@hesbynett.no> - 2018-05-06 17:01 +0200
Re: The case AGAINST C bartc <bc@freeuk.com> - 2018-05-06 17:54 +0100
Re: The case AGAINST C Keith Thompson <kst-u@mib.org> - 2018-05-06 13:38 -0700
Re: The case AGAINST C bartc <bc@freeuk.com> - 2018-05-06 21:49 +0100
Re: The case AGAINST C Richard Damon <Richard@Damon-Family.org> - 2018-05-06 17:19 -0400
Re: The case AGAINST C Keith Thompson <kst-u@mib.org> - 2018-05-06 15:24 -0700
Re: The case AGAINST C Keith Thompson <kst-u@mib.org> - 2018-05-06 15:16 -0700
Re: The case AGAINST C Steve Carroll <frelwizzen@gmail.com> - 2018-05-06 23:55 -0700
Re: The case AGAINST C Steve Carroll <frelwizzen@gmail.com> - 2018-05-06 11:59 -0700
Re: The case AGAINST C fir <profesor.fir@gmail.com> - 2018-05-01 14:51 -0700
Re: The case AGAINST C Steven Petruzzellis <frelwizzen@gmail.com> - 2018-05-02 04:46 -0700
Re: The case AGAINST C fir <profesor.fir@gmail.com> - 2018-05-01 11:45 -0700
Re: The case AGAINST C fir <profesor.fir@gmail.com> - 2018-05-01 06:10 -0700
Re: The case AGAINST C C W Rose <cwr@seckford.org> - 2018-05-02 15:23 +0100
Re: The case AGAINST C bartc <bc@freeuk.com> - 2018-05-02 17:36 +0100
Re: The case AGAINST C "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2018-04-30 22:03 +0800
Re: The case AGAINST C Jens Stuckelberger <Jens_Stuckelberger@nowhere.net> - 2018-05-01 13:46 +0000
Page 6 of 11 — ← Prev page 1 … 4 5 [6] 7 8 … 11 Next page →
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-05-02 23:22 +0100 |
| Message-ID | <RSqGC.80267$6A2.3553@fx21.am4> |
| In reply to | #130056 |
On 02/05/2018 22:57, Ian Collins wrote: > On 05/03/2018 09:42 AM, bartc wrote: >> >> The current version is targetted at applications that run under Windows. > > That says it all really, doesn't it? You don't get it do you? One of the big problems with C is all this #include nonsense. A modern approach to #includes is the use of 'import' together with the concept of modules. My language happens to have 'import'. But because it only runs on one machine (with an obscure architecture called x64 running a little known OS called 'Windows'), that somehow makes the problems with #include alright? My complaints about C would be valid even if my language didn't exist. That fact that I have actually implemented alternative solutions, means that at least I know what I'm talking about. (How are C++ modules coming along by the way?)
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2018-05-03 10:29 +1200 |
| Message-ID | <fkuse4Fl1fsU3@mid.individual.net> |
| In reply to | #130057 |
On 05/03/2018 10:22 AM, bartc wrote: > On 02/05/2018 22:57, Ian Collins wrote: >> On 05/03/2018 09:42 AM, bartc wrote: >>> >>> The current version is targetted at applications that run under Windows. >> >> That says it all really, doesn't it? > > You don't get it do you? Sure I do... > One of the big problems with C is all this #include nonsense. Nearly all of the "nonsense" you whinge about would go away if C were only targeted at one platform. -- Ian
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-05-03 00:14 +0100 |
| Message-ID | <QCrGC.151751$nr7.103545@fx31.am4> |
| In reply to | #130058 |
On 02/05/2018 23:29, Ian Collins wrote: > On 05/03/2018 10:22 AM, bartc wrote: >> On 02/05/2018 22:57, Ian Collins wrote: >>> On 05/03/2018 09:42 AM, bartc wrote: >>>> >>>> The current version is targetted at applications that run under >>>> Windows. >>> >>> That says it all really, doesn't it? >> >> You don't get it do you? > > Sure I do... > >> One of the big problems with C is all this #include nonsense. > > Nearly all of the "nonsense" you whinge about would go away if C were > only targeted at one platform. And this is pure nonsense on your part. We're talking about a HLL not assembly. (As though targetting one platform would make that convoluted type syntax go away!) (As a matter of interest, many platforms did the first C implementation run on? Because I'm sure most of its design defects were there from the start.) But this is clearly futile. /You/ have to use C or C++ because you have to. And reasonably enough you don't want to admit that anything could possibly be wrong with it, and have to resort to belittle the opinions and work of others. Others who have the nous to see the problems and the skill to create practical alternatives. But, have the last word if you want. I at least have a real choice.
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2018-05-03 03:59 -0700 |
| Message-ID | <1e62021c-a6a4-40b6-8ae5-8cac2a19d26a@googlegroups.com> |
| In reply to | #130059 |
W dniu czwartek, 3 maja 2018 01:13:59 UTC+2 użytkownik Bart napisał: > On 02/05/2018 23:29, Ian Collins wrote: > > On 05/03/2018 10:22 AM, bartc wrote: > >> On 02/05/2018 22:57, Ian Collins wrote: > >>> On 05/03/2018 09:42 AM, bartc wrote: > >>>> > >>>> The current version is targetted at applications that run under > >>>> Windows. > >>> > >>> That says it all really, doesn't it? > >> > >> You don't get it do you? > > > > Sure I do... > > > >> One of the big problems with C is all this #include nonsense. > > > > Nearly all of the "nonsense" you whinge about would go away if C were > > only targeted at one platform. > > And this is pure nonsense on your part. We're talking about a HLL not > assembly. (As though targetting one platform would make that convoluted > type syntax go away!) > > (As a matter of interest, many platforms did the first C implementation > run on? Because I'm sure most of its design defects were there from the > start.) > > But this is clearly futile. /You/ have to use C or C++ because you have > to. And reasonably enough you don't want to admit that anything could > possibly be wrong with it, and have to resort to belittle the opinions > and work of others. > > Others who have the nous to see the problems and the skill to create > practical alternatives. > > But, have the last word if you want. I at least have a real choice. let me yet once say what i see as a pathologi in you: you take some "core theses" (which are right, (like headers are not much fortunate and build systems are not much fortunate)) and 1) you stete it like humanity would oppose tio that and you would be a preacher on them (you should know at least imo that i for example was saying "headers are bad" too (more to say probably quite earlier, at least i remember it like this... becouse note whan i was saing here the headers are bad years ago nobody then stated or discussed on that - including you ;c) 1b) (other thing you shouldnt do is to assume people disagree with you, roughly anybody will agree i think that build systems used in c grant a lots of troubles) 2) then yet you attach some other theses (attachements) ehich are false (like c is crap and much more in sorta implicit form) and add it to it and preach it together i for example then coant agree with you as you then say stuopid things (based on those core right theses) and then you go in infinite (i mean long) loop of repeating that and fighting with imaginary opponents - i say imaginary becouse you alone create this confrontative state... like man saying "2+2=4" enveloped in something a bit false, and searhing anybody that could dsagree with this to repeatedly troll them (fight with them) for some example: as i said your 'adventures' in world of compilaton of projects from the net may have some value as an example but inte same wise 1) its not only you who noticed and know thet it is something wrong with it (thus fighting like youre only one which know that is serious mistake) 2) this is not strightly c fault as c not encompases that things like universal project file or universal build language isnt it better to state things clearly state tru things and not fight as stuopidly on it as you do it (becouse this fighting is sorta like psychicaly unmature trolling when people started to point it tou you (or something close) i noticed they are sorta right at this point... and i say that becouse this sorta like hodgin trolling may be annoying and makes this group a bit crazy and boring where sanity could be a bit better possibly i possibly also could talk with you but not when you troll the world
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2018-05-03 04:15 -0700 |
| Message-ID | <aed62a7f-4dd6-438b-980f-3b5b3fd9a4eb@googlegroups.com> |
| In reply to | #130068 |
more to say what i may add what i see as a more serious problem: those topics have some 'educational' value (as they are on educational plane) but the real problem is 1) the coefficient of usability of it is too low (it takes too much taime to get to conclusions.. bilion of posts to take 3 conclusions.. it wastes time to much, people gets old ) 2) c has other great planes that are left untouched (productivnes, creativness) here - and thats damn problem .. i realized that its a problem and started to search for answer some years ago (like 3?) .. still got no solution (seeing the problem is hovever the begining, y know what i mean) (got no solution but got some 'suggestion' suggestion is to get into more productive and creative topics as far its possible.. this group hovever dont supports it at all)
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-05-03 12:50 +0100 |
| Message-ID | <zHCGC.160685$Cd3.146635@fx33.am4> |
| In reply to | #130069 |
On 03/05/2018 12:15, fir wrote: > more to say what i may add what i see as a more serious problem: > > those topics have some 'educational' value (as they are on educational plane) but the real problem is > 1) the coefficient of usability of it is too low (it takes too much taime to get to conclusions.. bilion of posts to take 3 conclusions.. it wastes time to much, people gets old ) > > 2) c has other great planes that are left untouched (productivnes, creativness) here - and thats damn problem .. i realized that its a problem and started to search for answer some years ago (like 3?) .. still got no solution (seeing the problem is hovever the begining, y know what i mean) > > (got no solution but got some 'suggestion' suggestion is to get into more productive and creative topics as far its possible.. this group hovever dont supports it at all) Most of usenet is dead and this group is most of the way there. At times I think it was just me, supercat and you (when you used to post more) keeping it going. (And Rick, but on the wrong topics.) (There's also a chap called Petruzzellis who has started large numbers of spurious threads, if you're unfortunate enough to use Google Groups and get to see the posts.) There are other forums but they're web-based with logins and passwords, and can be more of a pain to use.
[toc] | [prev] | [next] | [standalone]
| From | Steven Petruzzellis <frelwizzen@gmail.com> |
|---|---|
| Date | 2018-05-03 13:36 -0700 |
| Message-ID | <af6cdefe-11e5-43a6-a733-c4bca7b5172f@googlegroups.com> |
| In reply to | #130068 |
On Thursday, May 3, 2018 at 3:59:59 AM UTC-7, fir wrote: > W dniu czwartek, 3 maja 2018 01:13:59 UTC+2 użytkownik Bart napisał: > > On 02/05/2018 23:29, Ian Collins wrote: > > > On 05/03/2018 10:22 AM, bartc wrote: > > >> On 02/05/2018 22:57, Ian Collins wrote: > > >>> On 05/03/2018 09:42 AM, bartc wrote: > > >>>> > > >>>> The current version is targetted at applications that run under > > >>>> Windows. > > >>> > > >>> That says it all really, doesn't it? > > >> > > >> You don't get it do you? > > > > > > Sure I do... > > > > > >> One of the big problems with C is all this #include nonsense. > > > > > > Nearly all of the "nonsense" you whinge about would go away if C were > > > only targeted at one platform. > > > > And this is pure nonsense on your part. We're talking about a HLL not > > assembly. (As though targetting one platform would make that convoluted > > type syntax go away!) > > > > (As a matter of interest, many platforms did the first C implementation > > run on? Because I'm sure most of its design defects were there from the > > start.) > > > > But this is clearly futile. /You/ have to use C or C++ because you have > > to. And reasonably enough you don't want to admit that anything could > > possibly be wrong with it, and have to resort to belittle the opinions > > and work of others. > > > > Others who have the nous to see the problems and the skill to create > > practical alternatives. > > > > But, have the last word if you want. I at least have a real choice. > > let me yet once say what i see as a pathologi in you: > > you take some "core theses" (which are right, (like headers are not much fortunate > and build systems are not much fortunate)) > and > 1) you stete it like humanity would oppose tio that and you would be a preacher on them > (you should know at least imo that i for example was saying "headers are bad" too (more to say probably quite earlier, at least i remember it like this... becouse note whan i was saing here the headers are bad years ago nobody then stated or discussed on that - including you ;c) > 1b) (other thing you shouldnt do is to assume people disagree with you, roughly anybody will agree i think that build systems used in c grant a lots of troubles) > 2) then yet you attach some other theses (attachements) ehich are false (like c is crap and much more in sorta implicit form) and add it to it and preach it together > > i for example then coant agree with you as > you then say stuopid things (based on those core right theses) and then you go in infinite (i mean long) loop of repeating that and fighting with imaginary opponents - i say imaginary becouse you alone create this confrontative state... like man saying "2+2=4" enveloped in something a bit false, and searhing anybody that could dsagree with this to repeatedly troll them (fight with them) > > for some example: > as i said your 'adventures' in world of compilaton of projects from the net may have some value as an example but inte same > wise > > 1) its not only you who noticed and know thet it is something wrong with it (thus fighting like youre only one which know that is serious mistake) > > 2) this is not strightly c fault as c not encompases that things like universal project file or universal build language > > isnt it better to state things clearly state tru things and not fight as stuopidly on it as you do it (becouse this fighting is sorta like psychicaly unmature trolling > > when people started to point it tou you (or something close) i noticed they are sorta right at this point... and i say that becouse this sorta like hodgin trolling may be annoying and makes this group a bit crazy and boring where sanity could be a bit better possibly > > i possibly also could talk with you but not when you troll the world Effectively everything David Empson says about anyone is dishonest as everyone knows. Not only did Manfred's question not mention the "GPL", it has _nothing_ to do with the desktop. David Empson should stop mixing red and blue pills ;) Too much glue for you, Gluey. Gee, imagine David Empson trying to pin his rubbish on me or others, no one has ever seen that before <shrug>. These posts are clearly NOT automated, they are made by a glue sniffing stalker with an axe to grind who has way too much time on his hands (with maybe some scripted pre-processing). - Live on Kickstarter http://www.5z8.info/killallimmigrants_j6f7mm_gruesome-gunshot-wounds https://groups.google.com/forum/#!topic/comp.os.linux.advocacy/smzXrBhsWf4 https://youtu.be/HHT9SJgYsH4 Jonas Eklundh Communication
[toc] | [prev] | [next] | [standalone]
| From | gazelle@shell.xmission.com (Kenny McCormack) |
|---|---|
| Date | 2018-05-03 08:44 +0000 |
| Subject | Of course I get it... (Was: The case AGAINST C) |
| Message-ID | <pcei54$chm$1@news.xmission.com> |
| In reply to | #130058 |
In article <fkuse4Fl1fsU3@mid.individual.net>, Ian Collins <ian-news@hotmail.com> wrote: >On 05/03/2018 10:22 AM, bartc wrote: >> On 02/05/2018 22:57, Ian Collins wrote: >>> On 05/03/2018 09:42 AM, bartc wrote: >>>> >>>> The current version is targetted at applications that run under Windows. >>> >>> That says it all really, doesn't it? >> >> You don't get it do you? > >Sure I do... There was this time, back in 1987 I think, where somebody on Usenet asserted that someone else "didn't get it", and that person admitted that, no, they didn't. Hasn't happened since, of course... -- The randomly chosen signature file that would have appeared here is more than 4 lines long. As such, it violates one or more Usenet RFCs. In order to remain in compliance with said RFCs, the actual sig can be found at the following URL: http://user.xmission.com/~gazelle/Sigs/RepInsults
[toc] | [prev] | [next] | [standalone]
| From | Dan Purgert <dan@djph.net> |
|---|---|
| Date | 2018-05-03 12:42 +0000 |
| Message-ID | <slrnpem0sv.jmn.dan@xps-linux.djph.net> |
| In reply to | #130057 |
bartc wrote: > On 02/05/2018 22:57, Ian Collins wrote: >> On 05/03/2018 09:42 AM, bartc wrote: >>> >>> The current version is targetted at applications that run under Windows. >> >> That says it all really, doesn't it? > > You don't get it do you? > > One of the big problems with C is all this #include nonsense. > > A modern approach to #includes is the use of 'import' together with the > concept of modules. How is "import <some_module>" any different than "#include <some_module>"? -- |_|O|_| Registered Linux user #585947 |_|_|O| Github: https://github.com/dpurgert |O|O|O| PGP: 05CA 9A50 3F2E 1335 4DC5 4AEE 8E11 DDF3 1279 A281
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2018-05-03 05:52 -0700 |
| Message-ID | <ef5d98b7-b5df-4cb8-9670-50d864fe4efa@googlegroups.com> |
| In reply to | #130074 |
W dniu czwartek, 3 maja 2018 14:42:16 UTC+2 użytkownik Dan Purgert napisał: > bartc wrote: > > On 02/05/2018 22:57, Ian Collins wrote: > >> On 05/03/2018 09:42 AM, bartc wrote: > >>> > >>> The current version is targetted at applications that run under Windows. > >> > >> That says it all really, doesn't it? > > > > You don't get it do you? > > > > One of the big problems with C is all this #include nonsense. > > > > A modern approach to #includes is the use of 'import' together with the > > concept of modules. > > How is "import <some_module>" any different than "#include > <some_module>"? > dont ask stupid questions (there should be a limit of stupidity on this forum - and it is constantly breakd) in real life when you divide code on modules and work with that (which is worth doin) all the trouble of keeping headers up to date (besided aditional trouble and complication to manage headers) is real big, this is a lot of unnecessary work (real lot)
[toc] | [prev] | [next] | [standalone]
| From | Dan Purgert <dan@djph.net> |
|---|---|
| Date | 2018-05-03 12:56 +0000 |
| Message-ID | <slrnpem1nh.jmn.dan@xps-linux.djph.net> |
| In reply to | #130076 |
fir wrote: > W dniu czwartek, 3 maja 2018 14:42:16 UTC+2 użytkownik Dan Purgert napisał: >> bartc wrote: >> > On 02/05/2018 22:57, Ian Collins wrote: >> >> On 05/03/2018 09:42 AM, bartc wrote: >> >>> >> >>> The current version is targetted at applications that run under Windows. >> >> >> >> That says it all really, doesn't it? >> > >> > You don't get it do you? >> > >> > One of the big problems with C is all this #include nonsense. >> > >> > A modern approach to #includes is the use of 'import' together with the >> > concept of modules. >> >> How is "import <some_module>" any different than "#include >> <some_module>"? >> > dont ask stupid questions (there should be a limit of stupidity on > this forum - and it is constantly breakd) Just to keep the stupid going then - why can't you write sanely for Usenet? > > in real life when you divide code on modules and work with that (which > is worth doin) all the trouble of keeping headers up to date (besided > aditional trouble and complication to manage headers) is real big, > this is a lot of unnecessary work (real lot) All I'm reading is "because I'm lazy". -- |_|O|_| Registered Linux user #585947 |_|_|O| Github: https://github.com/dpurgert |O|O|O| PGP: 05CA 9A50 3F2E 1335 4DC5 4AEE 8E11 DDF3 1279 A281
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2018-05-03 05:58 -0700 |
| Message-ID | <140a7011-6f75-4ba9-8710-ac985b25632c@googlegroups.com> |
| In reply to | #130077 |
W dniu czwartek, 3 maja 2018 14:56:26 UTC+2 użytkownik Dan Purgert napisał: > fir wrote: > > W dniu czwartek, 3 maja 2018 14:42:16 UTC+2 użytkownik Dan Purgert napisał: > >> bartc wrote: > >> > On 02/05/2018 22:57, Ian Collins wrote: > >> >> On 05/03/2018 09:42 AM, bartc wrote: > >> >>> > >> >>> The current version is targetted at applications that run under Windows. > >> >> > >> >> That says it all really, doesn't it? > >> > > >> > You don't get it do you? > >> > > >> > One of the big problems with C is all this #include nonsense. > >> > > >> > A modern approach to #includes is the use of 'import' together with the > >> > concept of modules. > >> > >> How is "import <some_module>" any different than "#include > >> <some_module>"? > >> > > dont ask stupid questions (there should be a limit of stupidity on > > this forum - and it is constantly breakd) > > Just to keep the stupid going then - why can't you write sanely for > Usenet? > > > > > in real life when you divide code on modules and work with that (which > > is worth doin) all the trouble of keeping headers up to date (besided > > aditional trouble and complication to manage headers) is real big, > > this is a lot of unnecessary work (real lot) > > All I'm reading is "because I'm lazy". > then youre imbecile.. (scary, isnt it?)
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-05-03 14:36 +0100 |
| Message-ID | <ffEGC.34377$U32.22742@fx04.am4> |
| In reply to | #130074 |
On 03/05/2018 13:42, Dan Purgert wrote:
> bartc wrote:
>> On 02/05/2018 22:57, Ian Collins wrote:
>>> On 05/03/2018 09:42 AM, bartc wrote:
>>>>
>>>> The current version is targetted at applications that run under Windows.
>>>
>>> That says it all really, doesn't it?
>>
>> You don't get it do you?
>>
>> One of the big problems with C is all this #include nonsense.
>>
>> A modern approach to #includes is the use of 'import' together with the
>> concept of modules.
>
> How is "import <some_module>" any different than "#include
> <some_module>"?
They couldn't be more different.
Usually C modules are divided into .h files and .c files.
You would include that .h file, not the module. And #include just
incorporates the text from the .h into the text of this translation
unit. There is no separate scope associated with it.
Being text, the meanings of the declarations in the .h file could vary
depend on what has already been encountered.
Nothing stops you including the same .h header file 20 times, and so
many header files have messy #ifdef guards to prevent this.
Header files can also include other header files. (Use #include
<windows.h> with MS' windows.h, and there are 650 nested includes
performed, although not all unique.)
The file part of the #include line can involve a relative or absolute
file path, which can interact with the location of the current module,
the current include file, the current directory, and the set of include
paths to search, in complex ways. Using either "..." or <...> can also
change the way the search is done.
Usually also, a module has to #include its own header (as it needs the
contained declarations).
The order of #includes may be important, because if B.h needs a
declaration in A.h, A.h must be included first. Sometimes, B.h will
#include A.h itself, but then the main module M.c will itself include
A.h, then B.h, and this is how duplicate headers can occur.
The way that C declares exported and imported names doesn't help either:
int abc; // in A.h
-------------
#include <a.h> // in A.c
int main (void) {
printf("%d",abc)';
}
--------------
#include <a.h> // in B.c
When A.c is compiled, the 'int abc;' is taken to be a exported from
module A.c. But when B.c is compiled, abc is still exported! Because
it's seeing exactly the same definition.
You can 'extern int abc;', but now both modules will apparently export
it! Sometimes a linker will sort this out and create just one shared
version.
There are problems also when you /do/ want to export the same name, but
different object, from different modules; C can't do this without renaming.
So, the #include/header system is a mess.
=============================================================
Now look a proper imports, as used in my language (or for something
mainstream, look at how Python imports work, which are not too different).
Here, there are no headers, only modules. If module X wants to use the
stuff exported from A, it will do:
import A
Then the compiler will do whatever it has to do to obtain the exported
names from A.m (.m is the source extension). It is not crude textual
insertion.
Importing A twice is no problem. Doing this:
import A
import B
when A itself imports B, is not a problem either. The order here is not
important. (If A needs B, it will import it itself, but that doesn't
affect what happens here.)
Inside A.m, I might have:
global int abc
if I want to export that. In X, I can refer to it as 'abc' just by
having 'import A'. (If both A and B export 'abc', then I might need to
use A.abc and B.abc to disambiguate.)
For imports, the A or B is not a file-spec; it is a name. It will locate
the module using a far simpler search method than for include files.
In other words, this is a more grown-up way of doing this stuff. You
really wouldn't want to go back to headers.
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | already5chosen@yahoo.com |
|---|---|
| Date | 2018-05-03 13:27 -0700 |
| Message-ID | <a8d6ecb8-b71b-4e09-a43b-5da049373ab1@googlegroups.com> |
| In reply to | #130081 |
On Thursday, May 3, 2018 at 4:36:24 PM UTC+3, Bart wrote:
> On 03/05/2018 13:42, Dan Purgert wrote:
> > bartc wrote:
> >> On 02/05/2018 22:57, Ian Collins wrote:
> >>> On 05/03/2018 09:42 AM, bartc wrote:
> >>>>
> >>>> The current version is targetted at applications that run under Windows.
> >>>
> >>> That says it all really, doesn't it?
> >>
> >> You don't get it do you?
> >>
> >> One of the big problems with C is all this #include nonsense.
> >>
> >> A modern approach to #includes is the use of 'import' together with the
> >> concept of modules.
> >
> > How is "import <some_module>" any different than "#include
> > <some_module>"?
>
> They couldn't be more different.
>
> Usually C modules are divided into .h files and .c files.
>
> You would include that .h file, not the module. And #include just
> incorporates the text from the .h into the text of this translation
> unit. There is no separate scope associated with it.
>
> Being text, the meanings of the declarations in the .h file could vary
> depend on what has already been encountered.
>
> Nothing stops you including the same .h header file 20 times, and so
> many header files have messy #ifdef guards to prevent this.
>
> Header files can also include other header files. (Use #include
> <windows.h> with MS' windows.h, and there are 650 nested includes
> performed, although not all unique.)
>
> The file part of the #include line can involve a relative or absolute
> file path, which can interact with the location of the current module,
> the current include file, the current directory, and the set of include
> paths to search, in complex ways. Using either "..." or <...> can also
> change the way the search is done.
>
> Usually also, a module has to #include its own header (as it needs the
> contained declarations).
>
> The order of #includes may be important, because if B.h needs a
> declaration in A.h, A.h must be included first. Sometimes, B.h will
> #include A.h itself, but then the main module M.c will itself include
> A.h, then B.h, and this is how duplicate headers can occur.
>
> The way that C declares exported and imported names doesn't help either:
>
> int abc; // in A.h
> -------------
> #include <a.h> // in A.c
> int main (void) {
> printf("%d",abc)';
> }
> --------------
> #include <a.h> // in B.c
>
>
> When A.c is compiled, the 'int abc;' is taken to be a exported from
> module A.c. But when B.c is compiled, abc is still exported! Because
> it's seeing exactly the same definition.
>
> You can 'extern int abc;', but now both modules will apparently export
> it! Sometimes a linker will sort this out and create just one shared
> version.
>
> There are problems also when you /do/ want to export the same name, but
> different object, from different modules; C can't do this without renaming.
>
> So, the #include/header system is a mess.
>
> =============================================================
>
> Now look a proper imports, as used in my language (or for something
> mainstream, look at how Python imports work, which are not too different).
>
> Here, there are no headers, only modules. If module X wants to use the
> stuff exported from A, it will do:
>
> import A
>
> Then the compiler will do whatever it has to do to obtain the exported
> names from A.m (.m is the source extension). It is not crude textual
> insertion.
>
> Importing A twice is no problem. Doing this:
>
> import A
> import B
>
> when A itself imports B, is not a problem either. The order here is not
> important. (If A needs B, it will import it itself, but that doesn't
> affect what happens here.)
>
> Inside A.m, I might have:
>
> global int abc
>
> if I want to export that. In X, I can refer to it as 'abc' just by
> having 'import A'. (If both A and B export 'abc', then I might need to
> use A.abc and B.abc to disambiguate.)
>
> For imports, the A or B is not a file-spec; it is a name. It will locate
> the module using a far simpler search method than for include files.
>
> In other words, this is a more grown-up way of doing this stuff. You
> really wouldn't want to go back to headers.
>
> --
> bartc
Two questions:
1. How does your compiler know where to look for a module A?
I'd guess, you have some sort of "project file" to tell it.
If yes, in which language it (a project file) is written? The same as language that is used to write modules themselves or something different?
2. What about separation of interface from implementation? Do you, similarly James Gosling and Anders Hejlsberg, consider this feature unimportant,
Pay attention that I am not asking "What about separate compilation?".
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-05-03 22:43 +0100 |
| Message-ID | <DnLGC.154427$jZ.130106@fx20.am4> |
| In reply to | #130105 |
On 03/05/2018 21:27, already5chosen@yahoo.com wrote: > On Thursday, May 3, 2018 at 4:36:24 PM UTC+3, Bart wrote: >> Now look [at] proper imports, as used in my language (or for something >> mainstream, look at how Python imports work, which are not too different). > Two questions: > 1. How does your compiler know where to look for a module A? > I'd guess, you have some sort of "project file" to tell it. How does it work in any other language, like Python? Mine uses a list of search paths, and usually the default set (location of source module, "." if different, compiler install location) suffices. > If yes, in which language it (a project file) is written? The same as language that is used to write modules themselves or something different? There is a project file, but that's for the benefit of my IDE. And it's not a language, it's little more than a list of modules (I've posted an example a few days ago). The compiler does not use it. Depending on how sophisticated it is, it might be able to work things out for itself. Here's one such in action: c:\mxold>qc mc Q Compiler 12.1 Compiling mc.q to mc.pc mq.q is the lead module of a 20-module, 24Kloc application. It will locate all required modules, and compile them in the right order. This process takes 0.05 seconds on this unoptimised byte-code compiler. The output is a single byte-code file for the entire application. Otherwise the compiler is invoked for each module in turn. (In this case, the implementation of modules is cruder, and requires they are compiled in a specific order. This is what I'm fixing at the minute.) > > 2. What about separation of interface from implementation? Do you, similarly James Gosling and Anders Hejlsberg, consider this feature unimportant, The way it works in the older compiler above, is that when a module is compiled, it automatically generates an exports file, containing all the declarations that are shared or exported from it. This is roughly equivalent to a header file. When the module is imported by another module, that small exports file (not the module) is processed. This readable exports file forms the interface, one that is generated automatically (I used to put doc-strings in there too). (The new compiler will be a whole-project compiler and will do away with such intermediate files. But the requirement for a discrete interface file is likely to arise again when an application as a whole is intended to form a library to be used from other programs in the same language.) -- bartc
[toc] | [prev] | [next] | [standalone]
| From | already5chosen@yahoo.com |
|---|---|
| Date | 2018-05-03 15:17 -0700 |
| Message-ID | <da10e85a-9fef-4c00-b8d7-37b69950dd40@googlegroups.com> |
| In reply to | #130111 |
On Friday, May 4, 2018 at 12:43:07 AM UTC+3, Bart wrote: > On 03/05/2018 21:27, already5chosen@yahoo.com wrote: > > On Thursday, May 3, 2018 at 4:36:24 PM UTC+3, Bart wrote: > > >> Now look [at] proper imports, as used in my language (or for something > >> mainstream, look at how Python imports work, which are not too different). > > > Two questions: > > 1. How does your compiler know where to look for a module A? > > I'd guess, you have some sort of "project file" to tell it. > > How does it work in any other language, like Python? > Python uses "hard" naming conventions. The module foo corresponds to file foo.py in the current directory or in other directories on the search path. That is very practical. but not very flexible. If one has several implementations of the same module and wants to experiment, he has several solutions, all of them unsatisfactory. The least bad is probably renaming at file system level. Sounds o.k as long as one does not consider implication to VCS. Renames tend to be the weakest spot of majority of VCSs. > Mine uses a list of search paths, and usually the default set (location > of source module, "." if different, compiler install location) suffices. > > > If yes, in which language it (a project file) is written? The same as language that is used to write modules themselves or something different? > > There is a project file, but that's for the benefit of my IDE. And it's > not a language, it's little more than a list of modules (I've posted an > example a few days ago). > > The compiler does not use it. Depending on how sophisticated it is, it > might be able to work things out for itself. Here's one such in action: > > c:\mxold>qc mc > Q Compiler 12.1 > Compiling mc.q to mc.pc > > mq.q is the lead module of a 20-module, 24Kloc application. It will > locate all required modules, and compile them in the right order. This > process takes 0.05 seconds on this unoptimised byte-code compiler. The > output is a single byte-code file for the entire application. > > Otherwise the compiler is invoked for each module in turn. (In this > case, the implementation of modules is cruder, and requires they are > compiled in a specific order. This is what I'm fixing at the minute.) Sounds similar to python. > > > > > 2. What about separation of interface from implementation? Do you, similarly James Gosling and Anders Hejlsberg, consider this feature unimportant, > > The way it works in the older compiler above, is that when a module is > compiled, it automatically generates an exports file, containing all the > declarations that are shared or exported from it. This is roughly > equivalent to a header file. > Sounds reasonable, > When the module is imported by another module, that small exports file > (not the module) is processed. > That's an implementation detail. Not really important if compiler is very fast or if there is no intention to build monster apps. > This readable exports file forms the interface, one that is generated > automatically (I used to put doc-strings in there too). > What do you mean by "used to" ? I think, if you goes this path then ability to transfer comments from module to the interface is mandatory. > (The new compiler will be a whole-project compiler and will do away with > such intermediate files. But the requirement for a discrete interface > file is likely to arise again when an application as a whole is intended > to form a library to be used from other programs in the same language.) > Interface files are far more important for human consumption than for machine consumption. Unless your language is not intended to be used outside of IDE, which, IMHO, would be a serious limitation (I mean, it sucks) for compiled language, but it's o.k. if the main use case is an interactive interpreter (like Matlab/Octave). > > -- > bartc
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-05-04 00:50 +0100 |
| Message-ID | <DeNGC.89087$Z64.55287@fx36.am4> |
| In reply to | #130112 |
On 03/05/2018 23:17, already5chosen@yahoo.com wrote: > On Friday, May 4, 2018 at 12:43:07 AM UTC+3, Bart wrote: > Python uses "hard" naming conventions. > The module foo corresponds to file foo.py in the current directory or in > other directories on the search path. > That is very practical. but not very flexible. > If one has several implementations of the same module and wants to experiment, Different installations of Python are enough of a problem! > he has several solutions, all of them unsatisfactory. The least bad is probably renaming at file system level. Sounds o.k as long as one does not consider implication to VCS. Renames tend to be the weakest spot of majority of VCSs. I use module renaming (within the compiler) in some situations. For example: import oslib oslib may be mapped to "windows" or "linux" depending on target OS. For this purpose, some module names are special. (My compilers are also heading towards compact one-file implementations. Then, modules which are standard libraries may reside inside the compiler executable and don't need locating, although it's possible to override. But this way the libraries are always the right versions.) >> When the module is imported by another module, that small exports file >> (not the module) is processed. >> > That's an implementation detail. Not really important if compiler is very fast or if there is no intention to build monster apps. (I'm converting the third of three compilers to a high-speed version. They tend to run at around 0.5 million lines per second on my PC. They will also be whole-project compilers, which means that once committed to that, they can /only/ build an entire project, so the speed is important. At 0.5Mlps, apps up to 100Kloc should be compilable from scratch with no noticeable delay. These speeds don't relay on an optimising C compiler either...) >> This readable exports file forms the interface, one that is generated >> automatically (I used to put doc-strings in there too). >> > > What do you mean by "used to" ? > I think, if you goes this path then ability to transfer comments from module to the interface is mandatory. The compiler that did that was changed to a whole-project one. Then intermediate textual export files were not needed. But since it can be useful for documentation purposes, it's possible the exports files can still be optionally generated for use as readable interface files. It can already generate a single-file composite of all source files used by a project, which includes a module summary. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Steven Petruzzellis <frelwizzen@gmail.com> |
|---|---|
| Date | 2018-05-03 15:41 -0700 |
| Message-ID | <88b6e38b-278a-423d-9887-79665a7a4881@googlegroups.com> |
| In reply to | #130111 |
On Thursday, May 3, 2018 at 2:43:07 PM UTC-7, Bart wrote: > On 03/05/2018 21:27, already5chosen@yahoo.com wrote: > > On Thursday, May 3, 2018 at 4:36:24 PM UTC+3, Bart wrote: > > >> Now look [at] proper imports, as used in my language (or for something > >> mainstream, look at how Python imports work, which are not too different). > > > Two questions: > > 1. How does your compiler know where to look for a module A? > > I'd guess, you have some sort of "project file" to tell it. > > How does it work in any other language, like Python? > > Mine uses a list of search paths, and usually the default set (location > of source module, "." if different, compiler install location) suffices. > > > If yes, in which language it (a project file) is written? The same as language that is used to write modules themselves or something different? > > There is a project file, but that's for the benefit of my IDE. And it's > not a language, it's little more than a list of modules (I've posted an > example a few days ago). > > The compiler does not use it. Depending on how sophisticated it is, it > might be able to work things out for itself. Here's one such in action: > > c:\mxold>qc mc > Q Compiler 12.1 > Compiling mc.q to mc.pc > > mq.q is the lead module of a 20-module, 24Kloc application. It will > locate all required modules, and compile them in the right order. This > process takes 0.05 seconds on this unoptimised byte-code compiler. The > output is a single byte-code file for the entire application. > > Otherwise the compiler is invoked for each module in turn. (In this > case, the implementation of modules is cruder, and requires they are > compiled in a specific order. This is what I'm fixing at the minute.) > > > > > 2. What about separation of interface from implementation? Do you, similarly James Gosling and Anders Hejlsberg, consider this feature unimportant, > > The way it works in the older compiler above, is that when a module is > compiled, it automatically generates an exports file, containing all the > declarations that are shared or exported from it. This is roughly > equivalent to a header file. > > When the module is imported by another module, that small exports file > (not the module) is processed. > > This readable exports file forms the interface, one that is generated > automatically (I used to put doc-strings in there too). > > (The new compiler will be a whole-project compiler and will do away with > such intermediate files. But the requirement for a discrete interface > file is likely to arise again when an application as a whole is intended > to form a library to be used from other programs in the same language.) > > > -- > bartc Carlos E.R. is being controlled by a corporation. Fuchsia, runs on the Windows kernel. So yeah, Windows is mobile. Windows is a super computer. Windows is a server. Windows is a desktop. Windows is growing in market share. Requesting Carlos E.R. to admit guilt, which we should all do, is different than quoting his fraud. My point was that good people come here to attack bullies. It's not like we all don't know what this place is, Autumn Nissen (https://www.facebook.com/anissen7) especially. -- "You'll notice how quickly he loses interest when everything is about him. He clearly wants the attention" Steven Petruzzellis, making the dumbest comment ever uttered.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-05-04 11:36 +0200 |
| Message-ID | <pch9jg$66e$1@dont-email.me> |
| In reply to | #130081 |
On 03/05/18 15:36, bartc wrote:
> On 03/05/2018 13:42, Dan Purgert wrote:
>> bartc wrote:
>>> On 02/05/2018 22:57, Ian Collins wrote:
>>>> On 05/03/2018 09:42 AM, bartc wrote:
>>>>>
>>>>> The current version is targetted at applications that run under
>>>>> Windows.
>>>>
>>>> That says it all really, doesn't it?
>>>
>>> You don't get it do you?
>>>
>>> One of the big problems with C is all this #include nonsense.
>>>
>>> A modern approach to #includes is the use of 'import' together with the
>>> concept of modules.
>>
>> How is "import <some_module>" any different than "#include
>> <some_module>"?
>
> They couldn't be more different.
Yes, they /could/ be more different - because the way #include is mostly
used is very similar to a more structured "module" concept. Typically,
languages that have a module system have a lot more structure and
restrictions than you have in include files. In C, the include system
is very flexible - you have to enforce a structure and modularisation
yourself. This has its advantages and disadvantages - sometimes the
flexibility is great, but it also means you have to understand how to
use include files properly for correct and modular coding.
Unfortunately, many C programmers (yourself including) don't understand
the details here.
From the viewpoint of the well-disciplined programmer, C #include files
cover the main requirements of modules. There are, as I see it, four
main disadvantages:
1. No namespacing. (C++ solves this with "namespace" - a feature C
could easily adopt.)
2. No separation of publicly useful data (like function declarations)
and implementation data needed by the compiler (like inline function
definitions, and details of struct contents).
3. No pre-compilation (that is a side-effect of the flexibility. It is
of little consequence for most C programming, but slows down very large
project builds and is a real pain for a lot of C++ programming).
4. The flexibility means people who don't know how to make C "modules"
get things wrong.
C #include files can be used for other more flexible uses too, which
modules cannot.
>
> Usually C modules are divided into .h files and .c files.
>
> You would include that .h file, not the module. And #include just
> incorporates the text from the .h into the text of this translation
> unit. There is no separate scope associated with it.
True. It would be nice if C had C++ namespaces for scoping.
>
> Being text, the meanings of the declarations in the .h file could vary
> depend on what has already been encountered.
True, in theory - but rarely the case in well-structure code.
>
> Nothing stops you including the same .h header file 20 times, and so
> many header files have messy #ifdef guards to prevent this.
The #ifdef guards are cheap, simple, and very familiar to all C
programmers. A "proper" C module concept would not need them, but they
are not a hardship.
When written properly (for /my/ definition of "proper", of course - C is
flexible and people have different thoughts) you can include the same
header files as often as you want, as nested as you want, and in the
orders that you want, and it should make absolutely no difference. Just
like with modules.
>
> Header files can also include other header files. (Use #include
> <windows.h> with MS' windows.h, and there are 650 nested includes
> performed, although not all unique.)
>
Yes. So what? It is a major advantage that header files can include
other headers - every "module" system I have used in any programming
language can do the same.
> The file part of the #include line can involve a relative or absolute
> file path, which can interact with the location of the current module,
> the current include file, the current directory, and the set of include
> paths to search, in complex ways. Using either "..." or <...> can also
> change the way the search is done.
Yes. It is flexible and useful. And it is similar to any module system.
>
> Usually also, a module has to #include its own header (as it needs the
> contained declarations).
In sensible modular code, it is /essential/ for an implementation file
to include its own header - that avoids unnecessary code duplication and
ensures consistency with the compiler checking for errors.
And I can't see any downsides to having an implementation file include
its own header.
>
> The order of #includes may be important, because if B.h needs a
> declaration in A.h, A.h must be included first. Sometimes, B.h will
> #include A.h itself, but then the main module M.c will itself include
> A.h, then B.h, and this is how duplicate headers can occur.
If the file B.h relies on A.h, then it should include it. It is exactly
the same with modules. Duplicate headers are avoided by header guards.
(An alternative to header guards is to use the #import instead of
#include. This is non-standard, but supported by many compilers.
Putting "#pragma once" in a header is similarly non-standard by often
supported. Header guards are the simplest, standard, and most used method.)
>
> The way that C declares exported and imported names doesn't help either:
>
> int abc; // in A.h
You mean "extern int abc;", surely? Headers should have declarations,
not definitions, for variables and non-inline functions.
> -------------
> #include <a.h> // in A.c
> int main (void) {
> printf("%d",abc)';
> }
You meant to have the definition "int abc;" in A.c too.
> --------------
> #include <a.h> // in B.c
>
>
> When A.c is compiled, the 'int abc;' is taken to be a exported from
> module A.c. But when B.c is compiled, abc is still exported! Because
> it's seeing exactly the same definition.
>
> You can 'extern int abc;', but now both modules will apparently export
> it! Sometimes a linker will sort this out and create just one shared
> version.
>
Look, it is actually fairly simple. Not as simple as it could have
been, perhaps, but not hard.
"extern int abc;" /declares/ "abc" to be an integer with external
(global) linkage - but it does not define it, allocate space for it, or
provide any initialisation for it.
"int abc;" is a "tentative definition" - if no full definition
("external definition" in the C standards) is found by the end of that
translation unit, then it is treated as if it were a full definition
"int abc = 0;".
"int abc = 0;" or other initialisation is always a full definition.
Generally speaking, the header A.h for your C "module" should contain
declarations like "extern int abc;". Your implementation file A.c
should contain the definitions like "int abc;" or "int abc = 1;". Then
all files that need access to the variable "abc", including the
implementation file A.c, will #include A.h. All files that need it will
then see the declaration - but only A.c will have the definition as well
as seeing the declaration.
The simple rule is that every single file-level variable and function in
A.c is /either/ declared "static", /or/ it has a matching "extern"
declaration in A.h. That keeps everything neat and ordered, you know
exactly where everything is, you get exactly one definition of
everything, you don't pollute your global namespace more than absolutely
necessary, and your compiler can spot mistakes. It is a bit simplistic
for when you have libraries and subdirectories of files, but it is an
excellent start.
Unfortunately, C implementations often support the concept of "common
symbols" when more than one translation file defines an object with the
same external linkage identifier. That's what you have if both A.c and
B.c have "int abc;" - whether directly or via an #include file. Early C
implementations were happy with this and the linker joined the symbols.
Early C code took advantage of it - and thus most C compilers support
it despite it not being a requirement of the language (it is outside the
scope of the C standards, and thus undefined behaviour for the C
language). It is a /bad/ idea - it is not always supported, on many
targets it is inefficient compared to data section variables, and most
importantly, it is extremely easy to get things very badly wrong without
diagnosis. Consider what happens if you have "int abc;" in A.c and
"double abc;" in B.c. The resulting binary could legitimately have a
single int-sized space used for both, a single double-sized space used
for both, two separate spaces of different sizes, no space at all, or a
linker failure. In no case do you get what you want.
For gcc, you should always use "-fno-common" - then at least you would
be guaranteed a linker error with such mismatches (or even if the same
"int abc;" is found in both A.c and B.c).
> There are problems also when you /do/ want to export the same name, but
> different object, from different modules; C can't do this without renaming.
C++ namespaces would solve this simply and reliably. Indeed, in the
proposed C++ modules, modules themselves don't introduce a new scope.
(Yes, I am agreeing that this is a feature C could benefit from.)
>
> So, the #include/header system is a mess.
>
> =============================================================
>
> Now look a proper imports, as used in my language (or for something
> mainstream, look at how Python imports work, which are not too different).
>
> Here, there are no headers, only modules. If module X wants to use the
> stuff exported from A, it will do:
>
> import A
>
> Then the compiler will do whatever it has to do to obtain the exported
> names from A.m (.m is the source extension). It is not crude textual
> insertion.
>
> Importing A twice is no problem. Doing this:
>
> import A
> import B
>
> when A itself imports B, is not a problem either. The order here is not
> important. (If A needs B, it will import it itself, but that doesn't
> affect what happens here.)
The same applies to C with #include files if you use common conventions
of include guards and nested includes.
And if you use a decent build system, it will handle re-builds on header
changes automatically.
>
> Inside A.m, I might have:
>
> global int abc
If I were to change C, I would make "static" the default (perhaps with a
different name) and require "extern" (or "global", or "export", or
whatever) explicitly for external linkage.
>
> if I want to export that. In X, I can refer to it as 'abc' just by
> having 'import A'. (If both A and B export 'abc', then I might need to
> use A.abc and B.abc to disambiguate.)
>
> For imports, the A or B is not a file-spec; it is a name. It will locate
> the module using a far simpler search method than for include files.
If module names do not match file names, then the search becomes
massively /more/ complex.
>
> In other words, this is a more grown-up way of doing this stuff. You
> really wouldn't want to go back to headers.
>
I agree that a good module system has advantages over includes. I don't
agree that includes are anything like as problematic as you make out -
you just need to know how to use them properly and have a bit of
self-discipline.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2018-05-04 08:52 -0700 |
| Message-ID | <bf53c2fc-92db-4edd-8c80-5e87caed7edc@googlegroups.com> |
| In reply to | #130124 |
On Friday, May 4, 2018 at 4:36:58 AM UTC-5, David Brown wrote:
> From the viewpoint of the well-disciplined programmer, C #include files
> cover the main requirements of modules. There are, as I see it, four
> main disadvantages:
>
> 1. No namespacing. (C++ solves this with "namespace" - a feature C
> could easily adopt.)
>
> 2. No separation of publicly useful data (like function declarations)
> and implementation data needed by the compiler (like inline function
> definitions, and details of struct contents).
>
> 3. No pre-compilation (that is a side-effect of the flexibility. It is
> of little consequence for most C programming, but slows down very large
> project builds and is a real pain for a lot of C++ programming).
>
> 4. The flexibility means people who don't know how to make C "modules"
> get things wrong.
5. No ability to interact with code which isn't processed by the same C
implementation, except perhaps by hard-coding or explicitly passing
the addresses of every point of interaction (e.g. if one wants to
call a routine and knows its address will be stored at 0x20001FF8,
one might be able to do something like:
void (*myRoutine)(myStructType *) =
*(((void**)(myStructType *))0x20001FF8);
myRoutine(&myStruct);
and sometimes that approach may be unavoidable, but being able to have
a linker resolve symbols among code written in different languages is
generally better).
[toc] | [prev] | [next] | [standalone]
Page 6 of 11 — ← Prev page 1 … 4 5 [6] 7 8 … 11 Next page →
Back to top | Article view | comp.lang.c
csiph-web