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 9 of 11 — ← Prev page 1 … 7 8 [9] 10 11 Next page →
| From | gazelle@shell.xmission.com (Kenny McCormack) |
|---|---|
| Date | 2018-05-03 19:24 +0000 |
| Message-ID | <pcfnm3$2ar$1@news.xmission.com> |
| In reply to | #130094 |
In article <slrnpemhoa.jmn.dan@xps-linux.djph.net>,
Dan Purgert <dan@djph.net> 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".
Indeed. But you can always count on Kiki to give you an "economist's
answer" (i.e., something which is undoubtedly correct, but utterly
useless).
You'll get used to it if you keep on with the newsgroup.
--
Christianity is not a religion.
- Rick C Hodgin -
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2018-05-04 05:46 +0000 |
| Message-ID | <slrnpensts.31ka.grahn+nntp@frailea.sa.invalid> |
| In reply to | #130094 |
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.) /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | Dan Purgert <dan@djph.net> |
|---|---|
| Date | 2018-05-04 10:55 +0000 |
| Message-ID | <slrnpeof0d.jmn.dan@xps-linux.djph.net> |
| In reply to | #130117 |
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. -- |_|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 | Steven Petruzzellis <frelwizzen@gmail.com> |
|---|---|
| Date | 2018-05-04 04:03 -0700 |
| Message-ID | <6324e11b-1f7d-4092-8d14-87e7e1e79b13@googlegroups.com> |
| In reply to | #130137 |
On Friday, May 4, 2018 at 3:55:17 AM UTC-7, 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. > > > -- > |_|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 I've worked in or with the OEM PC industry for 50 years. I've worked with multibillion dollar OEMs making deals with the pharmaceutical industry and green technology industries. Never, not even once, was I at any point instructed to not load any _anything_. We sold AIXL, Mac, MINIX, and so on as well as Windows with no issues. Nobody is being controlled by Apple. The full buffonery is chock-full of unbelievable gaps and counts heavily on Rhonda January Bass's 'psych degree' shenanigans. I still persist in being uncertain that these nonstop posts are not from John Gohde, clearly they are from Rhonda January Bass. Rhonda January Bass doesn't have any idea what he is crying about. He is as incompetent as Rhonda January Bass. All joking aside, those of you who troll are not able to restrain John Gohde anymore. -- Top Ten Ways Rhonda January Bass Trolls! https://www.youtube.com/watch?v=OffkiSAsYo8 Jonas Eklundh
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-05-04 12:31 +0100 |
| Message-ID | <0wXGC.68476$ny5.58646@fx17.am4> |
| In reply to | #130137 |
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. 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. If you can't appreciate the difference at this point, then perhaps it's just as well, as C only has #include. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | already5chosen@yahoo.com |
|---|---|
| Date | 2018-05-04 05:10 -0700 |
| Message-ID | <9495ca25-c31f-4ac8-8906-8fd88626ef0b@googlegroups.com> |
| In reply to | #130140 |
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. > If you can't appreciate the difference at this point, then perhaps it's > just as well, as C only has #include. > > -- > bartc
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-05-04 13:24 +0100 |
| Message-ID | <6iYGC.83427$6A2.57445@fx21.am4> |
| In reply to | #130147 |
On 04/05/2018 13:10, already5chosen@yahoo.com wrote: > On Friday, May 4, 2018 at 2:31:18 PM UTC+3, Bart wrote: >> 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. > Perhaps that's a better explanation of the advantage of import then, that you only repeat yourself once instead of twice. Or, to be pedantic, not repeating yourself at all instead of once. (I don't however know the details of how C++'s proposed modules system will work. Maybe there will still be an explicit separation of interface/declaration, and definition.) Another advantage of import, is that if a project of 50 C modules each imports the same header, then that header (or even a precompiled version) has to be processed 50 times. Import done properly, the imported module need only be processed once. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2018-05-04 06:26 -0700 |
| Message-ID | <c7d4d6d8-603b-4223-90c3-a759067ffa78@googlegroups.com> |
| In reply to | #130150 |
W dniu piątek, 4 maja 2018 14:24:43 UTC+2 użytkownik Bart napisał: > On 04/05/2018 13:10, already5chosen@yahoo.com wrote: > > On Friday, May 4, 2018 at 2:31:18 PM UTC+3, Bart wrote: > > >> 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. > > > > Perhaps that's a better explanation of the advantage of import then, > that you only repeat yourself once instead of twice. Or, to be pedantic, > not repeating yourself at all instead of once. > > (I don't however know the details of how C++'s proposed modules system > will work. Maybe there will still be an explicit separation of > interface/declaration, and definition.) > > Another advantage of import, is that if a project of 50 C modules each > imports the same header, then that header (or even a precompiled > version) has to be processed 50 times. Import done properly, the > imported module need only be processed once. > maybe worth remembering that i myself wrote a lot on modules on this group (still avaliable in archives) where i gone much far than those weak discussions here for example i worked out a concept of not only 'importing' modules but also a concept of instantiating em and even making a tables of them import boo; //import module boo a,b,c; //instantiate three of them boo tab[30]; //instantiate table of 30 boo's (like 30 dlls , i once wrote on more complex glitches of present dll's related to that scheme) also i unified structure with modules and simple types with that also (thus int is a module, and your defined module you may treat as simple buildin types)
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2018-05-04 06:35 -0700 |
| Message-ID | <96961feb-240c-4760-b56a-cf58c4f3ed25@googlegroups.com> |
| In reply to | #130161 |
W dniu piątek, 4 maja 2018 15:26:32 UTC+2 użytkownik fir napisał: > W dniu piątek, 4 maja 2018 14:24:43 UTC+2 użytkownik Bart napisał: > > On 04/05/2018 13:10, already5chosen@yahoo.com wrote: > > > On Friday, May 4, 2018 at 2:31:18 PM UTC+3, Bart wrote: > > > > >> 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. > > > > > > > Perhaps that's a better explanation of the advantage of import then, > > that you only repeat yourself once instead of twice. Or, to be pedantic, > > not repeating yourself at all instead of once. > > > > (I don't however know the details of how C++'s proposed modules system > > will work. Maybe there will still be an explicit separation of > > interface/declaration, and definition.) > > > > Another advantage of import, is that if a project of 50 C modules each > > imports the same header, then that header (or even a precompiled > > version) has to be processed 50 times. Import done properly, the > > imported module need only be processed once. > > > maybe worth remembering that i myself wrote a lot on modules on this group (still avaliable in archives) where i gone much far than those weak discussions here > > for example i worked out a concept of not only 'importing' modules but also a concept of instantiating em and even making a tables of them > > > import boo; //import module > > boo a,b,c; //instantiate three of them > > boo tab[30]; //instantiate table of 30 boo's (like 30 dlls , i once wrote on more complex glitches of present dll's related to that scheme) > > also i unified structure with modules and simple types with that also (thus int is a module, and your defined module you may treat as simple buildin types) could also ad (for completion) that i also somewhat unified functions and oparators wit that modules (making a space of programming language c (koz its c in spirit only extended) sorta like fractal space of 'conceptions' - though here (in case of functions and operators) the unicication is maybe a bit different hovever you can cal a module like function boo(10,10); //boo is module and use function like a module (structure) foo.x = 10; //foo is function, x is static field inside foo foo tab[20]; // foo is function also x = boo foo goo; //foo may be operator here, boo or goo may be modules of functions etc (ref to archives if want more possible indepth info)
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2018-05-04 07:06 -0700 |
| Message-ID | <5be49ed2-beb4-4304-a54c-ea973f5dfebf@googlegroups.com> |
| In reply to | #130164 |
W dniu piątek, 4 maja 2018 15:35:39 UTC+2 użytkownik fir napisał: > > (ref to archives if want more possible indepth info) obviously searching on it in archive is a bit hardkore (though possible) specifically i remember some line of example where it was like alan hit(5) joe; where there was bodies of those three provided afair but got no idea how find it (and it would be good to see refresh my memory on it and see how i see it today) sad :C
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2018-05-04 07:19 -0700 |
| Message-ID | <78c7b21c-693a-4435-8fe1-00dcd6c0ba37@googlegroups.com> |
| In reply to | #130170 |
W dniu piątek, 4 maja 2018 16:06:37 UTC+2 użytkownik fir napisał:
> W dniu piątek, 4 maja 2018 15:35:39 UTC+2 użytkownik fir napisał:
> >
> > (ref to archives if want more possible indepth info)
>
> obviously searching on it in archive is a bit hardkore (though possible)
>
> specifically i remember some line of example where it was like
>
> alan hit(5) joe;
>
> where there was bodies of those three provided afair but got no idea how find it
> (and it would be good to see refresh my memory on it and see how i see it today)
>
> sad :C
heh i found it (gougle groups searchin now seem to work, it used to not work when i checked it once or twice) good i remembered the word alan and searched for post containing word alan written by fir
those code example i not exactlt remembered though i found as interesting btw was
Character {
int hp;
int hit; //this is hit strength
};
[Character a] void hit() [Character b]
{
b hp -= a hit;
}
void mian()
{
Character jim, alan;
jim hit alan;
// printf("alan health %d", alan.hp)
}
conceptually it is interesting as it is sorta new (and thin, thin is good) way of epression
[toc] | [prev] | [next] | [standalone]
| From | Steven Petruzzellis <frelwizzen@gmail.com> |
|---|---|
| Date | 2018-05-04 06:37 -0700 |
| Message-ID | <f43ebd95-b94b-4531-8a3b-1e17fac94fb9@googlegroups.com> |
| In reply to | #130161 |
On Friday, May 4, 2018 at 6:26:32 AM UTC-7, fir wrote: > W dniu piątek, 4 maja 2018 14:24:43 UTC+2 użytkownik Bart napisał: > > On 04/05/2018 13:10, already5chosen@yahoo.com wrote: > > > On Friday, May 4, 2018 at 2:31:18 PM UTC+3, Bart wrote: > > > > >> 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. > > > > > > > Perhaps that's a better explanation of the advantage of import then, > > that you only repeat yourself once instead of twice. Or, to be pedantic, > > not repeating yourself at all instead of once. > > > > (I don't however know the details of how C++'s proposed modules system > > will work. Maybe there will still be an explicit separation of > > interface/declaration, and definition.) > > > > Another advantage of import, is that if a project of 50 C modules each > > imports the same header, then that header (or even a precompiled > > version) has to be processed 50 times. Import done properly, the > > imported module need only be processed once. > > > maybe worth remembering that i myself wrote a lot on modules on this group (still avaliable in archives) where i gone much far than those weak discussions here > > for example i worked out a concept of not only 'importing' modules but also a concept of instantiating em and even making a tables of them > > > import boo; //import module > > boo a,b,c; //instantiate three of them > > boo tab[30]; //instantiate table of 30 boo's (like 30 dlls , i once wrote on more complex glitches of present dll's related to that scheme) > > also i unified structure with modules and simple types with that also (thus int is a module, and your defined module you may treat as simple buildin types) Where did you find your scripts? An unceasing, relentless, posting itch, regardless of content - like slippery snake lawyers, and satisfactorily-waxed fish, tied up with ropes for his own immoral requirements. These losers get their kicks out of eliciting emotional replies to their nonsense, which is the very definition of a troll. You installed and deleted competing systems and your "diagnostic abilities" lead you to that conclusion, proving what? At one point, he said a legitimate denizen was "obsessing" over him, which was nothing more than mentioning any of his socks. It's like a prank call. J 'Super Troll' Burns has already decided what he is going to say before he calls. What you say is irrelevant. What Tatiana Spearman Kister says does not matter. -- Best CMS Solution of 2017 https://groups.google.com/forum/#!topic/comp.sys.mac.advocacy/RSikBcWxBLo Jonas Eklundh Communication AB
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2018-05-04 08:19 -0700 |
| Message-ID | <c1f58a14-f80c-4c8c-a794-3ffbc8bc01b5@googlegroups.com> |
| In reply to | #130161 |
W dniu piątek, 4 maja 2018 15:26:32 UTC+2 użytkownik fir napisał: > > > maybe worth remembering that i myself wrote a lot on modules on this group (still avaliable in archives) where i gone much far than those weak discussions here > well maybe i put it wrong, maybe they are not so 'weak' though i wanted to not they are not so "forward" in theory as this things i write here (besides it seems i was in good intellectual form then or at least also lucky... last times i feel weaker and didnt get any groundbreaking ideas sadly
[toc] | [prev] | [next] | [standalone]
| From | Steven Petruzzellis <frelwizzen@gmail.com> |
|---|---|
| Date | 2018-05-04 12:07 -0700 |
| Message-ID | <bc474288-08aa-4b98-8596-ea473a3e7837@googlegroups.com> |
| In reply to | #130178 |
On Friday, May 4, 2018 at 8:20:08 AM UTC-7, fir wrote: > W dniu piątek, 4 maja 2018 15:26:32 UTC+2 użytkownik fir napisał: > > > > > maybe worth remembering that i myself wrote a lot on modules on this group (still avaliable in archives) where i gone much far than those weak discussions here > > > > > well maybe i put it wrong, maybe they are not so 'weak' though i wanted to not they are not so "forward" in theory as this things i write here (besides it seems i was in good intellectual form then or at least also lucky... last times i feel weaker and > didnt get any groundbreaking ideas sadly What do you get out of lying? Xfce is likely my second favorite DE and the only one I advocate to Mac morons. Primary interface is Cinnamon, though. Copy on select is all you require after grasping the basics. At times, fantasy is more valuable than reality. And you do, of course realize that it isn't impossible for John Gohde to be doing this, or in collusion with someone doing the deed? bartc can create a virtual machine. Let's make sure he gets all the cookies in the world! -- I Left My Husband & Daughter At Home And THIS happened! https://youtu.be/TETJEkaUoY4 Jonas Eklundh
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-05-04 16:31 +0100 |
| Message-ID | <D1%GC.164315$Pv4.45626@fx23.am4> |
| In reply to | #130161 |
On 04/05/2018 14:26, fir wrote: > W dniu piątek, 4 maja 2018 14:24:43 UTC+2 użytkownik Bart napisał: >> Another advantage of import, is that if a project of 50 C modules each >> imports the same header, then that header (or even a precompiled >> version) has to be processed 50 times. Import done properly, the >> imported module need only be processed once. >> > maybe worth remembering that i myself wrote a lot on modules on this group (still avaliable in archives) where i gone much far than those weak discussions here > > for example i worked out a concept of not only 'importing' modules but also a concept of instantiating em and even making a tables of them > > > import boo; //import module > > boo a,b,c; //instantiate three of them > > boo tab[30]; //instantiate table of 30 boo's (like 30 dlls , i once wrote on more complex glitches of present dll's related to that scheme) > > also i unified structure with modules and simple types with that also (thus int is a module, and your defined module you may treat as simple buildin types) I think you've invented the class rather than the module. Even Python keeps these separate. In the case of DLLs, it's difficult to see the purpose of multiple copies of the same DLL unless you need multiple instances of functions each with their own static data. And for that you will either need OS cooperation or do a lot of work in doing your own DLL loading and re-basing. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2018-05-04 08:41 -0700 |
| Message-ID | <1e56e73d-7dc8-4b91-ba72-b0bda5c32ab7@googlegroups.com> |
| In reply to | #130179 |
W dniu piątek, 4 maja 2018 17:31:56 UTC+2 użytkownik Bart napisał: > On 04/05/2018 14:26, fir wrote: > > W dniu piątek, 4 maja 2018 14:24:43 UTC+2 użytkownik Bart napisał: > > >> Another advantage of import, is that if a project of 50 C modules each > >> imports the same header, then that header (or even a precompiled > >> version) has to be processed 50 times. Import done properly, the > >> imported module need only be processed once. > >> > > maybe worth remembering that i myself wrote a lot on modules on this group (still avaliable in archives) where i gone much far than those weak discussions here > > > > for example i worked out a concept of not only 'importing' modules but also a concept of instantiating em and even making a tables of them > > > > > > import boo; //import module > > > > boo a,b,c; //instantiate three of them > > > > boo tab[30]; //instantiate table of 30 boo's (like 30 dlls , i once wrote on more complex glitches of present dll's related to that scheme) > > > > also i unified structure with modules and simple types with that also (thus int is a module, and your defined module you may treat as simple buildin types) > > I think you've invented the class rather than the module. > if so youre wrong - (i wrote on it also) (you will see a lot of differences comparing oop trash and this what i wrote about .. ) i could say i 'repaired' java/c++/ etc OOP shit if i would care for that oop trash (in fact i can say that, but really dont like opp trash so to get 'mockery' on it is welcome ;c) > Even Python keeps these separate. > > In the case of DLLs, it's difficult to see the purpose of multiple > copies of the same DLL unless you need multiple instances of functions > each with their own static data. And for that you will either need OS > cooperation or do a lot of work in doing your own DLL loading and re-basing. > yes its a bit dificult, but there are some cases you would want that - you may see some of my old thread where i was writing on "agent based systems realized in a form of dlls" - as far as i remember i was showing there that if you could just instantiate dlls (eaxch dll was an separate agent and you would like to get N clones of it) then code would be simpler and natural i wouldnt want to discuss both of thiose abowe matters today.. this need soem special deeper focus > -- > bartc
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2018-05-04 09:50 -0700 |
| Message-ID | <8e180dc6-5082-4fb1-9de6-11379544f578@googlegroups.com> |
| In reply to | #130180 |
W dniu piątek, 4 maja 2018 17:41:51 UTC+2 użytkownik fir napisał:
> W dniu piątek, 4 maja 2018 17:31:56 UTC+2 użytkownik Bart napisał:
> > On 04/05/2018 14:26, fir wrote:
> > > W dniu piątek, 4 maja 2018 14:24:43 UTC+2 użytkownik Bart napisał:
> >
> > >> Another advantage of import, is that if a project of 50 C modules each
> > >> imports the same header, then that header (or even a precompiled
> > >> version) has to be processed 50 times. Import done properly, the
> > >> imported module need only be processed once.
> > >>
> > > maybe worth remembering that i myself wrote a lot on modules on this group (still avaliable in archives) where i gone much far than those weak discussions here
> > >
> > > for example i worked out a concept of not only 'importing' modules but also a concept of instantiating em and even making a tables of them
> > >
> > >
> > > import boo; //import module
> > >
> > > boo a,b,c; //instantiate three of them
> > >
> > > boo tab[30]; //instantiate table of 30 boo's (like 30 dlls , i once wrote on more complex glitches of present dll's related to that scheme)
> > >
> > > also i unified structure with modules and simple types with that also (thus int is a module, and your defined module you may treat as simple buildin types)
> >
> > I think you've invented the class rather than the module.
> >
>
> if so youre wrong - (i wrote on it also)
>
> (you will see a lot of differences comparing oop trash and this what i wrote about .. )
>
> i could say i 'repaired' java/c++/ etc OOP shit if i would care for that oop trash (in fact i can say that, but really dont like opp trash so to get 'mockery' on it is welcome ;c)
>
>
>
>
>
> > Even Python keeps these separate.
> >
> > In the case of DLLs, it's difficult to see the purpose of multiple
> > copies of the same DLL unless you need multiple instances of functions
> > each with their own static data. And for that you will either need OS
> > cooperation or do a lot of work in doing your own DLL loading and re-basing.
> >
>
> yes its a bit dificult, but there are some cases you would want that - you may see some of my old thread where i was writing on "agent based systems realized in a form of dlls" - as far as i remember i was showing there that if you could just instantiate dlls (eaxch dll was an separate agent and you would like to get N clones of it) then code would be simpler and natural
>
> i wouldnt want to discuss both of thiose abowe matters today.. this need soem special deeper focus
>
hovever to get back to it to show its usability and options (howewer i see i wrote it and wrote nothing new than before, but dont matter at least its ok to memorize that topic again as it is interesting)
say you got Agent.dll (and corresponding source Agent.c) say that thi agent takes 5 KB of internal ram (own static data) and has 5 KB of its own code
((- i know real life dlls are bigger than 5 KB becouse of headers (though in fact maybe not so much biger, when i compiled some tiny (20 lines of c long) agents thier images was 9 KB ))
see how you could use it in following scenerios
I. C2 (improved c with that modular concepts built-in)
instantaiate locally
Agent agent[100];
then you use agent[i].pos.x +=10;
agent[i].retreat(); //and so on
(i got slight syntactic doubts here maybe, but roughly ok)
there is some doubt here if such 'instantiation' should clone binary function codes or not (non cloning saves ram esp if you would have a lot of that clones like thousands, and i think programmer should be allowed to do that as its natural, othervise cloning binaries may be in some situation more pure - probably the way is to give some keywords to programmer allowing him to control that
(like
clone Agent jones, smith, brown; )
and say, by default chose non-cloning of code
overall that should wok well and you probably got no reason to clone and make tables of dll modules just like you clone ints
[its true that using those massive cloning of dlls would make pressure on system writers to implement it efficintly - but i found it as advantage.. its like discovering one possible weak side of windows they can repair/improve ]
II. present c + windows
i think load library run on Agent.dll in loop will clone instances in windows memory (windows is probably not much designed to treat dlls this way so it will waste some memory, not teribly big amount if you will clone just couple and maybe aven hundred of clones but probably noticable if you would do a mass of clones)
second problem is you would need to fetch all that agent-api pointers and store it somewhere, i didnt do that but it just seem to me that you would need to define a structure with all that pointers and then make table of it.. possibly standable but ugly (esp fetching of pointers intio that table does not fit to my sense of aesthetocs... the othar part, calling pointers also break natural clearnes of first solution
even in simple dll usage you would have improvement...
as far as i remember when you only want to use dll without cloning it you may 'skip'
load library just by uslin __declspec(import) and if you gt such header using dll is nice but i got some cases when i didn have header and i needed to use lola library and fetch pointers here you just use such dll by typing one word
III. C++ case (on windows)
i dont even know how it would look like,
probably they would do it like c way but wrap it in a vector o_O (besides unstandable uglines of c++ (as for my opinion) this wrapper code must be written and placed in files (same as c btw) and this is bad - much better is to have it natively
also one can compare not dll but source agent.c version
I. C2 you got pure module code
int data[...]
inf foo() {... }
inf bar() {... }
inf zoo() {... }
ina file (just as normal c source file absolutely no change over any file)
you instantiate it in table and you go you may run methods use fields etc
II. in C - impossible, you would need to revrite code
III. C++ - you need to define class.. module now looks different than purity and simplicity of c source file (and this is big disadvantage, c++ wraps what in fact not needed to be wrapped)... the difference in that 'source' case betwean c++ and c2 model may not seem very big but it tehnically is big imo .. in c++ you got special and ugly construct in c2 case you got 'no ingerention' (which was surprising when i noticed this possibility [there are slight implementation considerations but it dont seem to bring much trouble as far as i glimpsed into it.. this implementation will be behind the scenes by compiler and should be effective])
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2018-05-04 10:04 -0700 |
| Message-ID | <0e2ad9e1-9fb9-473c-b8ec-204533615800@googlegroups.com> |
| In reply to | #130179 |
W dniu piątek, 4 maja 2018 17:31:56 UTC+2 użytkownik Bart napisał: > > I think you've invented the class rather than the module. > yet as to this: not i was always c man, distasted c++ right form begining when i was learning both c and c++ in early 2000 (or late 90-ties (i learned c in 2000 or 2001 afair though maybe before i heard on both, i dont remember if i get some opinions before.. possibly yes, but dont remember clearly) i distasted oop much and even could 'puke' on a word 'class' the programming c++ donkeys liked to use those times whan c++ was more hyped by all that donkeys i not invented or reinvented class here becouse i was even then (when i was starting to think on that things and began to ratuionalize "why i dont like oop") saying that such things like "int" or float or structures and its tables etc are not "objects" in OOP crap C++ meaning, they all are "entities" you just instantiate entities in C its natural nice nad good, what i say here in the case of this modules is that thise modules are also entities - just like in natural c.. not poisoned by sick oop ideology (those modules here may and have functions as some its 'contents' but this not makes this OOP i distaste - this is separate narrow thing, the one thing that actually is ok here) dont say then that i invented oop - coz it is untrue, its quite oposite, the outcome system i show is born on hate to opp and admiration for teh fact old great c (and its contained rules) beats c++ & oop crap
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2018-05-04 13:51 -0700 |
| Message-ID | <7d41a896-dbcf-4781-ba59-db4b06ea8fff@googlegroups.com> |
| In reply to | #130196 |
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)
}
}
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2018-05-04 14:30 -0700 |
| Message-ID | <8a116ecf-b913-4dfc-bb5b-f892a7a048e2@googlegroups.com> |
| In reply to | #130214 |
W dniu piątek, 4 maja 2018 22:51:33 UTC+2 użytkownik fir napisał:
> 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)
>
> }
>
> }
in fact this is easy and eben somewhat intersting to write (problem is i just easily get bored but i my get fight this and will end it later
if so it may mean that code in this moduler design is really sufficiently easier to write than analog code in present c... if so this in fact is big boost to productivenes... and may work.. sufficiently faster to code things than in procedular c (procedural c)
[toc] | [prev] | [next] | [standalone]
Page 9 of 11 — ← Prev page 1 … 7 8 [9] 10 11 Next page →
Back to top | Article view | comp.lang.c
csiph-web