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 10 of 11 — ← Prev page 1 … 8 9 [10] 11 Next page →
| From | Steven Petruzzellis <frelwizzen@gmail.com> |
|---|---|
| Date | 2018-05-04 15:14 -0700 |
| Message-ID | <edd000de-881c-4937-9ed7-b1060e93e69c@googlegroups.com> |
| In reply to | #130214 |
On Friday, May 4, 2018 at 1:51:33 PM UTC-7, fir wrote:
> i also can say that this moduler design would be possibly mor concise than analogic code in pure c, when c++ oop wersion would be longer than pure c
>
> such modular schemec imo could offer different styles as possibilities but some hevy modular could look more like coding on bricks
>
> i should possibly some example of code that i think copuld be compilable and show some code for say arkanoid
>
> now im to tired but some early partial draft (know it lloks strange but may be considered ) .. imo looks a bit like plastic but normal c codes does not good anyway .. they lack of concisement imo
>
>
>
>
> module Paddle
> {
> uses mouse;
>
> int x, y;
>
> update()
> {
> x = mouse.x
> y = mouse.y
> }
>
> draw.on() [Window window]
> {
> window draw.rectangle(x-5,y-5,x+5,y+5, 0xff0000)
> }
>
>
> }
>
> module Arkanoid
> {
> uses system.sleep;
> uses system.app.exit
>
> Window window
>
> Brick brick[10][10]
> Ball ball
> Paddle paddle
>
> run.frame()
> {
> move brick[][]
> move ball
> update paddle
>
> if(keyboard.esc == pressed) app.exit
>
> brick[][] draw.on window
> ball draw.on window
> paddle draw.on window
>
> }
>
> run()
> {
> run.frame()
> system sleep(10)
>
> }
>
> }
I reported him years ago. As expected, it did diddly-squat to stop the dunderhead. Not long ago I did work on and showed some AppleScript for the front end (only works on Linux) which is the only thing you can do when trying to avoid Paul F. Riddle's dishonest crap while reading with Google Groups. Why do you keep repeating Jeff Relf?
Bravo, Jeff Relf, you are now living rent-free inside Paul F. Riddle's beady little brain. Lul.
My view is correct. Always correct. Can you knock off asking for my attention?
At one point, Paul F. Riddle said an online denizen was "obsessing" over him, which was shown to be merely him using his flood script to "boost" his "mentions" count.
Jeff Relf has plenty of experience to enlighten others and he has been persuaded to provide screencasts to help others. Of course this is arguably the least appropriate medium for doing that because much of response is howling, lying and other drivel.
--
E-commerce Simplified
http://tinyurl.com/proof-about-ebot
https://www.youtube.com/watch?v=AglvCo3dJ38&feature=youtu.be
https://youtu.be/UkAyrfOZaXc
Jonas Eklundh Communication AB
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2018-05-04 11:18 -0500 |
| Message-ID | <0p1peddn2laduuqlonjdjrsl1gqtresf3t@4ax.com> |
| In reply to | #130147 |
On Fri, 4 May 2018 05:10:28 -0700 (PDT), already5chosen@yahoo.com wrote: >On Friday, May 4, 2018 at 2:31:18 PM UTC+3, Bart wrote: >> On 04/05/2018 11:55, Dan Purgert wrote: >> > Jorgen Grahn wrote: >> >> On Thu, 2018-05-03, Dan Purgert wrote: >> >>> Keith Thompson wrote: >> >>>> Dan Purgert <dan@djph.net> writes: >> >>>>> How is "import <some_module>" any different than "#include >> >>>>> <some_module>"? >> >>>> >> >>>> #include exists in C. import doesn't. >> >>>> >> >>> >> >>> My question was more pointed at the apparent argument that "import >> >>> thing" is somehow better than "include thing". >> >> >> >> There are differences, but I haven't looked into it. If you want to >> >> find out more, try looking in C++. It has the same #include mechanism >> >> as C, but there are actual plans to add a module concept. (As far as >> >> I know, there are no such plans for C, outside vague speculation in >> >> comp.lang.c.) >> >> >> > Maybe someday. >> > >> > The only thing I could find with a quick google was that "yeah, they're >> > different approaches to the same goal." Almost sounds like arguing >> > whether or not taking a light rail vs. a bus from point (a) to (b) is >> > (always) better. Sure, there are probably cases for each, but hardly a >> > hard and fast rule. >> >> C's #include is nothing to do with modules, nor headers for that matter, >> and it doesn't understand anything about either. >> > >C's includes is generic text substitution tool that is commonly used by practitioners to implement interfaces of the modules. It certainly can be both used and misused for other purposes, but the above mentioned usage is by far the most common, the most idiomatic. > >> It's pure text insertion. You can do what #include does by copy & paste >> using an editor, except that then you'd have multiple copies to maintain. >> > >Pretty huge "except", isn't it? >One of the main goals, if not *The Main Goal*, of programming tools, including programming languages, is to assist DRY principle. C solution (well, formally speaking, C culture solution, rather than C language solution) to modularity >is not ideal, because it involves repeating yourself twice, but repeating yourself twice is FAR better than repeating yourself many times. Using C-style #includes to implement modules also has the problems of (usually) exposing a great deal of the implementation details of the "module". There are ways around that, but they are extra work, and often add extra overhead.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2018-05-04 09:05 -0700 |
| Message-ID | <lno9hvcsnv.fsf@kst-u.example.com> |
| In reply to | #130140 |
bartc <bc@freeuk.com> writes:
[...]
> C's #include is nothing to do with modules, nor headers for that matter,
> and it doesn't understand anything about either.
#include has nothing to do with headers?
Perhaps you have a different meaning for the word "header" than the rest
of us do.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-05-04 17:55 +0100 |
| Message-ID | <fg0HC.117671$GV1.108674@fx32.am4> |
| In reply to | #130183 |
On 04/05/2018 17:05, Keith Thompson wrote: > bartc <bc@freeuk.com> writes: > [...] >> C's #include is nothing to do with modules, nor headers for that matter, >> and it doesn't understand anything about either. > > #include has nothing to do with headers? > > Perhaps you have a different meaning for the word "header" than the rest > of us do. I said that #include doesn't understand headers. It is just a preprocessing directive that locates a text file and incorporates that at this location into the current translation unit. "It /might/ be C .h file that is used as a header. Or it might be other C code. Or it might be a text file that can contain anything, although it will usually still form valid source code once incorporated. For example, it might contain this paragraph. Doesn't much like a header does it?" -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2018-05-04 10:54 -0700 |
| Message-ID | <lnbmdvcnmi.fsf@kst-u.example.com> |
| In reply to | #130195 |
bartc <bc@freeuk.com> writes:
> On 04/05/2018 17:05, Keith Thompson wrote:
>> bartc <bc@freeuk.com> writes:
>> [...]
>>> C's #include is nothing to do with modules, nor headers for that matter,
>>> and it doesn't understand anything about either.
>>
>> #include has nothing to do with headers?
>>
>> Perhaps you have a different meaning for the word "header" than the rest
>> of us do.
>
> I said that #include doesn't understand headers.
Yes, you also said that.
What you actually wrote is still quoted at the top of this article.
You wrote that "C's #include is nothing to do with ... headers".
That's clearly untrue.
Perhaps whatever it was you meant to say is true, but I don't know what
that is.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-05-04 19:18 +0100 |
| Message-ID | <Wt1HC.92733$Z64.32809@fx36.am4> |
| In reply to | #130200 |
On 04/05/2018 18:54, Keith Thompson wrote: > bartc <bc@freeuk.com> writes: >> On 04/05/2018 17:05, Keith Thompson wrote: >>> bartc <bc@freeuk.com> writes: >>> [...] >>>> C's #include is nothing to do with modules, nor headers for that matter, >>>> and it doesn't understand anything about either. >>> >>> #include has nothing to do with headers? >>> >>> Perhaps you have a different meaning for the word "header" than the rest >>> of us do. >> >> I said that #include doesn't understand headers. > > Yes, you also said that. > > What you actually wrote is still quoted at the top of this article. > You wrote that "C's #include is nothing to do with ... headers". > That's clearly untrue. > > Perhaps whatever it was you meant to say is true, but I don't know what > that is. Let me put it this way: what does C's preprocessor know about header files, as opposed to just text files? Does it treat an included file which is used as a header, any differently from any other use of an include file? If so, how does it know which is which? The choice of <...> or "..." to enclose the file name just varies the search algorithm. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2018-05-04 11:24 -0700 |
| Message-ID | <lny3gzb7nt.fsf@kst-u.example.com> |
| In reply to | #130203 |
bartc <bc@freeuk.com> writes:
[...]
> Let me put it this way: what does C's preprocessor know about header
> files, as opposed to just text files?
A particular implementation of the C preprocessor might not make any
distinction between headers and source files.
Another implementation might treat them very differently. For example,
some compilers support precompiled headers.
See the footnote in N1570 7.1.2:
A header is not necessarily a source file, nor are the < and >
delimited sequences in header names necessarily valid source file
names.
> Does it treat an included file which is used as a header, any
> differently from any other use of an include file? If so, how does it
> know which is which?
>
> The choice of <...> or "..." to enclose the file name just varies the
> search algorithm.
No, that's not *necessarily* all it does. The details are in
N1570 6.10.2. The distinction between "header" and a "source file",
if any, can vary from one implementation to another.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-05-06 16:45 +0200 |
| Message-ID | <pcn4en$rka$1@dont-email.me> |
| In reply to | #130204 |
On 04/05/18 20:24, Keith Thompson wrote: > bartc <bc@freeuk.com> writes: > [...] >> Let me put it this way: what does C's preprocessor know about header >> files, as opposed to just text files? > > A particular implementation of the C preprocessor might not make any > distinction between headers and source files. > > Another implementation might treat them very differently. For example, > some compilers support precompiled headers. > > See the footnote in N1570 7.1.2: > > A header is not necessarily a source file, nor are the < and > > delimited sequences in header names necessarily valid source file > names. > I have used an embedded compiler in which standard headers were built into the toolchain (one binary that was compiler, assembler, linker, IDE, debugger, etc.) and were not files themselves. It's so long ago that I've forgotten what toolchain it was, unfortunately. #include with "..." worked with normal files. >> Does it treat an included file which is used as a header, any >> differently from any other use of an include file? If so, how does it >> know which is which? >> >> The choice of <...> or "..." to enclose the file name just varies the >> search algorithm. > > No, that's not *necessarily* all it does. The details are in > N1570 6.10.2. The distinction between "header" and a "source file", > if any, can vary from one implementation to another. > A very obvious example is that gcc disables warnings for headers included with <...>. This allows you to use stricter warnings for your own code, without triggering warnings in the standard headers. (As usual with gcc, there is a flag to change this behaviour.)
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@alumni.caltech.edu |
|---|---|
| Date | 2018-05-04 11:51 -0700 |
| Message-ID | <e25afc1e-bd51-4058-a3b8-b15e7046d4e5@googlegroups.com> |
| In reply to | #130203 |
On Friday, May 4, 2018 at 2:18:39 PM UTC-4, Bart wrote: > On 04/05/2018 18:54, Keith Thompson wrote: > > bartc <bc@freeuk.com> writes: > >> On 04/05/2018 17:05, Keith Thompson wrote: > >>> bartc <bc@freeuk.com> writes: > >>> [...] > >>>> C's #include is nothing to do with modules, nor headers for that matter, > >>>> and it doesn't understand anything about either. > >>> > >>> #include has nothing to do with headers? > >>> > >>> Perhaps you have a different meaning for the word "header" than the rest > >>> of us do. > >> > >> I said that #include doesn't understand headers. > > > > Yes, you also said that. > > > > What you actually wrote is still quoted at the top of this article. > > You wrote that "C's #include is nothing to do with ... headers". > > That's clearly untrue. > > > > Perhaps whatever it was you meant to say is true, but I don't know what > > that is. > > Let me put it this way: what does C's preprocessor know about header > files, as opposed to just text files? > > Does it treat an included file which is used as a header, any > differently from any other use of an include file? ... An implementation of C is permitted to treat headers differently - but that's partially because "header" means something different in the C standard than the meaning that you're probably thinking of. > ... If so, how does it > know which is which? The standard defines the term "header" in 7.1.2p1. The term is italicized, an ISO convention indicating that the sentence containing that term is the official definition of that term. It applies ONLY to the standard library headers, which are listed in 7.1.2p2. If it's not in that list, it isn't a header, as the C standard uses that term. That explains why the following clauses refer to "header or source file" - a source file is not a header, not even when it has a name ending with ".h" and is designed specifically to be used in a #include directive: "A #include preprocessing directive causes the named header or source file to be processed ..." (5.1.1.2p4). "The sequences in both forms of header names are mapped in an implementation-defined manner to headers or external source file names as specified in 6.10.2." (6.4.7p2). "A #include directive shall identify a header or source file that can be processed by the implementation." (6.10.2p1). > The choice of <...> or "..." to enclose the file name just varies the > search algorithm. The distinction between headers and source files matters, because that's NOT the case. The description for #include <> (6.10.2p2) only ever refers to "headers". Therefore, it's use for things which aren't headers, as C defines that term, is undefined behavior "by omission of an explicit definition of the behavior" (4p2). The description for #include "" (6.10.2p3) only ever refers to "source files". However, if the search described in 6.10.2p3 fails, then the directive is reprocessed as if it used <>, and it's only because of that fact that you can use #include"" on headers. The standard never uses the term "header file", and is deliberately written to avoid implying that headers must be implemented as text files (though that is, in fact, one of the most common ways to implement them). It is therefore permissible for a #include <> search to search only a list built into the compiler, which contains only the entries to be added to the compiler's symbol table, and not any actual text.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2018-05-04 12:15 -0700 |
| Message-ID | <ceed51dd-690c-4185-aee6-f00aa599efcd@googlegroups.com> |
| In reply to | #130203 |
On Friday, May 4, 2018 at 1:18:39 PM UTC-5, Bart wrote: > The choice of <...> or "..." to enclose the file name just varies the > search algorithm. To the contrary, the use of #include <standardHeaderName> has everything to do with headers; the use of #include "standardHeaderName" will involve headers in the cases where it is equivalent to <standardHeaderName>. Of particular significance is the fact that the Standard specifies that #include <standardHeaderName> will cause certain symbols to be defined in certain ways, but does not specify the mechanism. While the simplest way to accommodate that is typically to have a set of files in a known location, with names that match the standard header names, and whose contents will define the appropriate symbols, there's nothing that requires that an implementation do anything like that. An implementation could just as well have a flag word for each symbol table entry that says what standard-header #include directives, if any, must be processed to enable it, initialize the symbol table with all entries from all standard headers, and treat e.g. #include <stdio.h> as an indication to set the flag associated with stdio.h, thus enabling all symbols that would be defined therein. Such an approach would allow an implementation to be smaller on disk, and in many cases faster, but at the expense of increasing RAM requirements versus the more common approach of defining symbols using headers that are formatted as C source code.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-05-04 21:56 +0100 |
| Message-ID | <rO3HC.100940$EL2.89409@fx37.am4> |
| In reply to | #130213 |
On 04/05/2018 20:15, supercat@casperkitty.com wrote:
> On Friday, May 4, 2018 at 1:18:39 PM UTC-5, Bart wrote:
>> The choice of <...> or "..." to enclose the file name just varies the
>> search algorithm.
>
> To the contrary, the use of #include <standardHeaderName> has everything
> to do with headers; the use of #include "standardHeaderName" will involve
> headers in the cases where it is equivalent to <standardHeaderName>.
If I write this program:
#include <stdio.h>
int main(void) {
#include <hello.h>
}
where hello.h contains:
printf("Hello World!\n");
and is placed where the compiler can find it, then it compiles a normal
hello world program. Nothing about #include or the <...> is specifically
to do with headers (certainly not in my implementation).
If you say that an implementation /might/ treat such includes specially
(eg. detect that it refers to a standard header and act accordingly),
then it might well do; that doesn't really change the language.
I don't think it's enough that a standard can say an implementation
might do this or that; it might do anything.
You can't state, for all C implementations, that the code that handles
#includes knows anything about headers. All you can say is that some
might do.
Otherwise the C language can be attributed all sorts of advanced
features, even if they don't exist, just because the standard says that
an implementation might decide to add them.
> implementation do anything like that. An implementation could just as well
> have a flag word for each symbol table entry that says what standard-header
> #include directives, if any, must be processed to enable it, initialize
> the symbol table with all entries from all standard headers, and treat
> e.g. #include <stdio.h> as an indication to set the flag associated with
> stdio.h, thus enabling all symbols that would be defined therein. Such an
> approach would allow an implementation to be smaller on disk, and in many
> cases faster, but at the expense of increasing RAM requirements versus
> the more common approach of defining symbols using headers that are formatted
> as C source code.
I haven't seen any evidence of that in implementations I've looked at;
they all seem to have explicit headers. And if it was used, it would be
more useful for massive headers like windows.h rather than the usually
small standard headers.
(My implementation comes closest in not having explicit header files,
but they are just stored as source strings in memory; the contents are
not structured data.)
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-05-06 17:01 +0200 |
| Message-ID | <pcn5c1$31b$1@dont-email.me> |
| In reply to | #130215 |
On 04/05/18 22:56, bartc wrote:
> On 04/05/2018 20:15, supercat@casperkitty.com wrote:
>> On Friday, May 4, 2018 at 1:18:39 PM UTC-5, Bart wrote:
>>> The choice of <...> or "..." to enclose the file name just varies the
>>> search algorithm.
>>
>> To the contrary, the use of #include <standardHeaderName> has everything
>> to do with headers; the use of #include "standardHeaderName" will involve
>> headers in the cases where it is equivalent to <standardHeaderName>.
>
> If I write this program:
>
> #include <stdio.h>
>
> int main(void) {
> #include <hello.h>
> }
>
> where hello.h contains:
>
> printf("Hello World!\n");
>
> and is placed where the compiler can find it, then it compiles a normal
> hello world program. Nothing about #include or the <...> is specifically
> to do with headers (certainly not in my implementation).
Ah, the old "it worked when I tried it on some compilers, therefore it
must be correct" fallacy. The standard says that will work if you use
the "..." form of #include, but does not require it for the <...> form.
/Most/ compilers do happen to use /basically/ the same mechanism for
both forms, and thus it will work in most cases - but there are
compilers that do things differently.
>
> If you say that an implementation /might/ treat such includes specially
> (eg. detect that it refers to a standard header and act accordingly),
> then it might well do; that doesn't really change the language.
You have it ass-backwards. The fact that many implementations treat
<...> and "..." includes in mostly the same way does not change the
language or make it a requirement of the language.
>
> I don't think it's enough that a standard can say an implementation
> might do this or that; it might do anything.
>
> You can't state, for all C implementations, that the code that handles
> #includes knows anything about headers. All you can say is that some
> might do.
I know for a fact that some C implementations make a distinction between
<...> and "..." forms (other than the search path). So we can state
categorically that the standard makes a distinction, and some
implementations make a distinction. What more do you want?
You are correct, of course, in that most implementations handle
inclusion of both forms as though it were just text substitution, with
perhaps minor differences (like gcc's suppression of warnings). And
most implementations will work fine with an include file containing just
a printf statement, like your example. They will also be fine with ".h"
files, ".inc" files, or any other extension (or lack thereof) that you want.
But you are - as you so often do - confusion "what most implementations
do" with "how the language is defined".
>
> Otherwise the C language can be attributed all sorts of advanced
> features, even if they don't exist, just because the standard says that
> an implementation might decide to add them.
>
>> implementation do anything like that. An implementation could just as
>> well
>> have a flag word for each symbol table entry that says what
>> standard-header
>> #include directives, if any, must be processed to enable it, initialize
>> the symbol table with all entries from all standard headers, and treat
>> e.g. #include <stdio.h> as an indication to set the flag associated with
>> stdio.h, thus enabling all symbols that would be defined therein.
>> Such an
>> approach would allow an implementation to be smaller on disk, and in many
>> cases faster, but at the expense of increasing RAM requirements versus
>> the more common approach of defining symbols using headers that are
>> formatted
>> as C source code.
>
> I haven't seen any evidence of that in implementations I've looked at;
> they all seem to have explicit headers. And if it was used, it would be
> more useful for massive headers like windows.h rather than the usually
> small standard headers.
I /have/ used at least one implementation where the standard headers
were not available as files. It is highly unusual - of that there is
little doubt. But such implementations do exist.
>
> (My implementation comes closest in not having explicit header files,
> but they are just stored as source strings in memory; the contents are
> not structured data.)
>
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-05-06 17:54 +0100 |
| Message-ID | <srGHC.107198$tw.47787@fx42.am4> |
| In reply to | #130259 |
On 06/05/2018 16:01, David Brown wrote:
> On 04/05/18 22:56, bartc wrote:
>> where hello.h contains:
>>
>> printf("Hello World!\n");
>>
>> and is placed where the compiler can find it, then it compiles a
>> normal hello world program. Nothing about #include or the <...> is
>> specifically to do with headers (certainly not in my implementation).
>
> Ah, the old "it worked when I tried it on some compilers, therefore it
> must be correct" fallacy. The standard says that will work if you use
> the "..." form of #include, but does not require it for the <...> form.
What's at issue is whether C's preprocessor's #include feature knows
about headers, or whether it's the other way around: C's way of
implementing headers is built on top of #include.
I've seen little evidence that it's anything other than the latter. If I
added a new:
#includetextfile
directive to the language, then probably this could be used for headers
just as #include is, disregarding minor details of search paths or
whether warnings are disabled.
This suggests C could be defined without headers being a core part of
the language. And actually, it might work without #include (for new
programs), by synthesising the source file submitted to the compiler
from the text files that are to serve as headers.
It would not be practical emulate modules in a language.
(This can be put to the test: take a source file s1.c, preprocess it to
s2.c so that #includes disappear, and then compile s2.c. It should still
work, but without #includes and without headers; magic!
Now try to do the same with a language with imports. I can't speak for
all such languages as they are all different, but with mine that would
definitely not be practical. (Partly because it needs the compiler to
generate the symbol information necessary to do the importing, even if
it's all done with text files.)
--
bart
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2018-05-06 13:38 -0700 |
| Message-ID | <lnin80bjtz.fsf@kst-u.example.com> |
| In reply to | #130260 |
bartc <bc@freeuk.com> writes:
> On 06/05/2018 16:01, David Brown wrote:
>> On 04/05/18 22:56, bartc wrote:
>>> where hello.h contains:
>>>
>>> printf("Hello World!\n");
>>>
>>> and is placed where the compiler can find it, then it compiles a
>>> normal hello world program. Nothing about #include or the <...> is
>>> specifically to do with headers (certainly not in my implementation).
>>
>> Ah, the old "it worked when I tried it on some compilers, therefore it
>> must be correct" fallacy. The standard says that will work if you use
>> the "..." form of #include, but does not require it for the <...> form.
>
> What's at issue is whether C's preprocessor's #include feature knows
> about headers, or whether it's the other way around: C's way of
> implementing headers is built on top of #include.
Please explain what you mean by "knows about headers".
The standard's definition of "header" (N1570 7.1.2p1) refers only
to the standard library headers. `#include <stdio.h>` works *as
if* a chunk of C code (the "entire contents of the header") were
inserted at that point. The standard doesn't say how such a header
is implemented or how its contents are represented. It's commonly
a source file, but it may be something else.
Of course the preprocessor know about headers -- *if* you accept the
standard's definition of "headers".
[...]
> This suggests C could be defined without headers being a core part of
> the language. And actually, it might work without #include (for new
> programs), by synthesising the source file submitted to the compiler
> from the text files that are to serve as headers.
Sure, you could replace the preprocessor with some other tool that does
the same thing. So what?
> It would not be practical emulate modules in a language.
Why not? Isn't "synthesising the source file submitted to the
compiler from the text files that are to serve as headers" exactly
what the preprocessor already does?
> (This can be put to the test: take a source file s1.c, preprocess it to
> s2.c so that #includes disappear, and then compile s2.c. It should still
> work, but without #includes and without headers; magic!
That's not magic, that's just how #include works.
> Now try to do the same with a language with imports. I can't speak for
> all such languages as they are all different, but with mine that would
> definitely not be practical. (Partly because it needs the compiler to
> generate the symbol information necessary to do the importing, even if
> it's all done with text files.)
So the issue isn't what #include or "header" means. Both of those
concepts are well defined, in spite of your efforts to obfuscate
them.
The only open questions involve what you're calling "modules".
That's a well defined term in some languages, but C itself has no
such concept. Programmers commonly implement something that might
reasonable be called "modules" using #include and libraries (and
of course #include can be used for purposes other than implementing
"modules").
Does the preprocessor "know" about "headers", as that term is defined
in the standard? Of course it does. Does it know about "modules"?
No, because there is no such concept defined in the language.
C doesn't directly support modules, but programmers can implement
them using the tools provided by the language.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-05-06 21:49 +0100 |
| Message-ID | <LTJHC.48439$U32.31899@fx04.am4> |
| In reply to | #130273 |
On 06/05/2018 21:38, Keith Thompson wrote: > bartc <bc@freeuk.com> writes: > Of course the preprocessor know about headers -- *if* you accept the > standard's definition of "headers". So the preprocessor - which can also be used on input intended for other languages - knows about C headers because the C standard says it does? OK. That's a circular argument that I'm not going to win. But looked at more objectively from a cross-language viewpoint, that doesn't really stand up. If the standard had used the word 'module', I didn't think many would be convinced that C has a module system. #include is only ever going to be about text insertion. >> It would not be practical emulate modules in a language. > > Why not? Isn't "synthesising the source file submitted to the > compiler from the text files that are to serve as headers" exactly > what the preprocessor already does? Dealing with modules usually involves more than just inserting or concatenating text. Otherwise it wouldn't take so long to implement them. Implementing #include on the other hand is a day's work, if that. (The file search algorithm is probably the hardest bit.) > Does the preprocessor "know" about "headers", as that term is defined > in the standard? Of course it does. My preprocessor doesn't. But then you will say it is non-conforming. As I said, I can't win that argument if the C standard says that you're right and I'm wrong. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2018-05-06 17:19 -0400 |
| Message-ID | <mjKHC.79094$LR2.58802@fx41.iad> |
| In reply to | #130274 |
On 5/6/18 4:49 PM, bartc wrote: > On 06/05/2018 21:38, Keith Thompson wrote: >> bartc <bc@freeuk.com> writes: > >> Of course the preprocessor know about headers -- *if* you accept the >> standard's definition of "headers". > > So the preprocessor - which can also be used on input intended for other > languages - knows about C headers because the C standard says it does? > > OK. That's a circular argument that I'm not going to win. > Actually, the C Standard doesn't define the presence of a separate program that we are calling 'the preprocessor', just what must be done to translate a program. The use of a 'preprocessor' program (maybe usable for other languages) is an implementation detail, that doesn't even need to be documented. Note also that the required 'knowledge' may just be knowledge of where to find a set of source files (likely using implementation dependent features) the implement the needed definitions. This would make such a preprocessor much more usable in a multi-language environment. (And this seems to be the way that most implementations I know of work). The key point is that this is NOT required by the Standard, and the "headers" defined by the Standard might not exist a what would be thought of as a 'source file' > But looked at more objectively from a cross-language viewpoint, that > doesn't really stand up. > > If the standard had used the word 'module', I didn't think many would be > convinced that C has a module system. > > #include is only ever going to be about text insertion. > That is an assumption, and one that can be show to be false. As has been mention, it is quite possible that the #include statements referencing the Standard defined headers might not refer to any 'source file' in the system, but just 'magically' adds the needed symbols into the translation environment.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2018-05-06 15:24 -0700 |
| Message-ID | <lna7tcbexk.fsf@kst-u.example.com> |
| In reply to | #130277 |
Richard Damon <Richard@Damon-Family.org> writes:
> On 5/6/18 4:49 PM, bartc wrote:
[...]
>> #include is only ever going to be about text insertion.
>
> That is an assumption, and one that can be show to be false. As has been
> mention, it is quite possible that the #include statements referencing
> the Standard defined headers might not refer to any 'source file' in the
> system, but just 'magically' adds the needed symbols into the
> translation environment.
Actually I think bartc is correct on this point.
N1570 6.10.2 says that #include <...> "causes the replacement of that
directive by the entire contents of the header", and #include "..."
"causes the replacement of that directive by the entire contents
of the source file".
That sounds like text insertion to me -- whether the text is literally
copied from some input file or obtained by some other means.
(It's possible that no text representation of a header is ever
generated, and it's processed by "magically" adding entries to the
symbol table, but it must be processed *as if* it were inserted as
text and then processed through tranlation phases 1-4. #include is
defined in terms of text insertion.)
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2018-05-06 15:16 -0700 |
| Message-ID | <lnefiobfag.fsf@kst-u.example.com> |
| In reply to | #130274 |
bartc <bc@freeuk.com> writes:
> On 06/05/2018 21:38, Keith Thompson wrote:
>> bartc <bc@freeuk.com> writes:
>> Of course the preprocessor know about headers -- *if* you accept the
>> standard's definition of "headers".
>
> So the preprocessor - which can also be used on input intended for other
> languages - knows about C headers because the C standard says it does?
>
> OK. That's a circular argument that I'm not going to win.
No, it's simply an argument based on what the C standard says.
You're not losing because it's circular, you're losing because
you're wrong.
Actually I think it's because you're using terms that are already
defined, but with different meanings. If you want to talk about
"modules", go ahead and talk about "modules". You might start by
defining what you mean by the term.
(Incidentally, the C standard doesn't say or imply that
the C preprocessor can be used for other languages. Some C
preprocessor implementations can be, but there's no requirement
for the preprocessor's output to be made available. For example,
it could be tightly integrated into a compiler. It's true that
most C preprocessor implementations *can* be used that way, so you
needn't bother repeating that argument.)
[snip]
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Steve Carroll <frelwizzen@gmail.com> |
|---|---|
| Date | 2018-05-06 23:55 -0700 |
| Message-ID | <4e006b5f-1f0a-4c66-a612-b7e3358f65ff@googlegroups.com> |
| In reply to | #130273 |
On Sunday, May 6, 2018 at 1:38:59 PM UTC-7, Keith Thompson wrote:
> bartc <bc@freeuk.com> writes:
> > On 06/05/2018 16:01, David Brown wrote:
> >> On 04/05/18 22:56, bartc wrote:
> >>> where hello.h contains:
> >>>
> >>> printf("Hello World!\n");
> >>>
> >>> and is placed where the compiler can find it, then it compiles a
> >>> normal hello world program. Nothing about #include or the <...> is
> >>> specifically to do with headers (certainly not in my implementation).
> >>
> >> Ah, the old "it worked when I tried it on some compilers, therefore it
> >> must be correct" fallacy. The standard says that will work if you use
> >> the "..." form of #include, but does not require it for the <...> form.
> >
> > What's at issue is whether C's preprocessor's #include feature knows
> > about headers, or whether it's the other way around: C's way of
> > implementing headers is built on top of #include.
>
> Please explain what you mean by "knows about headers".
>
> The standard's definition of "header" (N1570 7.1.2p1) refers only
> to the standard library headers. `#include <stdio.h>` works *as
> if* a chunk of C code (the "entire contents of the header") were
> inserted at that point. The standard doesn't say how such a header
> is implemented or how its contents are represented. It's commonly
> a source file, but it may be something else.
>
> Of course the preprocessor know about headers -- *if* you accept the
> standard's definition of "headers".
>
> [...]
>
> > This suggests C could be defined without headers being a core part of
> > the language. And actually, it might work without #include (for new
> > programs), by synthesising the source file submitted to the compiler
> > from the text files that are to serve as headers.
>
> Sure, you could replace the preprocessor with some other tool that does
> the same thing. So what?
>
> > It would not be practical emulate modules in a language.
>
> Why not? Isn't "synthesising the source file submitted to the
> compiler from the text files that are to serve as headers" exactly
> what the preprocessor already does?
>
> > (This can be put to the test: take a source file s1.c, preprocess it to
> > s2.c so that #includes disappear, and then compile s2.c. It should still
> > work, but without #includes and without headers; magic!
>
> That's not magic, that's just how #include works.
>
> > Now try to do the same with a language with imports. I can't speak for
> > all such languages as they are all different, but with mine that would
> > definitely not be practical. (Partly because it needs the compiler to
> > generate the symbol information necessary to do the importing, even if
> > it's all done with text files.)
>
> So the issue isn't what #include or "header" means. Both of those
> concepts are well defined, in spite of your efforts to obfuscate
> them.
>
> The only open questions involve what you're calling "modules".
> That's a well defined term in some languages, but C itself has no
> such concept. Programmers commonly implement something that might
> reasonable be called "modules" using #include and libraries (and
> of course #include can be used for purposes other than implementing
> "modules").
>
> Does the preprocessor "know" about "headers", as that term is defined
> in the standard? Of course it does. Does it know about "modules"?
> No, because there is no such concept defined in the language.
>
> C doesn't directly support modules, but programmers can implement
> them using the tools provided by the language.
>
> --
> Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
> Working, but not speaking, for JetHead Development, Inc.
> "We must do something. This is something. Therefore, we must do this."
> -- Antony Jay and Jonathan Lynn, "Yes Minister"
Thankfully the person you are responding to is in my KF. Thanks to -hh and his 'followers' you now need an IP filtering system (which I programmed for Forté Agent and Unison). If people start responding to him again I will jump in... as I hate him too much to not. I am referring to advocates here, not trolls, who are just here to disrupt anyway.
Time to blame anything but Linux! Just look at your junk and look at dorayme's, there is nothing for dorayme to learn from an idiot like -hh. But whatever, let him keep making a cretin of himself. It is not like anyone believes him. Just hogwash from -hh. But -hh has thoroughly left reason behind and is merely holding me accountable for the exploits of himself.
Virtually everything -hh says about what dorayme has done is false of course, but he does not care.
And in reply you have nothing but a crack to start something. The one skill -hh learned sufficiently is to try to humiliate dorayme into silence and if that does not work, flood the thread or completely change the assertion.
--
Live on Kickstarter!
http://www.5z8.info/titstitstitstits_j7t4bl_stalin
https://youtu.be/HHT9SJgYsH4
Jonas Eklundh Communication
[toc] | [prev] | [next] | [standalone]
| From | Steve Carroll <frelwizzen@gmail.com> |
|---|---|
| Date | 2018-05-06 11:59 -0700 |
| Message-ID | <7f69484d-8da5-4688-b846-e9ed27fbf7d2@googlegroups.com> |
| In reply to | #130259 |
On Sunday, May 6, 2018 at 8:01:31 AM UTC-7, David Brown wrote:
> On 04/05/18 22:56, bartc wrote:
> > On 04/05/2018 20:15, supercat@casperkitty.com wrote:
> >> On Friday, May 4, 2018 at 1:18:39 PM UTC-5, Bart wrote:
> >>> The choice of <...> or "..." to enclose the file name just varies the
> >>> search algorithm.
> >>
> >> To the contrary, the use of #include <standardHeaderName> has everything
> >> to do with headers; the use of #include "standardHeaderName" will involve
> >> headers in the cases where it is equivalent to <standardHeaderName>.
> >
> > If I write this program:
> >
> > #include <stdio.h>
> >
> > int main(void) {
> > #include <hello.h>
> > }
> >
> > where hello.h contains:
> >
> > printf("Hello World!\n");
> >
> > and is placed where the compiler can find it, then it compiles a normal
> > hello world program. Nothing about #include or the <...> is specifically
> > to do with headers (certainly not in my implementation).
>
> Ah, the old "it worked when I tried it on some compilers, therefore it
> must be correct" fallacy. The standard says that will work if you use
> the "..." form of #include, but does not require it for the <...> form.
> /Most/ compilers do happen to use /basically/ the same mechanism for
> both forms, and thus it will work in most cases - but there are
> compilers that do things differently.
>
> >
> > If you say that an implementation /might/ treat such includes specially
> > (eg. detect that it refers to a standard header and act accordingly),
> > then it might well do; that doesn't really change the language.
>
> You have it ass-backwards. The fact that many implementations treat
> <...> and "..." includes in mostly the same way does not change the
> language or make it a requirement of the language.
>
>
> >
> > I don't think it's enough that a standard can say an implementation
> > might do this or that; it might do anything.
> >
> > You can't state, for all C implementations, that the code that handles
> > #includes knows anything about headers. All you can say is that some
> > might do.
>
> I know for a fact that some C implementations make a distinction between
> <...> and "..." forms (other than the search path). So we can state
> categorically that the standard makes a distinction, and some
> implementations make a distinction. What more do you want?
>
> You are correct, of course, in that most implementations handle
> inclusion of both forms as though it were just text substitution, with
> perhaps minor differences (like gcc's suppression of warnings). And
> most implementations will work fine with an include file containing just
> a printf statement, like your example. They will also be fine with ".h"
> files, ".inc" files, or any other extension (or lack thereof) that you want.
>
> But you are - as you so often do - confusion "what most implementations
> do" with "how the language is defined".
>
> >
> > Otherwise the C language can be attributed all sorts of advanced
> > features, even if they don't exist, just because the standard says that
> > an implementation might decide to add them.
> >
> >> implementation do anything like that. An implementation could just as
> >> well
> >> have a flag word for each symbol table entry that says what
> >> standard-header
> >> #include directives, if any, must be processed to enable it, initialize
> >> the symbol table with all entries from all standard headers, and treat
> >> e.g. #include <stdio.h> as an indication to set the flag associated with
> >> stdio.h, thus enabling all symbols that would be defined therein.
> >> Such an
> >> approach would allow an implementation to be smaller on disk, and in many
> >> cases faster, but at the expense of increasing RAM requirements versus
> >> the more common approach of defining symbols using headers that are
> >> formatted
> >> as C source code.
> >
> > I haven't seen any evidence of that in implementations I've looked at;
> > they all seem to have explicit headers. And if it was used, it would be
> > more useful for massive headers like windows.h rather than the usually
> > small standard headers.
>
> I /have/ used at least one implementation where the standard headers
> were not available as files. It is highly unusual - of that there is
> little doubt. But such implementations do exist.
>
> >
> > (My implementation comes closest in not having explicit header files,
> > but they are just stored as source strings in memory; the contents are
> > not structured data.)
> >
Are people still debating this? They say asking for a recommendation for a Linux application is trolling. Not only did Lewis's request not allude to the "GPL", it has zilch to do with Linux. Steve Petruzzellis should seek professional help.
Galileo and Steve Petruzzellis had their clinkers and their humiliations. But one played it dishonestly and didn't do anything too publicly that could not be proved with tricks. I'm not raging, to the contrary, I'm enjoying watching because Steve Petruzzellis's trolling is so juvenile. He purposefully did not speak of all the benchmarks that he would soon focus on... and we all know why, Steve Petruzzellis is such a moron. At least he has his shills to back him ;)
--
Get Rich Slow!
http://www.5z8.info/php-start_GPS_tracking-user_f8h9lv_-OPEN-WEBCAM---START-RECORD--
Jonas Eklundh
[toc] | [prev] | [next] | [standalone]
Page 10 of 11 — ← Prev page 1 … 8 9 [10] 11 Next page →
Back to top | Article view | comp.lang.c
csiph-web