Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #7572 > unrolled thread
| Started by | David Remacle <listes@NOSpamclampin.com> |
|---|---|
| First post | 2011-07-04 07:31 +0000 |
| Last post | 2011-07-06 16:07 +0100 |
| Articles | 20 on this page of 197 — 35 participants |
Back to article view | Back to comp.lang.c
C is fixed or not ? David Remacle <listes@NOSpamclampin.com> - 2011-07-04 07:31 +0000
Re: C is fixed or not ? China Blue Dolls <chine.bleu@yahoo.com> - 2011-07-04 00:46 -0700
Re: C is fixed or not ? "MikeP" <mp011011@some.org> - 2011-07-04 23:03 -0500
Re: C is fixed or not ? China Blue Dolls <chine.bleu@yahoo.com> - 2011-07-04 21:17 -0700
Re: C is fixed or not ? "MikeP" <mp011011@some.org> - 2011-07-07 16:59 -0500
Re: C is fixed or not ? Chris H <chris@phaedsys.org> - 2011-07-04 09:06 +0100
Re: C is fixed or not ? "MikeP" <mp011011@some.org> - 2011-07-04 23:05 -0500
Re: C is fixed or not ? Chris H <chris@phaedsys.org> - 2011-07-06 08:12 +0100
Re: C is fixed or not ? "MikeP" <mp011011@some.org> - 2011-07-07 17:02 -0500
Re: C is fixed or not ? "Joachim Schmitz" <nospam.jojo@schmitz-digital.de> - 2011-07-04 10:17 +0200
Re: C is fixed or not ? Noob <root@127.0.0.1> - 2011-07-04 11:37 +0200
Re: C is fixed or not ? Chris H <chris@phaedsys.org> - 2011-07-04 11:31 +0100
Re: C is fixed or not ? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-07-04 08:01 -0700
Re: C is fixed or not ? Noob <root@127.0.0.1> - 2011-07-04 17:29 +0200
Re: C is fixed or not ? James Kuyper <jameskuyper@verizon.net> - 2011-07-04 12:01 -0400
Re: C is fixed or not ? jacob navia <jacob@spamsink.net> - 2011-07-04 19:20 +0200
Re: C is fixed or not ? Ian Collins <ian-news@hotmail.com> - 2011-07-05 07:53 +1200
Re: C is fixed or not ? jacob navia <jacob@spamsink.net> - 2011-07-04 22:39 +0200
Re: C is fixed or not ? Ian Collins <ian-news@hotmail.com> - 2011-07-05 15:33 +1200
Re: C is fixed or not ? "MikeP" <mp011011@some.org> - 2011-07-04 23:32 -0500
Re: C is fixed or not ? "MikeP" <mp011011@some.org> - 2011-07-04 23:28 -0500
Re: C is fixed or not ? jacob navia <jacob@spamsink.net> - 2011-07-05 07:29 +0200
Re: C is fixed or not ? "MikeP" <mp011011@some.org> - 2011-07-07 17:17 -0500
Re: C is fixed or not ? Rui Maciel <rui.maciel@gmail.com> - 2011-07-06 03:37 +0100
Re: C is fixed or not ? "MikeP" <mp011011@some.org> - 2011-07-07 17:21 -0500
Re: C is fixed or not ? lawrence.jones@siemens.com - 2011-07-06 00:09 -0400
Re: C is fixed or not ? jacob navia <jacob@spamsink.net> - 2011-07-06 07:59 +0200
Re: C is fixed or not ? Keith Thompson <kst-u@mib.org> - 2011-07-05 23:52 -0700
Re: C is fixed or not ? lawrence.jones@siemens.com - 2011-07-06 11:20 -0400
Re: C is fixed or not ? Keith Thompson <kst-u@mib.org> - 2011-07-06 09:30 -0700
Re: C is fixed or not ? Ian Collins <ian-news@hotmail.com> - 2011-07-07 08:16 +1200
Re: C is fixed or not ? Walter Banks <walter@bytecraft.com> - 2011-07-07 11:13 -0400
Re: C is fixed or not ? jacob navia <jacob@spamsink.net> - 2011-07-07 17:23 +0200
Re: C is fixed or not ? jameskuyper <jameskuyper@gmail.com> - 2011-07-08 08:11 -0700
Re: C is fixed or not ? Rui Maciel <rui.maciel@gmail.com> - 2011-07-06 03:21 +0100
Re: C is fixed or not ? Keith Thompson <kst-u@mib.org> - 2011-07-05 19:41 -0700
Re: C is fixed or not ? Rui Maciel <rui.maciel@gmail.com> - 2011-07-06 04:15 +0100
Re: C is fixed or not ? James Kuyper <jameskuyper@verizon.net> - 2011-07-05 23:42 -0400
Re: C is fixed or not ? Shao Miller <sha0.miller@gmail.com> - 2011-07-06 08:44 -0400
Re: C is fixed or not ? Rui Maciel <rui.maciel@gmail.com> - 2011-07-06 15:00 +0100
Re: C is fixed or not ? James Kuyper <jameskuyper@verizon.net> - 2011-07-06 23:22 -0400
Re: C is fixed or not ? "MikeP" <mp011011@some.org> - 2011-07-07 22:23 -0500
Re: C is fixed or not ? lawrence.jones@siemens.com - 2011-07-06 11:32 -0400
Re: C is fixed or not ? ImpalerCore <jadill33@gmail.com> - 2011-07-06 10:27 -0700
Re: C is fixed or not ? jacob navia <jacob@spamsink.net> - 2011-07-06 19:41 +0200
Re: C is fixed or not ? lawrence.jones@siemens.com - 2011-07-07 00:19 -0400
Re: C is fixed or not ? jacob navia <jacob@spamsink.net> - 2011-07-07 09:24 +0200
Re: C is fixed or not ? lawrence.jones@siemens.com - 2011-07-10 16:27 -0400
Re: C is fixed or not ? Rui Maciel <rui.maciel@gmail.com> - 2011-07-07 00:21 +0100
Re: C is fixed or not ? Shao Miller <sha0.miller@gmail.com> - 2011-07-06 23:20 -0400
Re: C is fixed or not ? Shao Miller <sha0.miller@gmail.com> - 2011-07-07 00:04 -0400
Re: C is fixed or not ? "MikeP" <mp011011@some.org> - 2011-07-07 22:52 -0500
Re: C is fixed or not ? Robert Wessel <robertwessel2@yahoo.com> - 2011-07-07 23:47 -0500
Re: C is fixed or not ? Shao Miller <sha0.miller@gmail.com> - 2011-07-08 01:59 -0400
Re: C is fixed or not ? lawrence.jones@siemens.com - 2011-07-07 00:22 -0400
Re: C is fixed or not ? Rui Maciel <rui.maciel@gmail.com> - 2011-07-07 15:25 +0100
Re: C is fixed or not ? Ian Collins <ian-news@hotmail.com> - 2011-07-08 08:01 +1200
Re: C is fixed or not ? "MikeP" <mp011011@some.org> - 2011-07-07 22:59 -0500
Re: C is fixed or not ? "MikeP" <mp011011@some.org> - 2011-07-07 22:57 -0500
Re: C is fixed or not ? lawrence.jones@siemens.com - 2011-07-10 16:03 -0400
Re: C is fixed or not ? Ian Collins <ian-news@hotmail.com> - 2011-07-11 08:19 +1200
Re: C is fixed or not ? lawrence.jones@siemens.com - 2011-07-12 00:31 -0400
Re: C is fixed or not ? Ian Collins <ian-news@hotmail.com> - 2011-07-12 19:39 +1200
Re: C is fixed or not ? James Kuyper <jameskuyper@verizon.net> - 2011-07-12 06:06 -0400
Re: C is fixed or not ? Ian Collins <ian-news@hotmail.com> - 2011-07-12 22:14 +1200
Re: C is fixed or not ? Shao Miller <sha0.miller@gmail.com> - 2011-07-07 19:11 -0400
Re: C is fixed or not ? "MikeP" <mp011011@some.org> - 2011-07-07 22:49 -0500
Re: C is fixed or not ? Keith Thompson <kst-u@mib.org> - 2011-07-06 17:05 -0700
Re: C is fixed or not ? lawrence.jones@siemens.com - 2011-07-07 00:27 -0400
Re: C is fixed or not ? James Kuyper <jameskuyper@verizon.net> - 2011-07-07 06:39 -0400
Re: C is fixed or not ? jacob navia <jacob@spamsink.net> - 2011-07-07 12:45 +0200
POSIX threads hard to implement in Windows (was: C is fixed or not ?) Noob <root@127.0.0.1> - 2011-07-07 15:17 +0200
Re: POSIX threads hard to implement in Windows William Ahern <william@wilbur.25thandClement.com> - 2011-07-07 11:21 -0700
Re: POSIX threads hard to implement in Windows Ian Collins <ian-news@hotmail.com> - 2011-07-08 08:07 +1200
Re: POSIX threads hard to implement in Windows Robert Wessel <robertwessel2@yahoo.com> - 2011-07-07 16:01 -0500
Re: POSIX threads hard to implement in Windows "MikeP" <mp011011@some.org> - 2011-07-07 21:12 -0500
Re: POSIX threads hard to implement in Windows Robert Wessel <robertwessel2@yahoo.com> - 2011-07-07 23:33 -0500
Re: POSIX threads hard to implement in Windows "MikeP" <mp011011@some.org> - 2011-07-07 23:49 -0500
Re: POSIX threads hard to implement in Windows BGB <cr88192@hotmail.com> - 2011-08-03 07:32 -0700
Re: POSIX threads hard to implement in Windows William Ahern <william@wilbur.25thandClement.com> - 2011-07-07 15:06 -0700
Re: POSIX threads hard to implement in Windows lawrence.jones@siemens.com - 2011-07-10 16:08 -0400
Re: POSIX threads hard to implement in Windows William Ahern <william@wilbur.25thandClement.com> - 2011-07-10 16:09 -0700
Re: POSIX threads hard to implement in Windows James Kuyper <jameskuyper@verizon.net> - 2011-07-11 06:20 -0400
Re: POSIX threads hard to implement in Windows Ian Collins <ian-news@hotmail.com> - 2011-07-11 22:36 +1200
Re: POSIX threads hard to implement in Windows scott@slp53.sl.home (Scott Lurndal) - 2011-07-11 16:18 +0000
Re: POSIX threads hard to implement in Windows (was: C is fixed or not ?) Joshua Maurice <joshuamaurice@gmail.com> - 2011-07-07 19:01 -0700
Re: POSIX threads hard to implement in Windows (was: C is fixed or not ?) "Ersek, Laszlo" <lacos@caesar.elte.hu> - 2011-07-14 23:05 +0200
Re: C is fixed or not ? Rui Maciel <rui.maciel@gmail.com> - 2011-07-07 15:30 +0100
Re: C is fixed or not ? James Kuyper <jameskuyper@verizon.net> - 2011-07-07 11:00 -0400
Re: C is fixed or not ? Robert Wessel <robertwessel2@yahoo.com> - 2011-07-07 13:30 -0500
Re: C is fixed or not ? "MikeP" <mp011011@some.org> - 2011-07-07 21:30 -0500
Re: C is fixed or not ? Shao Miller <sha0.miller@gmail.com> - 2011-07-08 02:34 -0400
Re: C is fixed or not ? Rui Maciel <rui.maciel@gmail.com> - 2011-07-13 01:35 +0100
Re: C is fixed or not ? James Kuyper <jameskuyper@verizon.net> - 2011-07-12 22:30 -0400
Re: C is fixed or not ? "J. J. Farrell" <jjf@bcs.org.uk> - 2011-07-10 01:31 +0100
Windows Posix Support (was Re: C is fixed or not ?) Todd Carnes <toddcarnes@gmail.com> - 2011-07-10 01:06 +0000
Re: C is fixed or not ? Rui Maciel <rui.maciel@gmail.com> - 2011-07-13 01:25 +0100
Re: C is fixed or not ? James Kuyper <jameskuyper@verizon.net> - 2011-07-12 22:50 -0400
Re: C is fixed or not ? lawrence.jones@siemens.com - 2011-07-13 17:27 -0400
Re: C is fixed or not ? "J. J. Farrell" <jjf@bcs.org.uk> - 2011-07-16 03:00 +0100
Re: C is fixed or not ? "MikeP" <mp011011@some.org> - 2011-07-07 22:35 -0500
Re: C is fixed or not ? "christian.bau" <christian.bau@cbau.wanadoo.co.uk> - 2011-07-06 17:24 -0700
Re: C is fixed or not ? James Kuyper <jameskuyper@verizon.net> - 2011-07-07 07:02 -0400
Re: C is fixed or not ? Ian Collins <ian-news@hotmail.com> - 2011-07-06 14:46 +1200
Re: C is fixed or not ? Rui Maciel <rui.maciel@gmail.com> - 2011-07-06 04:04 +0100
Re: C is fixed or not ? Jens Gustedt <Jens.Gustedt@loria.fr> - 2011-07-06 09:25 +0200
Re: C is fixed or not ? "MikeP" <mp011011@some.org> - 2011-07-04 23:20 -0500
Re: C is fixed or not ? jacob navia <jacob@spamsink.net> - 2011-07-05 07:33 +0200
Re: C is fixed or not ? "MikeP" <mp011011@some.org> - 2011-07-07 17:49 -0500
Re: C is fixed or not ? jameskuyper <jameskuyper@gmail.com> - 2011-07-05 14:47 -0700
Re: C is fixed or not ? Rui Maciel <rui.maciel@gmail.com> - 2011-07-06 03:11 +0100
Re: C is fixed or not ? Ian Collins <ian-news@hotmail.com> - 2011-07-06 14:26 +1200
Re: C is fixed or not ? Rui Maciel <rui.maciel@gmail.com> - 2011-07-06 04:00 +0100
Re: C is fixed or not ? Ian Collins <ian-news@hotmail.com> - 2011-07-06 15:22 +1200
Re: C is fixed or not ? Rui Maciel <rui.maciel@gmail.com> - 2011-07-06 14:36 +0100
Re: C is fixed or not ? Ian Collins <ian-news@hotmail.com> - 2011-07-07 07:56 +1200
Re: C is fixed or not ? Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-07-08 02:15 +0300
Re: C is fixed or not ? Ian Collins <ian-news@hotmail.com> - 2011-07-08 15:31 +1200
Re: C is fixed or not ? James Kuyper <jameskuyper@verizon.net> - 2011-07-05 23:29 -0400
Re: C is fixed or not ? Rui Maciel <rui.maciel@gmail.com> - 2011-07-06 14:34 +0100
Re: C is fixed or not ? "MikeP" <mp011011@some.org> - 2011-07-07 22:00 -0500
Re: C is fixed or not ? Rui Maciel <rui.maciel@gmail.com> - 2011-07-08 13:20 +0100
Re: C is fixed or not ? James Kuyper <jameskuyper@verizon.net> - 2011-07-08 10:47 -0400
Re: C is fixed or not ? Shao Miller <sha0.miller@gmail.com> - 2011-07-08 11:07 -0400
Re: C is fixed or not ? "MikeP" <mp011011@some.org> - 2011-07-08 14:56 -0500
Re: C is fixed or not ? Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-07-13 07:50 -0700
Re: C is fixed or not ? "MikeP" <mp011011@some.org> - 2011-07-14 21:00 -0500
Re: C is fixed or not ? Ian Collins <ian-news@hotmail.com> - 2011-07-15 14:29 +1200
Re: C is fixed or not ? "MikeP" <mp011011@some.org> - 2011-07-14 22:58 -0500
Re: C is fixed or not ? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-07-15 11:31 +0100
Re: C is fixed or not ? "MikeP" <mp011011@some.org> - 2011-07-15 21:49 -0500
Re: C is fixed or not ? Ian Collins <ian-news@hotmail.com> - 2011-07-16 15:00 +1200
Re: C is fixed or not ? "MikeP" <mp011011@some.org> - 2011-07-15 23:08 -0500
Re: C is fixed or not ? Ian Collins <ian-news@hotmail.com> - 2011-07-16 16:23 +1200
Re: C is fixed or not ? "MikeP" <mp011011@some.org> - 2011-07-15 23:50 -0500
Re: C is fixed or not ? Ian Collins <ian-news@hotmail.com> - 2011-07-16 17:13 +1200
Re: C is fixed or not ? "MikeP" <mp011011@some.org> - 2011-07-16 00:26 -0500
Re: C is fixed or not ? Dr Nick <3-nospam@temporary-address.org.uk> - 2011-07-16 08:23 +0100
Re: C is fixed or not ? "MikeP" <mp011011@some.org> - 2011-07-16 03:35 -0500
Re: C is fixed or not ? Dr Nick <3-nospam@temporary-address.org.uk> - 2011-07-16 10:17 +0100
Re: C is fixed or not ? Dr Nick <3-nospam@temporary-address.org.uk> - 2011-07-16 10:21 +0100
Re: C is fixed or not ? "MikeP" <mp011011@some.org> - 2011-07-16 04:39 -0500
Re: C is fixed or not ? Dr Nick <3-nospam@temporary-address.org.uk> - 2011-07-16 12:22 +0100
Re: C is fixed or not ? "MikeP" <mp011011@some.org> - 2011-07-16 16:14 -0500
Re: C is fixed or not ? "io_x" <a@b.c.invalid> - 2011-07-17 08:01 +0200
Re: C is fixed or not ? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-07-16 13:48 +0100
Re: C is fixed or not ? "MikeP" <mp011011@some.org> - 2011-07-16 23:56 -0500
Re: C is fixed or not ? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-07-17 13:48 +0100
Re: C is fixed or not ? "MikeP" <mp011011@some.org> - 2011-07-18 06:32 -0500
Re: C is fixed or not ? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-07-19 01:14 +0100
Re: C is fixed or not ? Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-07-15 00:50 -0700
Re: C is fixed or not ? "MikeP" <mp011011@some.org> - 2011-07-15 22:44 -0500
Re: C is fixed or not ? Keith Thompson <kst-u@mib.org> - 2011-07-15 20:58 -0700
Re: C is fixed or not ? "MikeP" <mp011011@some.org> - 2011-07-15 23:09 -0500
Re: C is fixed or not ? Dr Nick <3-nospam@temporary-address.org.uk> - 2011-07-16 08:24 +0100
Re: C is fixed or not ? "MikeP" <mp011011@some.org> - 2011-07-16 03:38 -0500
Re: C is fixed or not ? Dr Nick <3-nospam@temporary-address.org.uk> - 2011-07-16 10:17 +0100
Re: C is fixed or not ? gazelle@shell.xmission.com (Kenny McCormack) - 2011-07-16 11:46 +0000
Re: C is fixed or not ? lawrence.jones@siemens.com - 2011-07-16 14:53 -0400
Re: C is fixed or not ? "MikeP" <mp011011@some.org> - 2011-07-16 23:58 -0500
Re: C is fixed or not ? Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-07-18 02:47 -0700
Re: C is fixed or not ? "MikeP" <mp011011@some.org> - 2011-07-18 06:41 -0500
Re: C is fixed or not ? Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-07-18 02:46 -0700
Re: C is fixed or not ? "MikeP" <mp011011@some.org> - 2011-07-18 06:46 -0500
Re: C is fixed or not ? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-07-15 01:24 -0700
Re: C is fixed or not ? "MikeP" <mp011011@some.org> - 2011-07-07 21:49 -0500
Re: C is fixed or not ? Rui Maciel <rui.maciel@gmail.com> - 2011-07-08 12:47 +0100
Re: C is fixed or not ? "MikeP" <mp011011@some.org> - 2011-07-08 17:44 -0500
Re: C is fixed or not ? Oliver Jackson <chexmofo@hotmail.com> - 2011-07-09 00:46 -0700
Re: C is fixed or not ? jacob navia <jacob@spamsink.net> - 2011-07-06 08:33 +0200
Re: C is fixed or not ? Ian Collins <ian-news@hotmail.com> - 2011-07-06 20:10 +1200
Re: C is fixed or not ? jacob navia <jacob@spamsink.net> - 2011-07-06 14:35 +0200
Re: C is fixed or not ? lawrence.jones@siemens.com - 2011-07-06 11:45 -0400
Re: C is fixed or not ? Rui Maciel <rui.maciel@gmail.com> - 2011-07-06 19:35 +0100
Re: C is fixed or not ? jacob navia <jacob@spamsink.net> - 2011-07-06 21:10 +0200
Re: C is fixed or not ? jacob navia <jacob@spamsink.net> - 2011-07-06 21:44 +0200
Re: C is fixed or not ? Ian Collins <ian-news@hotmail.com> - 2011-07-07 07:58 +1200
Re: C is fixed or not ? Chris H <chris@phaedsys.org> - 2011-07-06 15:59 +0100
Re: C is fixed or not ? jacob navia <jacob@spamsink.net> - 2011-07-06 17:39 +0200
Re: C is fixed or not ? Ian Collins <ian-news@hotmail.com> - 2011-07-07 08:03 +1200
Re: C is fixed or not ? jacob navia <jacob@spamsink.net> - 2011-07-06 17:16 +0200
Re: C is fixed or not ? "MikeP" <mp011011@some.org> - 2011-07-07 21:39 -0500
Re: C is fixed or not ? Rui Maciel <rui.maciel@gmail.com> - 2011-07-08 12:42 +0100
Re: C is fixed or not ? jacob navia <jacob@spamsink.net> - 2011-07-08 15:19 +0200
Re: C is fixed or not ? "MikeP" <mp011011@some.org> - 2011-07-08 17:46 -0500
Re: C is fixed or not ? Tim Rentsch <txr@alumni.caltech.edu> - 2011-07-04 17:35 -0700
Re: C is fixed or not ? Chris H <chris@phaedsys.org> - 2011-07-06 08:26 +0100
Re: C is fixed or not ? Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-07-07 19:52 +0300
Re: C is fixed or not ? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-07-05 08:09 -0700
Re: C is fixed or not ? Noob <root@127.0.0.1> - 2011-07-05 16:04 +0200
Re: C is fixed or not ? "MikeP" <mp011011@some.org> - 2011-07-04 23:07 -0500
Re: C is fixed or not ? "christian.bau" <christian.bau@cbau.wanadoo.co.uk> - 2011-07-06 17:11 -0700
Re: C is fixed or not ? Chris H <chris@phaedsys.org> - 2011-07-07 16:29 +0100
Re: C is fixed or not ? Ian Collins <ian-news@hotmail.com> - 2011-07-08 08:09 +1200
Re: C is fixed or not ? Keith Thompson <kst-u@mib.org> - 2011-07-04 14:35 -0700
Re: C is fixed or not ? "MikeP" <mp011011@some.org> - 2011-07-04 23:01 -0500
Re: C is fixed or not ? Chris H <chris@phaedsys.org> - 2011-07-06 16:07 +0100
Page 8 of 10 — ← Prev page 1 … 6 7 [8] 9 10 Next page →
| From | Dr Nick <3-nospam@temporary-address.org.uk> |
|---|---|
| Date | 2011-07-16 10:21 +0100 |
| Message-ID | <87hb6mr36f.fsf@temporary-address.org.uk> |
| In reply to | #8348 |
Dr Nick <3-nospam@temporary-address.org.uk> writes: > "MikeP" <mp011011@some.org> writes: > >> Dr Nick wrote: >>> "MikeP" <mp011011@some.org> writes: >>> >>>> ... is not a good top-level abstraction. :) >>> >>> It's not bad. I've managed to use it to write perfectly functional C >>> on (at least - I'm almost certainly forgetting some): CP/CMS, MVS, >>> VMS, QDOS, SMS/2, Linux and a custom OS. >>> >>> That's the whole idea of an abstraction. I would not like to have had >>> to learn the underlying OS calls for each of these, cope with the >>> complexities of the file systems, and then written my own code. >>> Particularly when I then had to move programs from one to the other of >>> these. >> >> Yeah, if you like the C API, that works. > > It's nothing to do with "liking" it, and it's not "that works". It's > "that's all there is to it". > >> You could have been using something nicer (assuming you are a good >> library designer) and evolving though if you would have considered C >> just another platform. But then again, if you only have C to work >> with, "nice" doesn't belong in the same dialog. Sorry - some editing errors crept in there. Try this version: > No, I couldn't have "been using something nicer" (whatever that looks > like; any suggestions for a library that is "nicer" and works on all > the above OSs?). > I'd never have managed to write the code in the time available (and > this is nothing to do with bad planning - sometimes there are external > factors that mean that there was no need for some software yesterday > and there is /now/) if I'd had to start on the raw application layer > and build my own "nicer" library. I'm not even sure I had > documentation or appropriate header files for the native interface. > > Some of that code was for myself. Some was for employers, so > migrating the library backwards and forwards would have been > problematical to say the least. > >> Move up a notch to C++ >> though, and you can create almost anything and with some elegance >> too. (Preaching to the choir, surely). > > So in one breath you are suggesting I cut out a huge chunk of the power > of C, and in the other you're suggesting I move to something much more > powerful. Most odd if you don't mind me saying so. -- Online waterways route planner | http://canalplan.eu Plan trips, see photos, check facilities | http://canalplan.org.uk
[toc] | [prev] | [next] | [standalone]
| From | "MikeP" <mp011011@some.org> |
|---|---|
| Date | 2011-07-16 04:39 -0500 |
| Message-ID | <ivrmca$n7a$1@dont-email.me> |
| In reply to | #8348 |
Dr Nick wrote: > "MikeP" <mp011011@some.org> writes: > >> Dr Nick wrote: >>> "MikeP" <mp011011@some.org> writes: >>> >>>> ... is not a good top-level abstraction. :) >>> >>> It's not bad. I've managed to use it to write perfectly functional >>> C on (at least - I'm almost certainly forgetting some): CP/CMS, MVS, >>> VMS, QDOS, SMS/2, Linux and a custom OS. >>> >>> That's the whole idea of an abstraction. I would not like to have >>> had to learn the underlying OS calls for each of these, cope with >>> the complexities of the file systems, and then written my own code. >>> Particularly when I then had to move programs from one to the other >>> of these. >> >> Yeah, if you like the C API, that works. > > It's nothing to do with "liking" it, and it's not "that works". It's > "that's all there is to it". Yeah, if "all you have is a hammer..". > >> You could have been using something nicer (assuming you are a good >> library designer) and evolving though if you would have considered C >> just another platform. But then again, if you only have C to work >> with, "nice" doesn't belong in the same dialog. > > No, I couldn't have "been using something nicer" (whatever that looks > like - any suggestions for a library that is "nicer" and works on all > the above OSs". I'd never have managed to write the code in the time > available > (and this is nothing to do with bad planning - sometimes > there are external factors that mean that there was no need for some > software yesterday and there is /now/) if I'd had to start on the raw > application layer and build my own "nicer" library. I'm not even > sure I had documentation or appropriate header files for the native > interface. > It would have gotten easier at every iteration though. And remember, the "C API" is a target for the higher-level API also, so it could have been used incrementally and evolved until it subsumed the "C API". > Some of that, as implied, was for myself. Some was for employers, so > migrating the library backwards and forwards would have been > problematical to say the least. > >> Move up a notch to C++ >> though, and you can create almost anything and with some elegance >> too. (Preaching to the choir, surely). > > So in one breath you are suggesting I cut out a huge chunk of the > power of C, and in the other you're suggesting I move to something > much more powerful. Most odd if you don't mind me saying so. I'm not making any suggestions to you. I was just thinking out loud. I don't care much how other people do things though I am curious about why sometimes.
[toc] | [prev] | [next] | [standalone]
| From | Dr Nick <3-nospam@temporary-address.org.uk> |
|---|---|
| Date | 2011-07-16 12:22 +0100 |
| Message-ID | <878vryqxll.fsf@temporary-address.org.uk> |
| In reply to | #8354 |
"MikeP" <mp011011@some.org> writes:
> Dr Nick wrote:
>> "MikeP" <mp011011@some.org> writes:
>>
>>> Dr Nick wrote:
>>>> "MikeP" <mp011011@some.org> writes:
>>>>
>>>>> ... is not a good top-level abstraction. :)
>>>>
>>>> It's not bad. I've managed to use it to write perfectly functional
>>>> C on (at least - I'm almost certainly forgetting some): CP/CMS, MVS,
>>>> VMS, QDOS, SMS/2, Linux and a custom OS.
>>>>
>>>> That's the whole idea of an abstraction. I would not like to have
>>>> had to learn the underlying OS calls for each of these, cope with
>>>> the complexities of the file systems, and then written my own code.
>>>> Particularly when I then had to move programs from one to the other
>>>> of these.
>>>
>>> Yeah, if you like the C API, that works.
>>
>> It's nothing to do with "liking" it, and it's not "that works". It's
>> "that's all there is to it".
>
> Yeah, if "all you have is a hammer..".
It's not that at all. In this case it's "I've got a hammer, and I have
a nail to hammer in - the horse is waiting outside. I'm not going to
fire up the blast furnace and start refining some iron ore to forge a
new hammer from".
>>> You could have been using something nicer (assuming you are a good
>>> library designer) and evolving though if you would have considered C
>>> just another platform. But then again, if you only have C to work
>>> with, "nice" doesn't belong in the same dialog.
>>
>> No, I couldn't have "been using something nicer" (whatever that looks
>> like - any suggestions for a library that is "nicer" and works on all
>> the above OSs". I'd never have managed to write the code in the time
>> available
>> (and this is nothing to do with bad planning - sometimes
>> there are external factors that mean that there was no need for some
>> software yesterday and there is /now/) if I'd had to start on the raw
>> application layer and build my own "nicer" library. I'm not even
>> sure I had documentation or appropriate header files for the native
>> interface.
>
> It would have gotten easier at every iteration though. And remember, the
> "C API" is a target for the higher-level API also, so it could have been
> used incrementally and evolved until it subsumed the "C API".
First time you've told me that this is a layer on top of stdio. Up to
now you've been saying "replace". Now you're layering on top. That's
another thing entirely and, from my source repository I give you:
struct filepointer {
enum file_type type;
enum file_mode mode;
enum file_method method;
union {
FILE *fp; // it might be a stream (types text, format, program)
socket_handle sock; // or a socket (socket)
struct plotter *plotp; // or a plotter channel (plotter)
database *dbp; // or a database (database)
struct sql_database *sqlp; // perhaps an SQL one
struct variable_stream *var; // or a variable (variable)
} u;
struct filepointer *incfile; // files can nest
};
I won't include all the others here, but I'll note that sql_database is
in turn a union of mysql and sqlite types. Database is the old db3
type.
Note that I *haven't* got the underlying Unix file in there, it's still
FILE.
If it's not going to do this, it's not going to get any easier in
detail. I haven't a clue what the interface to PDS on MVS looks like
but it's going to be pretty messy. I strongly suspect I'd end up
parsing strings for dots and brackets for a start.
>> Some of that, as implied, was for myself. Some was for employers, so
>> migrating the library backwards and forwards would have been
>> problematical to say the least.
>>
>>> Move up a notch to C++
>>> though, and you can create almost anything and with some elegance
>>> too. (Preaching to the choir, surely).
>>
>> So in one breath you are suggesting I cut out a huge chunk of the
>> power of C, and in the other you're suggesting I move to something
>> much more powerful. Most odd if you don't mind me saying so.
>
> I'm not making any suggestions to you. I was just thinking out loud. I
> don't care much how other people do things though I am curious about why
> sometimes.
OK. Please think out loud to tell us what you would put in a library
that would handle files, in C, that interfaces with operating systems
with traditional directories, with PDS, with version numbering and with
flat file systems, that is sufficiently "nicer" than the existing C
library that the time spent working on it rather than on something else
would repay the effort.
--
Online waterways route planner | http://canalplan.eu
Plan trips, see photos, check facilities | http://canalplan.org.uk
[toc] | [prev] | [next] | [standalone]
| From | "MikeP" <mp011011@some.org> |
|---|---|
| Date | 2011-07-16 16:14 -0500 |
| Message-ID | <ivsuup$4k6$1@dont-email.me> |
| In reply to | #8355 |
Dr Nick wrote: > "MikeP" <mp011011@some.org> writes: > >> Dr Nick wrote: >>> "MikeP" <mp011011@some.org> writes: >>> >>>> Dr Nick wrote: >>>>> "MikeP" <mp011011@some.org> writes: >>>>> >>>>>> ... is not a good top-level abstraction. :) >>>>> >>>>> It's not bad. I've managed to use it to write perfectly >>>>> functional C on (at least - I'm almost certainly forgetting >>>>> some): CP/CMS, MVS, VMS, QDOS, SMS/2, Linux and a custom OS. >>>>> >>>>> That's the whole idea of an abstraction. I would not like to have >>>>> had to learn the underlying OS calls for each of these, cope with >>>>> the complexities of the file systems, and then written my own >>>>> code. Particularly when I then had to move programs from one to >>>>> the other of these. >>>> >>>> Yeah, if you like the C API, that works. >>> >>> It's nothing to do with "liking" it, and it's not "that works". >>> It's "that's all there is to it". >> >> Yeah, if "all you have is a hammer..". > > It's not that at all. In this case it's "I've got a hammer, and I > have > a nail to hammer in - the horse is waiting outside. I'm not going to > fire up the blast furnace and start refining some iron ore to forge a > new hammer from". > Funny thing, metaphor-wars are, huh. >>>> You could have been using something nicer (assuming you are a good >>>> library designer) and evolving though if you would have considered >>>> C just another platform. But then again, if you only have C to work >>>> with, "nice" doesn't belong in the same dialog. >>> >>> No, I couldn't have "been using something nicer" (whatever that >>> looks like - any suggestions for a library that is "nicer" and >>> works on all the above OSs". I'd never have managed to write the >>> code in the time available >>> (and this is nothing to do with bad planning - sometimes >>> there are external factors that mean that there was no need for some >>> software yesterday and there is /now/) if I'd had to start on the >>> raw application layer and build my own "nicer" library. I'm not >>> even sure I had documentation or appropriate header files for the >>> native interface. >> >> It would have gotten easier at every iteration though. And remember, >> the "C API" is a target for the higher-level API also, so it could >> have been used incrementally and evolved until it subsumed the "C >> API". > > First time you've told me that this is a layer on top of stdio. It's "neither here nor there". I threw it out there as an option. I may develop my library to stand beside the ISO library and you may develop yours to sit on top of it. There is no one best way to do it all the time. Way too much emphasis by programmers is put on, "well, someday I may want to deploy on... therefore, THE standard library is the best choice". There's usually enough stuff to worry about without bringing in POTENTIAL stuff to worry about. > Up to > now you've been saying "replace". I don't think so. Surely I've been saying "in alternative to". > Now you're layering on top. Nope. YOU may have wanted to though, but I'm not sure that doing so wouldn't have compromised the design. I may want to target, e.g., 2 platforms, Windows and Unix, and create a framework that talks to those platforms' system-level APIs and ignore ISO std lib entirely. >>> Some of that, as implied, was for myself. Some was for employers, >>> so migrating the library backwards and forwards would have been >>> problematical to say the least. >>> >>>> Move up a notch to C++ >>>> though, and you can create almost anything and with some elegance >>>> too. (Preaching to the choir, surely). >>> >>> So in one breath you are suggesting I cut out a huge chunk of the >>> power of C, and in the other you're suggesting I move to something >>> much more powerful. Most odd if you don't mind me saying so. >> >> I'm not making any suggestions to you. I was just thinking out loud. >> I don't care much how other people do things though I am curious >> about why sometimes. > > OK. Please think out loud to tell us what you would put in a library > that would handle files, in C, that interfaces with operating systems > with traditional directories, with PDS, with version numbering and > with > flat file systems, that is sufficiently "nicer" than the existing C > library that the time spent working on it rather than on something > else > would repay the effort. That is but one set of requirements, surely contrived to "show" that the ISO standard library is "best". Some do argue that the ISO standard library, is best everywhere and all of the time, when that is, of course, either naivete or BS.
[toc] | [prev] | [next] | [standalone]
| From | "io_x" <a@b.c.invalid> |
|---|---|
| Date | 2011-07-17 08:01 +0200 |
| Message-ID | <4e227a62$0$15664$4fafbaef@reader2.news.tin.it> |
| In reply to | #8355 |
"Dr Nick" <3-nospam@temporary-address.org.uk> ha scritto nel messaggio
news:878vryqxll.fsf@temporary-address.org.uk...
> "MikeP" <mp011011@some.org> writes:
> struct filepointer {
> enum file_type type;
> enum file_mode mode;
> enum file_method method;
> union {
> FILE *fp; // it might be a stream (types text, format,
> program)
> socket_handle sock; // or a socket (socket)
> struct plotter *plotp; // or a plotter channel (plotter)
> database *dbp; // or a database (database)
> struct sql_database *sqlp; // perhaps an SQL one
> struct variable_stream *var; // or a variable (variable)
> } u;
> struct filepointer *incfile; // files can nest
> };
it could be as
FILE *fp;
and could be ok for all files,
sockets, all and all can be input output
there are places where to criticize,
but FILE* fgetc() fputc() fread() fopen() etc
buffered way [as K&R2 show code], are not the ones;
they could be ok in all kind of io;
at last i (no one) think so
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2011-07-16 13:48 +0100 |
| Message-ID | <0.46e4f17f058dc65215e1.20110716134825BST.877h7ifl2e.fsf@bsb.me.uk> |
| In reply to | #8333 |
"MikeP" <mp011011@some.org> writes: > Ben Bacarisse wrote: >> "MikeP" <mp011011@some.org> writes: >> >>> Ian Collins wrote: >>>> On 07/15/11 02:00 PM, MikeP wrote: >>>>> >>>>> (Aside: The C std library is, of course, the Unix API >>>> >>>> No, it isn't. >>> >>> Well it started out being that >> >> I don't think so. Had you said "is influenced by" or "was developed >> to work closely with" or some such phrase I doubt there would be much >> objection, but "is" on its own suggests they are the same (or >> substantially the same) and they're not. The only part of the Unix >> API (the system call interface) that I can spot that went into the C >> standard library was signal(2). That's a tiny part of the library. > > E.g. (what I was getting at): Unix has 'fopen', Windows has > 'CreateFile'. That may be an example of what you are getting at, but it is not an example of what you said. If I counter with the true by unhelpful statement that "Windows has fopen and Unix has open and creat" you (presumably) will be able to refute the conclusion that fopen is part of the Windows API. Swap that argument around and I believe you'll have a valid refutation of your claim about the "Unix API". (I have to use quotes because it's a bit vague and it may be in that vagueness that the confusion lies. To me, the "Unix API" is the system call interface -- the one thing that all programs will eventually have to use to access and manipulate system resources.) >> Your argument is, presumably, that tighter system integration is more >> important than portability. > > Not really (not that I don't or do agree with that). Standard libraries > of programming languages notoriously suck. One is faced with that "holy > portability" (and "performance trumps elegance") thing even when one need > not be. That's fine if you need it, but if you don't, you don't. Not that > platform-provided libraries are a panacea, but that I'd rather build > something on top of that than on top of language-provided libraries > because I feel that language-provided libraries are not adequate as the > top-level of abstraction and if I have to build something on top of > something anyway, I prefer to build on top of the platform API. YMMV: I'm > not trying to persuade anyone to use my methods. Does your interface/library/whatever not suck then? If you think it is better than what programming languages currently do with their standard libraries, the world needs to see it! If it is only better for one or two programs (because it's tailored) and you re-write it for others, then I think there is a valid technical objection to your methods: by not abstracting you are wasting effort. I acknowledge that there is another possibility. What you build on top of the native OS might be a higher-level abstraction but so system specific that there is no benefit to publishing it. That's possible but I am having trouble imaging how that could be. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | "MikeP" <mp011011@some.org> |
|---|---|
| Date | 2011-07-16 23:56 -0500 |
| Message-ID | <ivtq1n$gt8$1@dont-email.me> |
| In reply to | #8357 |
Ben Bacarisse wrote:
> "MikeP" <mp011011@some.org> writes:
>
>> Ben Bacarisse wrote:
>>> "MikeP" <mp011011@some.org> writes:
>>>
>>>> Ian Collins wrote:
>>>>> On 07/15/11 02:00 PM, MikeP wrote:
>>>>>>
>>>>>> (Aside: The C std library is, of course, the Unix API
>>>>>
>>>>> No, it isn't.
>>>>
>>>> Well it started out being that
>>>
>>> I don't think so. Had you said "is influenced by" or "was developed
>>> to work closely with" or some such phrase I doubt there would be
>>> much objection, but "is" on its own suggests they are the same (or
>>> substantially the same) and they're not. The only part of the Unix
>>> API (the system call interface) that I can spot that went into the C
>>> standard library was signal(2). That's a tiny part of the library.
>>
>> E.g. (what I was getting at): Unix has 'fopen', Windows has
>> 'CreateFile'.
>
> That may be an example of what you are getting at, but it is not an
> example of what you said.
Language is paltry for communication on the quick. Text even moreso. But
you will soon enough get my drift after a few posts. The logic is
consistent. I did know before I posted that there was something below
fopen on Unix but was too lazy to look it up. I wasn't diligent in
presenting my position. Of course I'm sure there are a few (if not more)
that just lurk here for the "opportunity" to render someone a total waste
of life the second that someone appears to be less than a total bit head.
> If I counter
I wasn't debating though, really. I know y'all do that ("my language is
better than your language... I'm a better programmer than you are.. na
na!"), but I'm not part of any group that that does that.
> with the true by unhelpful
> statement that "Windows has fopen and Unix has open and creat" you
> (presumably) will be able to refute the conclusion that fopen is part
> of the Windows API. Swap that argument
What "argument"? I'm not arguing. Are you? What about?
> around and I believe you'll
> have a valid refutation of your claim about the "Unix API".
Oh, THAT one (NOW I remember where this started! I could've had a V8!).
To ME, then maybe, it is the Unix API. Does the std lib not like its
lineage? Hmm. You know that my feel for it is correct, admit it. Do you
think I'm "knocking it" and is it dear to you and you feel the need to
defend it?
> (I have
> to use quotes because it's a bit vague and it may be in that
> vagueness that the confusion lies. To me, the "Unix API" is the
> system call interface
Surely that is the "correct" technical answer, but there is more to
things than just "correct technical answers". Ya think?
> -- the one thing that all programs will
> eventually have to use to access and manipulate system resources.)
>
>>> Your argument is, presumably, that tighter system integration is
>>> more important than portability.
>>
>> Not really (not that I don't or do agree with that). Standard
>> libraries of programming languages notoriously suck. One is faced
>> with that "holy portability" (and "performance trumps elegance")
>> thing even when one need not be. That's fine if you need it, but if
>> you don't, you don't. Not that platform-provided libraries are a
>> panacea, but that I'd rather build something on top of that than on
>> top of language-provided libraries because I feel that
>> language-provided libraries are not adequate as the top-level of
>> abstraction and if I have to build something on top of something
>> anyway, I prefer to build on top of the platform API. YMMV: I'm not
>> trying to persuade anyone to use my methods.
>
> Does your interface/library/whatever not suck then?
Why would I make a sucky one?
> If you think it
> is better than what programming languages currently do with their
> standard libraries, the world needs to see it!
Well it's quite a leap from "one man show library" to "mass consumption".
(And I'm not saying whether I'm doing that or have done that or will be
doing that, but just to respond to your very valid inquiry).
> If it is only better
> for one or two programs (because it's tailored) and you re-write it
> for others, then I think there is a valid technical objection to your
> methods: by not abstracting you are wasting effort.
See, there is no "enlightening" you guys! :P You keep doing it like you
always have and everyone before you has and someone somewhere in the
world WONDERS why there is no progress or why it is sooooo slooooow in
coming.
>
> I acknowledge that there is another possibility.
Just one?
> What you build on
> top of the native OS might be a higher-level abstraction but so system
> specific that there is no benefit to publishing it.
That's not true, of course, even if it is just one system. Actually, it's
probably a good scenario for doing such (have you looked at the .Net file
API lately? It's horrendous!).
> That's possible
> but I am having trouble imaging how that could be.
>
Look at the .Net file API and please give me your critique of it. I'd be
very interested in knowing that, but not here, because if MS wants
consulting, they should have to PAY for it! (My email available upon
request).
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2011-07-17 13:48 +0100 |
| Message-ID | <0.151e5dc75e5d734d012e.20110717134852BST.87tyaldqdn.fsf@bsb.me.uk> |
| In reply to | #8371 |
"MikeP" <mp011011@some.org> writes:
> Ben Bacarisse wrote:
>> "MikeP" <mp011011@some.org> writes:
>>
>>> Ben Bacarisse wrote:
>>>> "MikeP" <mp011011@some.org> writes:
>>>>
>>>>> Ian Collins wrote:
>>>>>> On 07/15/11 02:00 PM, MikeP wrote:
>>>>>>>
>>>>>>> (Aside: The C std library is, of course, the Unix API
>>>>>>
>>>>>> No, it isn't.
>>>>>
>>>>> Well it started out being that
>>>>
>>>> I don't think so. Had you said "is influenced by" or "was developed
>>>> to work closely with" or some such phrase I doubt there would be
>>>> much objection, but "is" on its own suggests they are the same (or
>>>> substantially the same) and they're not. The only part of the Unix
>>>> API (the system call interface) that I can spot that went into the C
>>>> standard library was signal(2). That's a tiny part of the library.
>>>
>>> E.g. (what I was getting at): Unix has 'fopen', Windows has
>>> 'CreateFile'.
>>
>> That may be an example of what you are getting at, but it is not an
>> example of what you said.
>
> Language is paltry for communication on the quick. Text even moreso.
Then take your time. If you don't have time to express what you want to
say, you could prefix your post with something like "Don't spend much of
your time trying to understand this -- I spent very time writing it".
> But
> you will soon enough get my drift after a few posts. The logic is
> consistent. I did know before I posted that there was something below
> fopen on Unix but was too lazy to look it up. I wasn't diligent in
> presenting my position. Of course I'm sure there are a few (if not more)
> that just lurk here for the "opportunity" to render someone a total waste
> of life the second that someone appears to be less than a total bit
> head.
But after all these posts I still don't know what your drift is.
>> If I counter
>
> I wasn't debating though, really. I know y'all do that ("my language is
> better than your language... I'm a better programmer than you are.. na
> na!"), but I'm not part of any group that that does that.
Call it what you like, but if you try to express an opinion in a public
forum other people may well express different options or they may offer
opinions about your options. You don't have to think of that as a
debate if you don't like the term, but that's what's happening here.
>> with the true by unhelpful
>> statement that "Windows has fopen and Unix has open and creat" you
>> (presumably) will be able to refute the conclusion that fopen is part
>> of the Windows API. Swap that argument
>
> What "argument"? I'm not arguing. Are you? What about?
Yes, I am. I am arguing about whether the "C std library is [...] the
Unix API". Feel free not to express any more opinions on the matter,
but if you do I will probably conclude that we are having a "debate"
about it even if you don't ever do that.
>> around and I believe you'll
>> have a valid refutation of your claim about the "Unix API".
>
> Oh, THAT one (NOW I remember where this started! I could've had a V8!).
> To ME, then maybe, it is the Unix API. Does the std lib not like its
> lineage? Hmm. You know that my feel for it is correct, admit it. Do you
> think I'm "knocking it" and is it dear to you and you feel the need to
> defend it?
No. I wanted to correct a detail. I was also interesting in what you
would do instead since you dismissed the whole idea of language
libraries. I really would like to know what should be done instead.
>> (I have
>> to use quotes because it's a bit vague and it may be in that
>> vagueness that the confusion lies. To me, the "Unix API" is the
>> system call interface
>
> Surely that is the "correct" technical answer, but there is more to
> things than just "correct technical answers". Ya think?
Yes, a lot more. But do you object to correct technical answers? I
think there are a good place to start in technical news groups.
>> -- the one thing that all programs will
>> eventually have to use to access and manipulate system resources.)
>>
>>>> Your argument is, presumably, that tighter system integration is
>>>> more important than portability.
>>>
>>> Not really (not that I don't or do agree with that). Standard
>>> libraries of programming languages notoriously suck. One is faced
>>> with that "holy portability" (and "performance trumps elegance")
>>> thing even when one need not be. That's fine if you need it, but if
>>> you don't, you don't. Not that platform-provided libraries are a
>>> panacea, but that I'd rather build something on top of that than on
>>> top of language-provided libraries because I feel that
>>> language-provided libraries are not adequate as the top-level of
>>> abstraction and if I have to build something on top of something
>>> anyway, I prefer to build on top of the platform API. YMMV: I'm not
>>> trying to persuade anyone to use my methods.
>>
>> Does your interface/library/whatever not suck then?
>
> Why would I make a sucky one?
>
>> If you think it
>> is better than what programming languages currently do with their
>> standard libraries, the world needs to see it!
>
> Well it's quite a leap from "one man show library" to "mass consumption".
> (And I'm not saying whether I'm doing that or have done that or will be
> doing that, but just to respond to your very valid inquiry).
So "standard libraries [...] suck" (which must include C's) and by
implication from the answer before this one yours does (in your option)
not suck. Is it not selfish not share at least the API? Even if you
plan to keep it proprietary, getting the interface out there can only
help.
For one thing it would do away with all the hypothetical questions that
I posed ("if it's this... if it's that...") which I've now snipped.
We'd see what it is and not have to speculate. For another thing, I'd
probably get your drift at last -- I'd see if you favour system
specifics over portability, or convenience over efficiency and so on.
May request is not some sarcastic "show us so we can mock" request. The
C library is so full of historical curiosities and idiosyncratic choices
that I can easily image that you have something better -- I've just been
too lazy to try to bring it all together into something new.
<snip>
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | "MikeP" <mp011011@some.org> |
|---|---|
| Date | 2011-07-18 06:32 -0500 |
| Message-ID | <j015js$2ee$1@dont-email.me> |
| In reply to | #8381 |
Ben Bacarisse wrote:
> "MikeP" <mp011011@some.org> writes:
>
>> Ben Bacarisse wrote:
>>> "MikeP" <mp011011@some.org> writes:
>>>
>>>> Ben Bacarisse wrote:
>>>>> "MikeP" <mp011011@some.org> writes:
>>>>>
>>>>>> Ian Collins wrote:
>>>>>>> On 07/15/11 02:00 PM, MikeP wrote:
>>>>>>>>
>>>>>>>> (Aside: The C std library is, of course, the Unix API
>>>>>>>
>>>>>>> No, it isn't.
>>>>>>
>>>>>> Well it started out being that
>>>>>
>>>>> I don't think so. Had you said "is influenced by" or "was
>>>>> developed to work closely with" or some such phrase I doubt there
>>>>> would be much objection, but "is" on its own suggests they are
>>>>> the same (or substantially the same) and they're not. The only
>>>>> part of the Unix API (the system call interface) that I can spot
>>>>> that went into the C standard library was signal(2). That's a
>>>>> tiny part of the library.
>>>>
>>>> E.g. (what I was getting at): Unix has 'fopen', Windows has
>>>> 'CreateFile'.
>>>
>>> That may be an example of what you are getting at, but it is not an
>>> example of what you said.
>>
>> Language is paltry for communication on the quick. Text even moreso.
>
> Then take your time. If you don't have time to express what you want
> to say, you could prefix your post with something like "Don't spend
> much of your time trying to understand this -- I spent very time
> writing it".
Or maybe you should get the fuck out of my face?
>
>> But
>> you will soon enough get my drift after a few posts. The logic is
>> consistent. I did know before I posted that there was something below
>> fopen on Unix but was too lazy to look it up. I wasn't diligent in
>> presenting my position. Of course I'm sure there are a few (if not
>> more) that just lurk here for the "opportunity" to render someone a
>> total waste of life the second that someone appears to be less than
>> a total bit head.
>
> But after all these posts I still don't know what your drift is.
Maybe I don't have one of those. Maybe I'm "a troll". Or maybe just a
good one. Who's to say
<
>
>>> If I counter
>>
>> I wasn't debating though, really. I know y'all do that ("my language
>> is better than your language... I'm a better programmer than you
>> are.. na na!"), but I'm not part of any group that that does that.
>
> Call it what you like, but if you try to express an opinion in a
> public forum other people may well express different options or they
> may offer opinions about your options. You don't have to think of
> that as a debate if you don't like the term, but that's what's
> happening here.
But I wasn't doing that. I'm not you. I don't do that.[do I]
>
>>> with the true by unhelpful
>>> statement that "Windows has fopen and Unix has open and creat" you
>>> (presumably) will be able to refute the conclusion that fopen is
>>> part of the Windows API. Swap that argument
>>
>> What "argument"? I'm not arguing. Are you? What about?
>
> Yes, I am. I am arguing about whether the "C std library is [...] the
> Unix API".
That is not an argument to me. I am not arguing. Shut up, I know what
Unix is.Are you testing me
> Feel free
Now you're talkin. The keyword is 'feel'. Huh.
> not to express any more opinions on the matter,
> but if you do I will probably conclude that we are having a "debate"
> about it even if you don't ever do that.
>
What matter
>>> around and I believe you'll
>>> have a valid refutation of your claim about the "Unix API".
>>
>> Oh, THAT one (NOW I remember where this started! I could've had a
>> V8!). To ME, then maybe, it is the Unix API. Does the std lib not
>> like its lineage? Hmm. You know that my feel for it is correct,
>> admit it. Do you think I'm "knocking it" and is it dear to you and
>> you feel the need to defend it?
>
> No. I wanted to correct a detail. I was also interesting in what you
> would do instead since you dismissed the whole idea of language
> libraries. I really would like to know what should be done instead.
>
I probably did do that. It was not intentional. I fucked up, surely.
>>> (I have
>>> to use quotes because it's a bit vague and it may be in that
>>> vagueness that the confusion lies. To me, the "Unix API" is the
>>> system call interface
>>
>> Surely that is the "correct" technical answer, but there is more to
>> things than just "correct technical answers". Ya think?
>
> Yes, a lot more.
You don't know that though.
> But do you object to correct technical answers?
You posed an oxymoron. There is no question there.
> I
> think there are a good place to start in technical news groups.
>
I dunno. You said "get your feet wet in ".. stepped in what
>>> -- the one thing that all programs will
>>> eventually have to use to access and manipulate system resources.)
>>>
>>>>> Your argument is, presumably, that tighter system integration is
>>>>> more important than portability.
>>>>
>>>> Not really (not that I don't or do agree with that). Standard
>>>> libraries of programming languages notoriously suck. One is faced
>>>> with that "holy portability" (and "performance trumps elegance")
>>>> thing even when one need not be. That's fine if you need it, but if
>>>> you don't, you don't. Not that platform-provided libraries are a
>>>> panacea, but that I'd rather build something on top of that than on
>>>> top of language-provided libraries because I feel that
>>>> language-provided libraries are not adequate as the top-level of
>>>> abstraction and if I have to build something on top of something
>>>> anyway, I prefer to build on top of the platform API. YMMV: I'm not
>>>> trying to persuade anyone to use my methods.
>>>
>>> Does your interface/library/whatever not suck then?
>>
>> Why would I make a sucky one?
>>
>>> If you think it
>>> is better than what programming languages currently do with their
>>> standard libraries, the world needs to see it!
>>
>> Well it's quite a leap from "one man show library" to "mass
>> consumption". (And I'm not saying whether I'm doing that or have
>> done that or will be doing that, but just to respond to your very
>> valid inquiry).
>
> So "standard libraries [...] suck" (which must include C's)
Well it is the epitome of suckiness of course.
> and by
> implication from the answer before this one yours does (in your
> option) not suck. Is it not selfish not share at least the API?
> Even if you plan to keep it proprietary, getting the interface out
> there can only help.
>
I don't think it has worked for you. It hasn't worked for me. Why
wouldn't I curse it
> For one thing it would do away with all the hypothetical questions
> that I posed ("if it's this... if it's that...")
I did not recognize any hypotheticality in you post, and I quite liked
it.
> which I've now
> snipped. We'd see what it is and not have to speculate.
Well, see, that is not speculative at all. It is hopeful. Did I misread
that
[question marks and parens don't work on this computer.. fill in the
blanks]
>For another
> thing, I'd probably get your drift at last -- I'd see if you favour
> system specifics over portability, or convenience over efficiency and
> so on.
Not necessarily.
>
> May request is not some sarcastic "show us so we can mock" request.
> The C library is so full of historical curiosities and idiosyncratic
> choices that I can easily image that you have something better --
Another keen observation. In a lot of my posts I have to Tango.
> I've just been too lazy to try to bring it all together into
> something new.
>
Is that the rub
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2011-07-19 01:14 +0100 |
| Message-ID | <0.2687393c066f0ae33981.20110719011417BST.8739i3cejq.fsf@bsb.me.uk> |
| In reply to | #8421 |
"MikeP" <mp011011@some.org> writes: <snip> > Or maybe you should get the fuck out of my face? Happy to oblige. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Nick Keighley <nick_keighley_nospam@hotmail.com> |
|---|---|
| Date | 2011-07-15 00:50 -0700 |
| Message-ID | <cd60d3d3-bec6-4964-aaba-9de6ade6fb3e@q15g2000yqk.googlegroups.com> |
| In reply to | #8289 |
On Jul 15, 3:00 am, "MikeP" <mp011...@some.org> wrote: > Nick Keighley wrote: > > On Jul 8, 4:00 am, "MikeP" <mp011...@some.org> wrote: > >> James Kuyper wrote: <snip> > >> Let's see.. the POSIX/Unix crowd has their threading API already and > >> the Windows crowd has theirs, and you are making the assumption that > >> something that works on both platforms is going to be liked/used by > >> either of those groups, even knowing that the approaches are > >> different? What are the chances! > > > some people write portable code. i find it vaguely irritating that > > unix and windows have gratuitious incompatibilities in, say, sockets. > > If I could do the thready part of the program in some standard API and > > have it Just Work then I'd feel a strong compulsion to use that API. I > > could alos avoid learning two presumably subtly different thread > > approaches. Seems a win win to me. > > Well that's the THEORY behind programming language standard libraries, there is nothing as practical as a good theory. A theory isn't a half assed idea someone dreamed up in the shower. Standard cross platform libraries are incredibly useful. > anyway. All it really is though, is yet another wrench in the machine. > Better to program to the specific platform than some concoction that is > half-way here and half-way there, IMO. and I beg to differ. *Some* things are goign to be platform specific but huge chunks of many applications are plaform agnostic. > The "portable code" mantra is more > trouble than it is worth (again, IMO. Been there, done that). so have I, and the conclusions we've drawn seem to differ > I think > languages should strive to enable library development, but I don't think > they should specify any libraries at all, as that is for ancillaries > (groups, companies) to do. Standard libraries hinder progress rather than > advance the state of the art. the Python people would disagree (plus pretty much any other language designed in the last 20 years) > IMO. :) > > (Aside: The C std library is, of course, the Unix API, so why someone > would want to use it on Windows escapes me. One could further on that > track by asking why anyone would want to use C (the Unix PL) on > Windows!). what do you thing Windows was programmed in? Take a look at the Win32 API. It's C. > >> Should the C standard library recognize threads? Yes. Should it > >> provide a whole API? Questionable.
[toc] | [prev] | [next] | [standalone]
| From | "MikeP" <mp011011@some.org> |
|---|---|
| Date | 2011-07-15 22:44 -0500 |
| Message-ID | <ivr1fa$s92$1@dont-email.me> |
| In reply to | #8300 |
Nick Keighley wrote: > On Jul 15, 3:00 am, "MikeP" <mp011...@some.org> wrote: >> Nick Keighley wrote: >>> On Jul 8, 4:00 am, "MikeP" <mp011...@some.org> wrote: >>>> James Kuyper wrote: > > <snip> > >>>> Let's see.. the POSIX/Unix crowd has their threading API already >>>> and the Windows crowd has theirs, and you are making the >>>> assumption that something that works on both platforms is going to >>>> be liked/used by either of those groups, even knowing that the >>>> approaches are different? What are the chances! >> >>> some people write portable code. i find it vaguely irritating that >>> unix and windows have gratuitious incompatibilities in, say, >>> sockets. If I could do the thready part of the program in some >>> standard API and have it Just Work then I'd feel a strong >>> compulsion to use that API. I could alos avoid learning two >>> presumably subtly different thread approaches. Seems a win win to >>> me. >> >> Well that's the THEORY behind programming language standard >> libraries, > > there is nothing as practical as a good theory. LOL. You surely meant to say: there's nothing practical about theory! > A theory isn't a half > assed idea someone dreamed up in the shower. > > Standard cross platform libraries are incredibly useful. To some of the people, some of the time. > >> anyway. All it really is though, is yet another wrench in the >> machine. Better to program to the specific platform than some >> concoction that is half-way here and half-way there, IMO. > > and I beg to differ. > *Some* things are goign to be platform specific > but huge chunks of many applications are plaform agnostic. > > >> The "portable code" mantra is more >> trouble than it is worth (again, IMO. Been there, done that). > > so have I, and the conclusions we've drawn seem to differ > I'm not much of a follower, so people and me usually differ. No problemo. > >> I think >> languages should strive to enable library development, but I don't >> think they should specify any libraries at all, as that is for >> ancillaries (groups, companies) to do. Standard libraries hinder >> progress rather than advance the state of the art. > > the Python people would disagree (plus pretty much any other language > designed in the last 20 years) > 20 years wasted, why waste 20 more? ;) > >> IMO. :) >> >> (Aside: The C std library is, of course, the Unix API, so why someone >> would want to use it on Windows escapes me. One could further on that >> track by asking why anyone would want to use C (the Unix PL) on >> Windows!). > > what do you thing Windows was programmed in? Take a look at the Win32 > API. It's C. That was a loooong time ago. It's changing. It doesn't take much imagination to see the trends.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2011-07-15 20:58 -0700 |
| Message-ID | <lntyamoozv.fsf@nuthaus.mib.org> |
| In reply to | #8335 |
"MikeP" <mp011011@some.org> writes:
> Nick Keighley wrote:
>> On Jul 15, 3:00 am, "MikeP" <mp011...@some.org> wrote:
[...]
>>> Well that's the THEORY behind programming language standard
>>> libraries,
>>
>> there is nothing as practical as a good theory.
>
> LOL. You surely meant to say: there's nothing practical about theory!
Right, because if anyone states an opinion contrary to yours, it could
only have been a typo.
[...]
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | "MikeP" <mp011011@some.org> |
|---|---|
| Date | 2011-07-15 23:09 -0500 |
| Message-ID | <ivr2ua$2h0$1@dont-email.me> |
| In reply to | #8336 |
Keith Thompson wrote: > "MikeP" <mp011011@some.org> writes: >> Nick Keighley wrote: >>> On Jul 15, 3:00 am, "MikeP" <mp011...@some.org> wrote: > [...] >>>> Well that's the THEORY behind programming language standard >>>> libraries, >>> >>> there is nothing as practical as a good theory. >> >> LOL. You surely meant to say: there's nothing practical about theory! > > Right, because if anyone states an opinion contrary to yours, it could > only have been a typo. > > [...] Lighten up dude, I was making a joke!
[toc] | [prev] | [next] | [standalone]
| From | Dr Nick <3-nospam@temporary-address.org.uk> |
|---|---|
| Date | 2011-07-16 08:24 +0100 |
| Message-ID | <87aacesn5l.fsf@temporary-address.org.uk> |
| In reply to | #8338 |
"MikeP" <mp011011@some.org> writes: > Keith Thompson wrote: >> "MikeP" <mp011011@some.org> writes: >>> Nick Keighley wrote: >>>> On Jul 15, 3:00 am, "MikeP" <mp011...@some.org> wrote: >> [...] >>>>> Well that's the THEORY behind programming language standard >>>>> libraries, >>>> >>>> there is nothing as practical as a good theory. >>> >>> LOL. You surely meant to say: there's nothing practical about theory! >> >> Right, because if anyone states an opinion contrary to yours, it could >> only have been a typo. >> >> [...] > > Lighten up dude, I was making a joke! If everything you say that is rubbish is a joke, could you start saying serious things please? -- Online waterways route planner | http://canalplan.eu Plan trips, see photos, check facilities | http://canalplan.org.uk
[toc] | [prev] | [next] | [standalone]
| From | "MikeP" <mp011011@some.org> |
|---|---|
| Date | 2011-07-16 03:38 -0500 |
| Message-ID | <ivrima$5mb$1@dont-email.me> |
| In reply to | #8344 |
Dr Nick wrote: > "MikeP" <mp011011@some.org> writes: > >> Keith Thompson wrote: >>> "MikeP" <mp011011@some.org> writes: >>>> Nick Keighley wrote: >>>>> On Jul 15, 3:00 am, "MikeP" <mp011...@some.org> wrote: >>> [...] >>>>>> Well that's the THEORY behind programming language standard >>>>>> libraries, >>>>> >>>>> there is nothing as practical as a good theory. >>>> >>>> LOL. You surely meant to say: there's nothing practical about >>>> theory! >>> >>> Right, because if anyone states an opinion contrary to yours, it >>> could only have been a typo. >>> >>> [...] >> >> Lighten up dude, I was making a joke! > > If everything you say that is rubbish is a joke, could you start > saying serious things please? I don't understand what you mean.
[toc] | [prev] | [next] | [standalone]
| From | Dr Nick <3-nospam@temporary-address.org.uk> |
|---|---|
| Date | 2011-07-16 10:17 +0100 |
| Message-ID | <87pqlar3dx.fsf@temporary-address.org.uk> |
| In reply to | #8347 |
"MikeP" <mp011011@some.org> writes: > Dr Nick wrote: >> "MikeP" <mp011011@some.org> writes: >> >>> Keith Thompson wrote: >>>> "MikeP" <mp011011@some.org> writes: >>>>> Nick Keighley wrote: >>>>>> On Jul 15, 3:00 am, "MikeP" <mp011...@some.org> wrote: >>>> [...] >>>>>>> Well that's the THEORY behind programming language standard >>>>>>> libraries, >>>>>> >>>>>> there is nothing as practical as a good theory. >>>>> >>>>> LOL. You surely meant to say: there's nothing practical about >>>>> theory! >>>> >>>> Right, because if anyone states an opinion contrary to yours, it >>>> could only have been a typo. >>>> >>>> [...] >>> >>> Lighten up dude, I was making a joke! >> >> If everything you say that is rubbish is a joke, could you start >> saying serious things please? > > I don't understand what you mean. No. -- Online waterways route planner | http://canalplan.eu Plan trips, see photos, check facilities | http://canalplan.org.uk
[toc] | [prev] | [next] | [standalone]
| From | gazelle@shell.xmission.com (Kenny McCormack) |
|---|---|
| Date | 2011-07-16 11:46 +0000 |
| Message-ID | <ivrtmf$abb$2@news.xmission.com> |
| In reply to | #8336 |
In article <lntyamoozv.fsf@nuthaus.mib.org>,
Keith Thompson <kst-u@mib.org> wrote:
>"MikeP" <mp011011@some.org> writes:
>> Nick Keighley wrote:
>>> On Jul 15, 3:00 am, "MikeP" <mp011...@some.org> wrote:
>[...]
>>>> Well that's the THEORY behind programming language standard
>>>> libraries,
>>>
>>> there is nothing as practical as a good theory.
>>
>> LOL. You surely meant to say: there's nothing practical about theory!
>
>Right, because if anyone states an opinion contrary to yours, it could
>only have been a typo.
That's rich - coming from you.
In your case, anyone who disagrees with you is automatically a "troll".
--
"We should always be disposed to believe that which appears to us to be
white is really black, if the hierarchy of the church so decides."
- Saint Ignatius Loyola (1491-1556) Founder of the Jesuit Order -
[toc] | [prev] | [next] | [standalone]
| From | lawrence.jones@siemens.com |
|---|---|
| Date | 2011-07-16 14:53 -0400 |
| Message-ID | <u939f8-oqo.ln1@jones.homeip.net> |
| In reply to | #8335 |
MikeP <mp011011@some.org> wrote: > Nick Keighley wrote: > > > > there is nothing as practical as a good theory. > > LOL. You surely meant to say: there's nothing practical about theory! In theory, there's no difference between theory and practice but in practice, there often is. :-) -- Larry Jones I don't NEED to compromise my principles, because they don't have the slightest bearing on what happens to me anyway. -- Calvin
[toc] | [prev] | [next] | [standalone]
| From | "MikeP" <mp011011@some.org> |
|---|---|
| Date | 2011-07-16 23:58 -0500 |
| Message-ID | <ivtq65$heu$1@dont-email.me> |
| In reply to | #8360 |
lawrence.jones@siemens.com wrote: > MikeP <mp011011@some.org> wrote: >> Nick Keighley wrote: >>> >>> there is nothing as practical as a good theory. >> >> LOL. You surely meant to say: there's nothing practical about theory! > > In theory, there's no difference between theory and practice but in > practice, there often is. :-) Yes, surely I was quipping about that. Who said that? I think you just admonished me Mr. Jones. TY. Eh em.. uh, you were saying Nick? Cat got your tongue? (hehehe). Just kiddin' ya Joe.
[toc] | [prev] | [next] | [standalone]
Page 8 of 10 — ← Prev page 1 … 6 7 [8] 9 10 Next page →
Back to top | Article view | comp.lang.c
csiph-web