Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #138239 > unrolled thread
| Started by | bart4858@gmail.com |
|---|---|
| First post | 2018-11-25 14:38 -0800 |
| Last post | 2018-11-26 14:38 +0000 |
| Articles | 20 on this page of 179 — 20 participants |
Back to article view | Back to comp.lang.c
_mingw_off_t.h bart4858@gmail.com - 2018-11-25 14:38 -0800
Re: _mingw_off_t.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-11-26 03:19 -0800
Re: _mingw_off_t.h David Brown <david.brown@hesbynett.no> - 2018-11-26 12:48 +0100
Re: _mingw_off_t.h Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-11-26 13:29 +0000
Re: _mingw_off_t.h Reinhardt Behm <rbehm@hushmail.com> - 2018-11-26 22:02 +0800
Re: _mingw_off_t.h Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-11-26 16:09 +0000
Re: _mingw_off_t.h bart4858@gmail.com - 2018-11-26 09:11 -0800
Re: _mingw_off_t.h bart4858@gmail.com - 2018-11-26 06:34 -0800
Re: _mingw_off_t.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-11-26 06:39 -0800
Re: _mingw_off_t.h Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-11-26 16:06 +0000
Re: _mingw_off_t.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-11-26 09:01 -0800
Re: _mingw_off_t.h scott@slp53.sl.home (Scott Lurndal) - 2018-11-26 17:04 +0000
Re: _mingw_off_t.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-11-26 09:19 -0800
Re: _mingw_off_t.h David Brown <david.brown@hesbynett.no> - 2018-11-26 22:19 +0100
Re: _mingw_off_t.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-11-26 14:11 -0800
Re: _mingw_off_t.h scott@slp53.sl.home (Scott Lurndal) - 2018-11-27 00:29 +0000
Re: _mingw_off_t.h gazelle@shell.xmission.com (Kenny McCormack) - 2018-11-27 09:44 +0000
Re: _mingw_off_t.h "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-11-27 01:49 -0800
Re: _mingw_off_t.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-11-27 04:21 -0800
Re: _mingw_off_t.h "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-11-27 04:25 -0800
Re: _mingw_off_t.h bart4858@gmail.com - 2018-11-27 04:51 -0800
Re: _mingw_off_t.h gazelle@shell.xmission.com (Kenny McCormack) - 2018-11-27 13:19 +0000
Re: _mingw_off_t.h Keith Thompson <kst-u@mib.org> - 2018-11-26 17:26 -0800
Re: _mingw_off_t.h David Brown <david.brown@hesbynett.no> - 2018-11-27 08:16 +0100
Re: _mingw_off_t.h bart4858@gmail.com - 2018-11-27 04:18 -0800
Re: _mingw_off_t.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-11-27 04:48 -0800
Re: _mingw_off_t.h bart4858@gmail.com - 2018-11-27 05:09 -0800
Re: _mingw_off_t.h David Brown <david.brown@hesbynett.no> - 2018-11-27 14:39 +0100
Re: _mingw_off_t.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-11-27 05:54 -0800
Re: _mingw_off_t.h David Brown <david.brown@hesbynett.no> - 2018-11-27 15:28 +0100
Re: _mingw_off_t.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-11-27 06:58 -0800
Re: _mingw_off_t.h scott@slp53.sl.home (Scott Lurndal) - 2018-11-27 15:03 +0000
Re: _mingw_off_t.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-11-27 07:13 -0800
Re: _mingw_off_t.h David Brown <david.brown@hesbynett.no> - 2018-11-27 16:55 +0100
Re: _mingw_off_t.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-11-27 09:02 -0800
Re: _mingw_off_t.h scott@slp53.sl.home (Scott Lurndal) - 2018-11-27 17:11 +0000
Re: _mingw_off_t.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-11-27 09:17 -0800
Re: _mingw_off_t.h scott@slp53.sl.home (Scott Lurndal) - 2018-11-27 17:48 +0000
Re: _mingw_off_t.h Bart <bc@freeuk.com> - 2018-11-27 20:35 +0000
Re: _mingw_off_t.h Ian Collins <ian-news@hotmail.com> - 2018-11-28 15:42 +1300
Re: _mingw_off_t.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-11-28 02:44 -0800
Re: _mingw_off_t.h Ian Collins <ian-news@hotmail.com> - 2018-11-28 23:52 +1300
Re: _mingw_off_t.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-11-28 03:42 -0800
Re: _mingw_off_t.h Anton Shepelev <anton.txt@g{oogle}mail.com> - 2018-11-28 15:48 +0300
Re: _mingw_off_t.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-11-28 05:24 -0800
Re: _mingw_off_t.h Anton Shepelev <anton.txt@g{oogle}mail.com> - 2018-11-28 17:30 +0300
Re: _mingw_off_t.h David Brown <david.brown@hesbynett.no> - 2018-11-28 13:59 +0100
Re: _mingw_off_t.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-11-28 05:33 -0800
Re: _mingw_off_t.h scott@slp53.sl.home (Scott Lurndal) - 2018-11-28 14:31 +0000
Re: _mingw_off_t.h David Brown <david.brown@hesbynett.no> - 2018-11-28 23:19 +0100
Re: _mingw_off_t.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-11-29 01:35 -0800
Re: _mingw_off_t.h David Brown <david.brown@hesbynett.no> - 2018-11-29 13:25 +0100
Re: _mingw_off_t.h scott@slp53.sl.home (Scott Lurndal) - 2018-11-28 14:28 +0000
Re: _mingw_off_t.h Anton Shepelev <anton.txt@g{oogle}mail.com> - 2018-11-28 17:33 +0300
Re: _mingw_off_t.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-11-28 06:56 -0800
Re: _mingw_off_t.h Bart <bc@freeuk.com> - 2018-11-28 11:53 +0000
Re: _mingw_off_t.h Bart <bc@freeuk.com> - 2018-11-28 12:09 +0000
Re: _mingw_off_t.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-11-28 01:26 -0800
Re: _mingw_off_t.h mark.bluemel@gmail.com - 2018-11-28 02:57 -0800
Re: _mingw_off_t.h jameskuyper@alumni.caltech.edu - 2018-11-27 09:49 -0800
Re: _mingw_off_t.h Keith Thompson <kst-u@mib.org> - 2018-11-27 11:31 -0800
Re: _mingw_off_t.h scott@slp53.sl.home (Scott Lurndal) - 2018-11-27 20:34 +0000
Re: _mingw_off_t.h David Brown <david.brown@hesbynett.no> - 2018-11-27 22:45 +0100
Re: _mingw_off_t.h scott@slp53.sl.home (Scott Lurndal) - 2018-11-27 14:12 +0000
Re: _mingw_off_t.h Keith Thompson <kst-u@mib.org> - 2018-11-27 11:32 -0800
Re: _mingw_off_t.h David Brown <david.brown@hesbynett.no> - 2018-11-27 14:36 +0100
Re: _mingw_off_t.h Bart <bc@freeuk.com> - 2018-11-27 14:45 +0000
Re: _mingw_off_t.h scott@slp53.sl.home (Scott Lurndal) - 2018-11-27 15:02 +0000
Re: _mingw_off_t.h David Brown <david.brown@hesbynett.no> - 2018-11-27 16:29 +0100
Re: _mingw_off_t.h scott@slp53.sl.home (Scott Lurndal) - 2018-11-27 15:51 +0000
Re: _mingw_off_t.h Bart <bc@freeuk.com> - 2018-11-27 16:00 +0000
Re: _mingw_off_t.h David Brown <david.brown@hesbynett.no> - 2018-11-27 23:40 +0100
Re: _mingw_off_t.h Bart <bc@freeuk.com> - 2018-11-28 01:22 +0000
Re: _mingw_off_t.h Ian Collins <ian-news@hotmail.com> - 2018-11-28 15:57 +1300
Re: _mingw_off_t.h David Brown <david.brown@hesbynett.no> - 2018-11-28 08:29 +0100
Re: _mingw_off_t.h Bart <bc@freeuk.com> - 2018-11-28 11:38 +0000
Re: _mingw_off_t.h Anton Shepelev <anton.txt@g{oogle}mail.com> - 2018-11-28 16:02 +0300
Re: _mingw_off_t.h Bart <bc@freeuk.com> - 2018-11-28 13:35 +0000
Re: _mingw_off_t.h Robert Wessel <robertwessel2@yahoo.com> - 2018-11-28 08:14 -0600
Re: _mingw_off_t.h Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-11-28 13:33 +0000
Re: _mingw_off_t.h Bart <bc@freeuk.com> - 2018-11-28 14:25 +0000
Re: _mingw_off_t.h David Brown <david.brown@hesbynett.no> - 2018-11-28 15:25 +0100
Re: _mingw_off_t.h Bart <bc@freeuk.com> - 2018-11-28 15:06 +0000
Re: _mingw_off_t.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-11-28 07:43 -0800
Re: _mingw_off_t.h scott@slp53.sl.home (Scott Lurndal) - 2018-11-28 15:49 +0000
Re: _mingw_off_t.h jameskuyper@alumni.caltech.edu - 2018-11-28 08:16 -0800
Re: _mingw_off_t.h Bart <bc@freeuk.com> - 2018-11-28 17:56 +0000
Re: _mingw_off_t.h David Brown <david.brown@hesbynett.no> - 2018-11-28 23:27 +0100
Re: _mingw_off_t.h Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-11-28 20:12 +0000
Re: _mingw_off_t.h Tim Rentsch <txr@alumni.caltech.edu> - 2018-11-29 09:58 -0800
Re: _mingw_off_t.h David Brown <david.brown@hesbynett.no> - 2018-11-29 13:04 +0100
Re: _mingw_off_t.h Bart <bc@freeuk.com> - 2018-11-29 12:41 +0000
Re: _mingw_off_t.h Richard Damon <Richard@Damon-Family.org> - 2018-11-29 08:19 -0500
Re: _mingw_off_t.h Bart <bc@freeuk.com> - 2018-11-29 14:28 +0000
Re: _mingw_off_t.h Richard Damon <Richard@Damon-Family.org> - 2018-11-29 22:25 -0500
Re: _mingw_off_t.h Bart <bc@freeuk.com> - 2018-11-30 11:59 +0000
Re: _mingw_off_t.h Richard Damon <Richard@Damon-Family.org> - 2018-11-30 08:02 -0500
Re: _mingw_off_t.h Bart <bc@freeuk.com> - 2018-11-30 14:09 +0000
Re: _mingw_off_t.h Richard Damon <Richard@Damon-Family.org> - 2018-11-30 10:30 -0500
Re: _mingw_off_t.h Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-11-30 16:02 +0000
Re: _mingw_off_t.h Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-11-30 16:40 +0000
Re: _mingw_off_t.h Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-11-30 17:23 +0000
Re: _mingw_off_t.h Tim Rentsch <txr@alumni.caltech.edu> - 2018-12-01 07:47 -0800
Re: _mingw_off_t.h Richard Damon <Richard@Damon-Family.org> - 2018-12-01 13:46 -0500
Re: _mingw_off_t.h Keith Thompson <kst-u@mib.org> - 2018-12-01 12:08 -0800
Re: _mingw_off_t.h David Brown <david.brown@hesbynett.no> - 2018-12-02 12:57 +0100
Re: _mingw_off_t.h Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-12-02 16:21 +0000
Re: _mingw_off_t.h David Brown <david.brown@hesbynett.no> - 2018-12-02 20:42 +0100
Re: _mingw_off_t.h Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-12-02 22:04 +0000
Re: _mingw_off_t.h David Brown <david.brown@hesbynett.no> - 2018-12-02 23:49 +0100
Re: _mingw_off_t.h Anton Shepelev <anton.txt@g{oogle}mail.com> - 2018-11-30 16:35 +0300
Re: _mingw_off_t.h Bart <bc@freeuk.com> - 2018-11-30 14:19 +0000
Re: _mingw_off_t.h scott@slp53.sl.home (Scott Lurndal) - 2018-11-30 14:58 +0000
Re: _mingw_off_t.h Richard Damon <Richard@Damon-Family.org> - 2018-11-30 10:33 -0500
Re: _mingw_off_t.h David Brown <david.brown@hesbynett.no> - 2018-11-30 15:45 +0100
Re: _mingw_off_t.h scott@slp53.sl.home (Scott Lurndal) - 2018-11-30 14:22 +0000
Re: _mingw_off_t.h Bart <bc@freeuk.com> - 2018-11-30 15:20 +0000
Re: _mingw_off_t.h David Brown <david.brown@hesbynett.no> - 2018-11-29 14:54 +0100
Re: _mingw_off_t.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-11-29 06:03 -0800
Re: _mingw_off_t.h David Brown <david.brown@hesbynett.no> - 2018-11-29 16:09 +0100
Re: _mingw_off_t.h Bart <bc@freeuk.com> - 2018-11-29 16:44 +0000
Re: _mingw_off_t.h David Brown <david.brown@hesbynett.no> - 2018-11-29 22:08 +0100
Re: _mingw_off_t.h Bart <bc@freeuk.com> - 2018-11-29 22:29 +0000
Re: _mingw_off_t.h David Brown <david.brown@hesbynett.no> - 2018-11-30 10:27 +0100
Re: _mingw_off_t.h Keith Thompson <kst-u@mib.org> - 2018-11-30 01:49 -0800
"real" programming langauges? (Was: _mingw_off_t.h) gazelle@shell.xmission.com (Kenny McCormack) - 2018-12-01 08:18 +0000
Re: "real" programming langauges? (Was: _mingw_off_t.h) David Brown <david.brown@hesbynett.no> - 2018-12-01 18:02 +0100
That time back in 1987... (Was: "real" programming langauges? (Was: _mingw_off_t.h)) gazelle@shell.xmission.com (Kenny McCormack) - 2018-12-01 17:31 +0000
Re: That time back in 1987... (Was: "real" programming langauges? (Was: _mingw_off_t.h)) David Brown <david.brown@hesbynett.no> - 2018-12-02 13:03 +0100
Re: That time back in 1987... (Was: "real" programming langauges? (Was: _mingw_off_t.h)) James Kuyper <jameskuyper@alumni.caltech.edu> - 2018-12-02 23:05 -0500
Re: That time back in 1987... (Was: "real" programming langauges? (Was: _mingw_off_t.h)) David Brown <david.brown@hesbynett.no> - 2018-12-03 11:38 +0100
Re: _mingw_off_t.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-11-30 02:00 -0800
Re: _mingw_off_t.h Ian Collins <ian-news@hotmail.com> - 2018-11-30 08:16 +1300
Re: _mingw_off_t.h Bart <bc@freeuk.com> - 2018-11-29 20:49 +0000
Re: _mingw_off_t.h Ian Collins <ian-news@hotmail.com> - 2018-11-30 19:39 +1300
Re: _mingw_off_t.h gazelle@shell.xmission.com (Kenny McCormack) - 2018-11-30 10:37 +0000
Re: _mingw_off_t.h Bart <bc@freeuk.com> - 2018-11-30 20:21 +0000
Re: _mingw_off_t.h scott@slp53.sl.home (Scott Lurndal) - 2018-11-30 20:23 +0000
Re: _mingw_off_t.h Ian Collins <ian-news@hotmail.com> - 2018-12-01 10:13 +1300
Re: _mingw_off_t.h Bart <bc@freeuk.com> - 2018-11-30 22:14 +0000
Re: _mingw_off_t.h Ian Collins <ian-news@hotmail.com> - 2018-12-01 11:29 +1300
Re: _mingw_off_t.h Richard Damon <Richard@Damon-Family.org> - 2018-11-30 18:32 -0500
Re: _mingw_off_t.h scott@slp53.sl.home (Scott Lurndal) - 2018-11-30 23:47 +0000
Re: _mingw_off_t.h David Brown <david.brown@hesbynett.no> - 2018-12-01 18:05 +0100
Re: _mingw_off_t.h Richard Damon <Richard@Damon-Family.org> - 2018-12-01 13:29 -0500
Re: _mingw_off_t.h Tim Rentsch <txr@alumni.caltech.edu> - 2018-12-01 07:28 -0800
Re: _mingw_off_t.h Bart <bc@freeuk.com> - 2018-12-01 16:49 +0000
Re: _mingw_off_t.h Ian Collins <ian-news@hotmail.com> - 2018-11-29 08:53 +1300
Re: _mingw_off_t.h scott@slp53.sl.home (Scott Lurndal) - 2018-11-28 20:01 +0000
Re: _mingw_off_t.h Bart <bc@freeuk.com> - 2018-11-28 21:15 +0000
Re: _mingw_off_t.h scott@slp53.sl.home (Scott Lurndal) - 2018-11-28 21:26 +0000
Re: _mingw_off_t.h Bart <bc@freeuk.com> - 2018-11-29 00:22 +0000
Re: _mingw_off_t.h scott@slp53.sl.home (Scott Lurndal) - 2018-11-29 14:14 +0000
Re: _mingw_off_t.h Bart <bc@freeuk.com> - 2018-11-29 14:54 +0000
Re: _mingw_off_t.h scott@slp53.sl.home (Scott Lurndal) - 2018-11-28 14:19 +0000
Re: _mingw_off_t.h Robert Wessel <robertwessel2@yahoo.com> - 2018-11-27 16:44 -0600
Re: _mingw_off_t.h Ike Naar <ike@iceland.freeshell.org> - 2018-11-29 22:58 +0000
Re: _mingw_off_t.h Bart <bc@freeuk.com> - 2018-11-30 00:58 +0000
Re: _mingw_off_t.h scott@slp53.sl.home (Scott Lurndal) - 2018-11-27 14:11 +0000
Re: _mingw_off_t.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-11-27 06:28 -0800
Re: _mingw_off_t.h Bart <bc@freeuk.com> - 2018-11-27 15:14 +0000
Re: _mingw_off_t.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-11-27 07:41 -0800
Re: _mingw_off_t.h Bart <bc@freeuk.com> - 2018-11-27 16:11 +0000
Re: _mingw_off_t.h Tim Rentsch <txr@alumni.caltech.edu> - 2018-11-29 10:00 -0800
Re: _mingw_off_t.h Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-11-26 17:24 +0000
Re: _mingw_off_t.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-11-26 10:57 -0800
Re: _mingw_off_t.h scott@slp53.sl.home (Scott Lurndal) - 2018-11-26 19:06 +0000
Re: _mingw_off_t.h bart4858@gmail.com - 2018-11-26 12:16 -0800
Re: _mingw_off_t.h David Brown <david.brown@hesbynett.no> - 2018-11-26 12:52 +0100
Re: _mingw_off_t.h bart4858@gmail.com - 2018-11-26 04:17 -0800
Re: _mingw_off_t.h David Brown <david.brown@hesbynett.no> - 2018-11-26 14:40 +0100
What is wrong with this sentence? (Was: _mingw_off_t.h) gazelle@shell.xmission.com (Kenny McCormack) - 2018-11-26 13:34 +0000
Re: What is wrong with this sentence? (Was: _mingw_off_t.h) Anton Shepelev <anton.txt@g{oogle}mail.com> - 2018-11-26 16:39 +0300
Re: What is wrong with this sentence? (Was: _mingw_off_t.h) bart4858@gmail.com - 2018-11-26 06:13 -0800
Re: What is wrong with this sentence? (Was: _mingw_off_t.h) David Brown <david.brown@hesbynett.no> - 2018-11-26 16:13 +0100
Re: What is wrong with this sentence? (Was: _mingw_off_t.h) David Brown <david.brown@hesbynett.no> - 2018-11-26 14:42 +0100
Re: _mingw_off_t.h Keith Thompson <kst-u@mib.org> - 2018-11-26 13:02 -0800
Re: _mingw_off_t.h David Brown <david.brown@hesbynett.no> - 2018-11-26 22:24 +0100
Re: _mingw_off_t.h scott@slp53.sl.home (Scott Lurndal) - 2018-11-26 14:38 +0000
Page 4 of 9 — ← Prev page 1 2 3 [4] 5 6 7 8 9 Next page →
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2018-11-27 11:31 -0800 |
| Message-ID | <lnr2f6nwqv.fsf@kst-u.example.com> |
| In reply to | #138317 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> On Tuesday, November 27, 2018 at 3:55:49 PM UTC, David Brown wrote:
[...]
> Two out of five programmers contributing to this thread think that
> the proliferation of integer types is a problem. I've also heard
> complaints elsewhere, but of course it's hard to dig up actual references.
>
> But basically its common sense. Machines support a very limited number
> of integer types at the instruction level. So why do you need a huge long
> list?
By your own claim, three out of five programmers *don't* think it's a
problem.
It's not just a "huge long list". Each integer type defined by the
library (size_t, [u]intN_t, etc.) has a specific purpose. Use what you
need.
[...]
>> Let's just take the example from earlier. How would /you/ define the
>> return type for clock() ? Remembering that modern PC users probably
>> want 1µs or 1ns precision and ranges for years, while 8-bit embedded
>> systems might want 1ms precision covering days?
>>
> So time is continuous, and SI units are seconds.
> So double clock() - return time in seconds since system start-up.
> Now everything should work.
>
> The snag is when the 8 bit embedded system doesn't have a double,
> but then it's not conforming anyway.
On the system I'm using, clock_t is a 64-bit integer type (or a
32-bit integer type if I compile with "gcc -m32") with microsecond
resolution (CLOCKS_PER_SEC == 1000000). Using a floating-point
type would mean that the precision varies depending on how long
the program has been running (though admittedly the precision is
better than one microsecond for any reasonable run time).
It's likely that the CPU time a program has used is stored or
computed by the OS as an integer. Converting that integer to
floating-point introduces unnecessary complexity.
But sure, you can make clock_t anything you like if you ignore
existing systems.
--
Keith Thompson (The_Other_Keith) kst@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2018-11-27 20:34 +0000 |
| Message-ID | <pThLD.671596$8r2.615745@fx34.iad> |
| In reply to | #138322 |
Keith Thompson <kst-u@mib.org> writes:
>Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>> Let's just take the example from earlier. How would /you/ define the
>>> return type for clock() ? Remembering that modern PC users probably
>>> want 1µs or 1ns precision and ranges for years, while 8-bit embedded
>>> systems might want 1ms precision covering days?
>>>
>> So time is continuous, and SI units are seconds.
>> So double clock() - return time in seconds since system start-up.
>> Now everything should work.
>>
>> The snag is when the 8 bit embedded system doesn't have a double,
>> but then it's not conforming anyway.
>
>On the system I'm using, clock_t is a 64-bit integer type (or a
>32-bit integer type if I compile with "gcc -m32") with microsecond
>resolution (CLOCKS_PER_SEC == 1000000). Using a floating-point
>type would mean that the precision varies depending on how long
>the program has been running (though admittedly the precision is
>better than one microsecond for any reasonable run time).
>
>It's likely that the CPU time a program has used is stored or
>computed by the OS as an integer. Converting that integer to
>floating-point introduces unnecessary complexity.
And worse, it would have an adverse performance effect on a
lot of programs that don't otherwise use floating point operations.
Operating systems will optimize context switch overhead by not
saving floating point state if it wasn't used by the thread/process
(Particularly on x86/x86_64 systems).
This breaks that optimization for no good reason.
Someone recently had posted a loop (on the C++ group)
that used a floating constant in the loop:
for (int i = 0; i < 1e6; i++) {
}
GCC actually generated SSE instructions for this. The generated
code was much simpler without the floating point constant.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-11-27 22:45 +0100 |
| Message-ID | <ptkdug$p7d$1@dont-email.me> |
| In reply to | #138317 |
On 27/11/2018 18:02, Malcolm McLean wrote: > On Tuesday, November 27, 2018 at 3:55:49 PM UTC, David Brown wrote: >> On 27/11/18 15:58, Malcolm McLean wrote: >>> On Tuesday, November 27, 2018 at 2:29:05 PM UTC, David Brown wrote: >>>> On 27/11/18 14:54, Malcolm McLean wrote: >>>> >>>> You have worm's eye view. You see C purely in terms of how /you/ want >>>> to use it for /your/ programs on /your/ systems - you fail to see how >>>> other people use it for other programs on other systems. You fail to >>>> recognise that maybe other people have different needs or wants than >>>> your own. >>>> >>> I use C for general data processing where high performance is required, >>> and I started my career as a games programmer. I then did a PhD on >>> the protein folding problem, and I now work as a graphics programmer. >>> So general purpose programming, for the point of view of C. >> >> That is like saying "I drive my car to work each day, and to the shops >> at the weekend - so general driving" and then thinking that all road >> users should use the same vehicle as you do. >> >> Your uses of C cover a tiny, tiny spread of how the language is used by >> others. (So do /my/ uses, but I have no illusions about that.) >> >> It is particularly amusing to hear you argue for fewer integer types >> when you claim you need high performance. People using C for high >> performance regularly want very careful control of their types, and use >> many different types so that they can get maximal use of features like >> SIMD processing, maximal hit rates on their caches, etc. >> > I can't use that sort of micro-optimisation because my code has to be > portable. It also has to slot in to other, larger programs. That might be reasonable enough. It is possible to write code that is portable and also generates SIMD instructions on systems that support it, but that depends on the kind of program and the kind of portability, and the amount of effort appropriate. >> >> Oh, so you really thought you were covering all the needs of embedded >> programmers and every other C programmer? Honestly? >> > C is a general purpose programming language. C is a language with a very wide range of uses. No one type of programming can really be said to be "general C programming". And certainly the types you describe as being "all that are needed" for other programmers are very far from covering the needs of this wide range of uses. >> >>> I speak to the C community. The sheer proliferation of integer types >>> has become a problem. >> >> What is your justification for this, beyond the sample of you and Bart? >> We know from experience that you have your own way of thinking, your >> own way of coding, your own terminology, and your own ideas about what >> types are needed (which is fair enough, for your own programming - but >> it does not carry over to other people). We also know that Bart has >> enormous difficulties about learning /anything/ related to C, and he >> rejects all help, advice and knowledge. >> >> So outside of this, what evidence do you have for the integer types in C >> being a problem? What evidence do you have for suggesting it has >> /become/ a problem - that someone everything was fine at some point in >> the past, and now it is not? >> > Two out of five programmers contributing to this thread think that > the proliferation of integer types is a problem. I've also heard > complaints elsewhere, but of course it's hard to dig up actual references. > That is hardly a good sample. > But basically its common sense. Machines support a very limited number > of integer types at the instruction level. So why do you need a huge long > list? C is not assembly. It is a high level language. It has a range of types - some very concrete, some much more abstract - to suit many uses. The range of types are designed to give programmers choices, with a balance between efficiency, flexibility and portability. >> >> I can certainly agree that mixing types from different places can >> complicate things, and that too many different types is unhelpful. That >> applies to all sorts of things - split files into too many bits, have >> too many functions in your API, too many buttons on your GUI window. >> That does not mean you should not use appropriate types, or that you >> should not abstract your types when it makes sense! >> > You see you understand the benefits of abstraction, but not the > cost. That's because the costs are small, but cumulative. In fact "int" > is already an abstraction. I understand the real cost of abstraction types such as clock_t. The cost is that you don't have pre-defined information about the ranges and the precision of the type. I also understand that the things you and Bart complain about - that it is all too difficult, there are too many types, there are too many layers, there are scary preprocessor directives - are no cost at all. >> >> One situation where multiple types can be a pain in small embedded >> systems is that a fair number of libraries, RTOS'es, etc., are written >> for C90 rather than C99. And these usually need size-specific integer >> types - but they can't use the standard C99 <stdint.h> types. So it is >> not uncommon to see libraries with their own U32, or uint32, or U32_t, >> types. That kind of thing is ugly and unnecessary, and /can/ cause >> trouble, but nothing insurmountable. >> >>> I am not convinced that you need, in the C standard, a whole list of >>> abstract types which are defined in terms of the basic types. >> >> Let's just take the example from earlier. How would /you/ define the >> return type for clock() ? Remembering that modern PC users probably >> want 1µs or 1ns precision and ranges for years, while 8-bit embedded >> systems might want 1ms precision covering days? >> > So time is continuous, and SI units are seconds. > So double clock() - return time in seconds since system start-up. > Now everything should work. > > The snag is when the 8 bit embedded system doesn't have a double, > but then it's not conforming anyway. > It won't work on an 8-bit system with full doubles, or an embedded 32-bit system, or anywhere else where you want efficient handling of time and don't have high speed operations on double-precision floating point. The /huge/ majority of processors sold are very much slower (several orders of magnitude) at handling double-precision floating point operations than integer operations. So your attempt at giving an alternative return type for clock() is a total failure to meet the requirements.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2018-11-27 14:12 +0000 |
| Message-ID | <qhcLD.265001$X82.216044@fx22.iad> |
| In reply to | #138292 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: >On Tuesday, November 27, 2018 at 12:19:12 PM UTC, bart...@gmail.com wrote: > >So we've got four sizes, 8, 16, 32 and 64 bits. There's signed and >unsigned, and you need unsigned 8 bit values. But a signed 16 bit >type will hold values that go up to 32767. Unsigned gives values >up to 65535. So for unsigned to make sense, you need a number that >can go above 32767, but not above 65535, and where just using 43 >bits isn't a sensible option. That's quite a narrow use case, examples >might be fixed-point representation of real numbers (so not really >integers) and amounts of memory in machines with 64 kilobytes installed. >Is that enough to justify an unsigned type? Similar arguments >apply to 32 and 64 bits. > >The other reason for using unsigned is to document that a number is >naturally a non-negative, e.g. a count of employees. But this is poor >practice because intermediate calculations involving values like that >often can go negative. > >So really we need five types > >8 bit signed, 8 bit unsigned, 16 bit, 32 bit, 64 bit signed. > Have you ever written a real program?
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2018-11-27 11:32 -0800 |
| Message-ID | <lnmupunwo1.fsf@kst-u.example.com> |
| In reply to | #138292 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
[...]
> So really we need five types
>
> 8 bit signed, 8 bit unsigned, 16 bit, 32 bit, 64 bit signed.
[...]
That's similar to what Java does (though Java has operators that
essentially treat signed integers as if they were unsigned).
--
Keith Thompson (The_Other_Keith) kst@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-11-27 14:36 +0100 |
| Message-ID | <ptjh88$d2c$1@dont-email.me> |
| In reply to | #138289 |
On 27/11/18 13:18, bart4858@gmail.com wrote: > On Tuesday, 27 November 2018 07:16:16 UTC, David Brown wrote: >> On 26/11/2018 23:11, Malcolm McLean wrote: > >>> Can't you see that there are too many integer types in the C standard? >> >> No. >> >> I don't use all of the integer types in the C standard - I doubt if >> anyone does. But they will all be of use to some people, and I am not >> so selfish as to expect a language to be defined around my own personal >> needs and wants. > > This was posted by me last year, but is worth repeating. You posted this before. Did you pay any attention to the responses you got at the time? Which of them made you feel it was worth repeating? We know you feel it is a problem that C lets you define types that are aliases of existing types. We know you feel it is a problem that people write general libraries or portable code, and use named types for abstraction so that code can be used on many processors, OS's, or configurations - and that you would be happier if everyone concentrated solely on the platforms and processors that /you/ want to use. > It's how > clock_t is defined in a particular set of system headers (I believe > under Linux): > > clock_t => > __clock_t => > __CLOCK_T_TYPE => > __SYSCALL_S_LONG => > __SQUAD_T => > __quad_t => > long int > > So clock_t is just a 'long int' here. Except that isn't quite the full > story, as that would be int64 under Linux, but int32 under Windows. So > even this is platform-specific. No, clock_t is not "just a long int". "clock_t" is a type suitable for holding time counts, with a range and precision that makes sense for the system in use. What that range and precision is, depends on the system. That gives implementers flexibility - a modern 64-bit PC OS can have a longer range and higher precision than made sense on systems 30 years ago, or that are in use on a tiny embedded system. The cost of the flexibility is that the actual ranges and precisions are not fixed in the standard library - you can't use the "clock()" function as-is if you want, say, microsecond precision times of up to a year. Having these layers of indirection and abstraction - whether it be via typedefs, macros, conditional compilation, whatever - keeps things flexible. It means that you might have a 32-bit OS with 64-bit times, or a 64-bit OS with 32-bit times, or an OS that supports libraries and programs with different combinations on the same system. And how much do these layers affect users - i.e., C programmers? Not at all. Apart from a few people in this newsgroup, they really do not matter in the slightest. (It matters that the precision and range are not defined in advance - that is the price you pay for the flexibility, and that may be a hard price to pay. But /how/ that is achieved - the layers along the way, and the multiple type names - is irrelevant.) > > I don't know which kinds of integers Malcolm is refering to. But I'm > talking about stuff like this as well as the standard types of which > there /are/ too many. > >> If I were to design a language, its integer types would we defined in a >> different way from those in C, but it would have many more integer >> types. (In particular, you'd be able to define new integer types with >> specific ranges - thus there would be no limit to the number of integer >> types.) > > This is C; it's not Pascal or Ada. I recall the Pascal I used had only > the one basic INTEGER type. Early Pascal was very limited, and has - as you say - just one integer type (whose range was implementation defined). Most popular Pascal implementations had a range of integer types. For example, Delphi has 2 platform-dependent types (whose size varies) and 5 platform-independent types - and then another 7 unsigned versions of these. > There is a point to user-defined integers in > those languages, which doesn't apply to C. Nothing stops you using a > clock_t in place of a dev_t. And nothing stops you using a clock_t* in > place of a dev_t* if both happen to have the same underlying type. There > is no safety. That is true - nothing in the C language stops you mixing type names, since typedefs are aliases and not new types. The type names in C are for the benefit of the programmer - it is up to the programmer to use them appropriately. The language can't stop you mixing mixing dev_t and clock_t (if they have the same underlying type) any more than it can stop you writing a timer function called "get_device_id". So type names in C serve much the same purpose as being able to write functions with different names, rather than just "func1", "func2", "func3". > >> Nonsense. You haven't the slightest evidence for calling this a "design >> by committee problem", nor the slightest evidence that "design by >> committee" is a bad thing for the types in C, nor even any reason for >> supposing that the number of integer types in C is a problem. Invented >> problems about translating from other languages to C do not count - if >> you understood about the types in C, you would realise they help such >> translators, rather than hindering them. > > A typical x64 assembler supports these 5 basic storage types: > > db 0 # 1 byte > dw 0 # 2 bytes > dd 0 # 4 bytes > dq 0 # 8 bytes > do 0 # 16 bytes > > They can define initialised static data for i8/16/32/64/128, > as well as u8/16/32/64/128, f32/64/128, plus for arrays of those types, > and structs using those types. > > Now /that/ is simple. > Simple, yes - no one will deny that. It is also limited, inflexible, loses a whole range of possibilities for writing clearer code, and makes porting harder. If you want to write your C code with nothing but a few fixed-size types, that's up to you. That makes sense for some kinds of code - generated code from an interpreter is one such case. C won't stop you - indeed, it makes it easy with the <stdint.h> types. But most of the rest of us, who want to write quality C code as the source language, prefer to have a bit more clarity and legibility in our coding - and use more types.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2018-11-27 14:45 +0000 |
| Message-ID | <XLcLD.75681$lKb.3224@fx15.am4> |
| In reply to | #138296 |
On 27/11/2018 13:36, David Brown wrote:
> On 27/11/18 13:18, bart4858@gmail.com wrote:
>> clock_t =>
>> __clock_t =>
>> __CLOCK_T_TYPE =>
>> __SYSCALL_S_LONG =>
>> __SQUAD_T =>
>> __quad_t =>
>> long int
>>
>> So clock_t is just a 'long int' here.
> No, clock_t is not "just a long int".
It's a long int /here/.
"clock_t" is a type suitable for
> holding time counts, with a range and precision that makes sense for the
> system in use. What that range and precision is, depends on the system.
> That gives implementers flexibility - a modern 64-bit PC OS can have a
> longer range and higher precision than made sense on systems 30 years
> ago,
There must be a million functions that return an integer value of this
kind. The vast majority don't consider it necessary to invent a new kind
of integer for that return type. What's so special about the count
returned by clock()?
On a modern PC just use int64 for everything, unless you know that int
(ie. usually int32) is adequate.
> Having these layers of indirection and abstraction - whether it be via
> typedefs, macros, conditional compilation, whatever - keeps things
> flexible. It means that you might have a 32-bit OS with 64-bit times,
> or a 64-bit OS with 32-bit times, or an OS that supports libraries and
> programs with different combinations on the same system.
>
> And how much do these layers affect users - i.e., C programmers? Not at
> all.
There is no excuse for those six layers, which is a sign of non-existent
maintenance: people just adding stuff, to avoid disrupting existing code
which may stop working.
The whole thing is symptomatic of many other things I see going on. (I
used to do the same when painting my rotting window frames every year,
but in the end I had to get the lot torn out and replaced.)
> So type names in C serve much the same purpose as being able to write
> functions with different names, rather than just "func1", "func2", "func3".
I don't think so. Different function and variable names are a necessity,
as they all do different things. You can't have 50 functions all with
the same name. But you can have 50 variables, parameters and function
return types all using the same int type.
There was a pathological case, I think involving a 'struct stat', of a
struct where practical every integer member was given its own private
integer type. So you saw this pattern:
struct {
A a;
B b;
C c;
D d;
}
instead of:
struct {
int a;
int b;
int c;
int d;
}
which can also be written as:
struct { int a, b, c, d;}
Which one conveys more information just from the given context? Which
one is easier to duplicate in a separate language? Which member can be
copied to another without losing information? Which member /can/ be
copied to another?
There is clearly something amiss with the first example. Imagine if
EVERY int variable, parameter or return type had its own private typedef.
>> Now /that/ is simple.
> Simple, yes - no one will deny that. It is also limited, inflexible,
> loses a whole range of possibilities for writing clearer code, and makes
> porting harder.
>
> If you want to write your C code with nothing but a few fixed-size
> types, that's up to you.
What's wrong with that? I like seeing concrete types in a struct
definition; see above.
> But most of the rest of us, who want to write quality C code as the
> source language, prefer to have a bit more clarity and legibility in our
> coding - and use more types.
Clarity and legibility are at odds with using gratuitous user types.
(Why is everyone chary of using raw integer types in C? Is it because
the classic types are ill-defined, while the intN_t types are ugly?)
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2018-11-27 15:02 +0000 |
| Message-ID | <y0dLD.435854$ql2.223172@fx06.iad> |
| In reply to | #138304 |
Bart <bc@freeuk.com> writes: > "clock_t" is a type suitable for >> holding time counts, with a range and precision that makes sense for the >> system in use. What that range and precision is, depends on the system. >> That gives implementers flexibility - a modern 64-bit PC OS can have a >> longer range and higher precision than made sense on systems 30 years >> ago, > >There must be a million functions that return an integer value of this >kind. The vast majority don't consider it necessary to invent a new kind >of integer for that return type. What's so special about the count >returned by clock()? > >On a modern PC just use int64 for everything, unless you know that int >(ie. usually int32) is adequate. C is used on far more than just a "modern PC". Abstract types are there for a reason. Just because it's not useful to you doesn't mean that it's not useful to others. There's also history to consider; many abstract types (uid_t, gid_t for example) were defined to support portable code across implementations that have different sizes for 'int'.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-11-27 16:29 +0100 |
| Message-ID | <ptjnsi$ebr$1@dont-email.me> |
| In reply to | #138304 |
On 27/11/18 15:45, Bart wrote:
> On 27/11/2018 13:36, David Brown wrote:
>> On 27/11/18 13:18, bart4858@gmail.com wrote:
>
>>> clock_t =>
>>> __clock_t =>
>>> __CLOCK_T_TYPE =>
>>> __SYSCALL_S_LONG =>
>>> __SQUAD_T =>
>>> __quad_t =>
>>> long int
>>>
>>> So clock_t is just a 'long int' here.
>
>> No, clock_t is not "just a long int".
>
> It's a long int /here/.
>
It is a /clock_t/ here. The implementation might happen to be the same
as a "long int", but that's an implementation detail.
When you want to turn the result of calling clock() into seconds, you
divide by CLOCKS_PER_SEC. You don't divide by 100, or 1000, or whatever
the value happens to be on your particular platform. That is because
CLOCKS_PER_SEC means something more than "100" or "1000".
Similarly, "clock_t" has meaning beyond just "long int" or whatever it
happens to be on that platform.
> "clock_t" is a type suitable for
>> holding time counts, with a range and precision that makes sense for the
>> system in use. What that range and precision is, depends on the system.
>> That gives implementers flexibility - a modern 64-bit PC OS can have a
>> longer range and higher precision than made sense on systems 30 years
>> ago,
>
> There must be a million functions that return an integer value of this
> kind. The vast majority don't consider it necessary to invent a new kind
> of integer for that return type. What's so special about the count
> returned by clock()?
>
For many functions, "int" is fine as a return value. For many more
functions that return "int", they would have been better with a more
appropriate type. That could be "bool", or an enumeration, or a typedef
name.
clock() returns a clock_t because the exact type needed can vary from
system to system. That makes it special.
> On a modern PC just use int64 for everything, unless you know that int
> (ie. usually int32) is adequate.
>
There you go with the worm's eye view. The world does not revolve
around modern PC's. The C programming language is not all about modern
PC's.
If you are making a programming language whose sole target is modern
PC's, then having a single integer type for everything - or almost
everything - makes sense. Languages like Python and Lua have only one
integer type, and use a different system for interfacing to external
functions or matching structures in files, network protocols, etc.,
which have size-specific type requirements.
But C is not that kind of language, and many C programs need other types.
>> Having these layers of indirection and abstraction - whether it be via
>> typedefs, macros, conditional compilation, whatever - keeps things
>> flexible. It means that you might have a 32-bit OS with 64-bit times,
>> or a 64-bit OS with 32-bit times, or an OS that supports libraries and
>> programs with different combinations on the same system.
>>
>> And how much do these layers affect users - i.e., C programmers? Not at
>> all.
>
> There is no excuse for those six layers, which is a sign of non-existent
> maintenance: people just adding stuff, to avoid disrupting existing code
> which may stop working.
The cost of adding these layers is virtually nothing. The benefits of
avoiding disrupting existing code is almost priceless. Do you
understand the concept of cost/benefit analysis?
C is an /old/ programming language. Unix, and all its relatives,
derivatives, and duplications is an /old/ system. Of course it has
built up layers over the years. Of course it would be different, and
more streamlined, if you could throw out everything and start from scratch.
While you are at it, you could rationalise the spelling of English, make
the Americans drive on the left side of the road, and insist that house
paint comes in only three different colours because no one really needs
more than that.
Or maybe you think that supporting the existing status quo, keeping
compatibility with the world around us, and giving people a choice is a
good thing?
>
> The whole thing is symptomatic of many other things I see going on. (I
> used to do the same when painting my rotting window frames every year,
> but in the end I had to get the lot torn out and replaced.)
>
The big difference is that there is no rot here. People are not
bothered by the definition of clock_t - it is an implementation detail,
just like the definition of the clock() function.
>> So type names in C serve much the same purpose as being able to write
>> functions with different names, rather than just "func1", "func2",
>> "func3".
>
> I don't think so. Different function and variable names are a necessity,
> as they all do different things. You can't have 50 functions all with
> the same name. But you can have 50 variables, parameters and function
> return types all using the same int type.
I do different things with my types, and I like the names to reflect
their usage.
>
> There was a pathological case, I think involving a 'struct stat', of a
> struct where practical every integer member was given its own private
> integer type. So you saw this pattern:
>
> struct {
> A a;
> B b;
> C c;
> D d;
> }
>
> instead of:
>
> struct {
> int a;
> int b;
> int c;
> int d;
> }
>
> which can also be written as:
>
> struct { int a, b, c, d;}
>
> Which one conveys more information just from the given context?
With meaningless type names like A, B, C, and meaningless field names,
then neither gives much information. So it is a silly question.
If the type names were appropriate, then they would add more information
- that much is obvious.
> Which
> one is easier to duplicate in a separate language?
Who cares? The number of people making an interface between two
languages is negligible compared to the number of people /using/ the two
languages. The effort required to make the interface is therefore
irrelevant in the grand scheme of things. What is important is that the
function is easy to write, maintain, port and use in its original
language, and that the wrapper in the second language is easy to use in
that second language. It is of almost no consequence how much effort is
needed to write that wrapper.
> Which member can be
> copied to another without losing information? Which member /can/ be
> copied to another?
Again, with a meaningless example you are asking meaningless questions.
>
> There is clearly something amiss with the first example. Imagine if
> EVERY int variable, parameter or return type had its own private typedef.
No one is suggesting that.
>
>>> Now /that/ is simple.
>
>> Simple, yes - no one will deny that. It is also limited, inflexible,
>> loses a whole range of possibilities for writing clearer code, and makes
>> porting harder.
>>
>> If you want to write your C code with nothing but a few fixed-size
>> types, that's up to you.
>
> What's wrong with that? I like seeing concrete types in a struct
> definition; see above.
As I said, there is nothing wrong with it - write things that way if you
want. But don't expect or demand that others write things the way /you/
like it - some will, others won't.
>
>> But most of the rest of us, who want to write quality C code as the
>> source language, prefer to have a bit more clarity and legibility in our
>> coding - and use more types.
>
> Clarity and legibility are at odds with using gratuitous user types.
>
Clarity and legibility are not at odds with sensible use of user types -
they are enhanced by it. Of course they are at odds with abuses or
extremes - /any/ feature can be taken too far and result in lower
quality code. (I believe I have covered this a fair number of times
already.)
> (Why is everyone chary of using raw integer types in C? Is it because
> the classic types are ill-defined, while the intN_t types are ugly?)
>
No one minds using the standard types - whether it be "int", "long int",
or "int32_t", "uint64_t", or whatever. All that has been said here is
that there are good uses of additional integer type aliases.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2018-11-27 15:51 +0000 |
| Message-ID | <rKdLD.200613$MJ2.153301@fx12.iad> |
| In reply to | #138310 |
David Brown <david.brown@hesbynett.no> writes:
>On 27/11/18 15:45, Bart wrote:
>> (Why is everyone chary of using raw integer types in C? Is it because
>> the classic types are ill-defined, while the intN_t types are ugly?)
>>
>
>No one minds using the standard types - whether it be "int", "long int",
>or "int32_t", "uint64_t", or whatever. All that has been said here is
>that there are good uses of additional integer type aliases.
Actually, there are very good reasons, dating back three decades, for
why "everyone is <legitimately> chary of using raw integer types". They
don't work well in code that needs to be portable and future proof. A
lesson first learned when moving from the PDP-11 to the VAX.
You (bart/hannah/malcom) refer to struct stat as an egregious example.
Here's the version of struct stat in the 1970's (Unix V7):
struct stat
{
dev_t st_dev;
ino_t st_ino;
unsigned short st_mode;
short st_nlink;
short st_uid;
short st_gid;
dev_t st_rdev;
off_t st_size;
time_t st_atime;
time_t st_mtime;
time_t st_ctime;
};
They screwed up in only two respects, which were fixed
a few years later, and that's with the definition of
the st_uid and st_gid fields which are now defined
as uid_t and gid_t[*] and the various time fields which
are now of type 'struct timespec' to provide higher
resolution timestamps.
[*] these were explicitly added because of the difficulties
of porting software which assumed gid's and uid's were short
(16 bits) to operating environments (e.g. the VAX) where uids/gids
were expanded to 32-bits (because 16-bits was insufficient).
By using abstract types for these, no user application would require
more than a simple compile on an architecture with different
sizes for any of the fields of the structure.
(Historical note: All the field names start with st_ to disambiguate
them from user-defined symbols in early C, where MOS (members of structure)
were top-level symbol table entries and could be used with any type of
pointer).
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2018-11-27 16:00 +0000 |
| Message-ID | <pSdLD.412437$p%6.103429@fx26.am4> |
| In reply to | #138310 |
On 27/11/2018 15:29, David Brown wrote:
> On 27/11/18 15:45, Bart wrote:
>> On a modern PC just use int64 for everything, unless you know that int
>> (ie. usually int32) is adequate.
>>
>
> There you go with the worm's eye view. The world does not revolve
> around modern PC's. The C programming language is not all about modern
> PC's.
No?
C is used in helping write the OSes in desktop PCs. It is used to write
compilers, interpreters and other tools used on PCs. It figures heavily
in pretty much every library's API that I want to use on PCs. And, I
understand, it is still used in the underlying code used by the OSes of
smartphones and tablets.
Still, we have to keep C crippled just so it can still be used on some
4-bit microcontroller.
This is why a split in the language for those diverse applications has
been brought up a few times.
> But C is not that kind of language
It can be. Give it a makeover, and you won't be needing Go and Rust so much.
> The cost of adding these layers is virtually nothing.
Can't you see how pointless those are? If you can't directly use a raw
int type, then that's an argument for ONE layer of typedefs.
What about the other five? Are you really not that fussed about the
quality of such code? How many useless layers of abstract types do there
need to be before you express any sort of concern?
The benefits of
> avoiding disrupting existing code is almost priceless. Do you
> understand the concept of cost/benefit analysis?
So are the benefits of replacing a huge complex mess full of patches for
historical bugs with something new, smaller, simpler and snappier.
> The big difference is that there is no rot here.
That's not my view. If my own code starts looking like that, then I will
fix it.
People are not
> bothered by the definition of clock_t - it is an implementation detail,
> just like the definition of the clock() function.
Trying writing your own language that has to call clock() from the
nearest C library.
>> Which one conveys more information just from the given context?
>
> With meaningless type names like A, B, C, and meaningless field names,
> then neither gives much information. So it is a silly question.
Those names aren't meant to be meaningful. They are meant to convey the
fact that each member, whatever it happens to be in real code, has a
matching private type. If you want real names, try:
dev_t st_dev;
ino_t st_ino;
mode_t st_mode;
nlink_t st_nlink;
uid_t st_uid;
gid_t st_gid;
blksize_t st_blksize;
> If the type names were appropriate, then they would add more information
> - that much is obvious.
The have the same information as in the member name - see above. That
example is, frankly, ridiculous.
(And it was me who had to track down all those types to find out what
the hell they were.)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-11-27 23:40 +0100 |
| Message-ID | <ptkh5q$cge$1@dont-email.me> |
| In reply to | #138314 |
On 27/11/2018 17:00, Bart wrote: > On 27/11/2018 15:29, David Brown wrote: >> On 27/11/18 15:45, Bart wrote: > >>> On a modern PC just use int64 for everything, unless you know that int >>> (ie. usually int32) is adequate. >>> >> >> There you go with the worm's eye view. The world does not revolve >> around modern PC's. The C programming language is not all about modern >> PC's. > > No? > No. Software on modern PC's may revolve around C (at least if you dig deep enough), but C does not revolve around PC's. You've got your logic ass-backward. > C is used in helping write the OSes in desktop PCs. It is used to write > compilers, interpreters and other tools used on PCs. It figures heavily > in pretty much every library's API that I want to use on PCs. And, I > understand, it is still used in the underlying code used by the OSes of > smartphones and tablets. > > Still, we have to keep C crippled just so it can still be used on some > 4-bit microcontroller. > C is rarely used on 4-bit microcontrollers - they usually use Forth-like languages. You do like to exaggerate, but it does not help your argument. And C is not "kept crippled" for 8-bit microcontrollers and other small systems. It is simply flexible enough and efficient enough to be usable on such systems. > This is why a split in the language for those diverse applications has > been brought up a few times. > All sorts of suggestions get made at times. Personally, I would not be adverse to having a few "implementation classes" of C that impose certain restrictions on the implementation, and thereby give additional guarantees to the developer. For example, an implementation class of "common" might include the requirement that CHAR_BIT be 8, int be 32-bit, signed integers be two's complement representation (but /not/ in overflow behaviour - that would be undefined), and similarly a number of other implementation-defined behaviour would be fixed or restricted. Then people could write code that is "portable within the common class", with a meaningful and precise specification, rather than saying "portable to most modern cpus", which is vague and poorly specified. You would have the same integer types in each class. >> But C is not that kind of language > > It can be. Give it a makeover, and you won't be needing Go and Rust so > much. No, it can't be. Then it would not be C, it would be a different language. Go and Rust (and C++) are different languages made for different purposes, with different emphases - even though there is some overlap with C on suitability for particular types of programming. > >> The cost of adding these layers is virtually nothing. > > Can't you see how pointless those are? If you can't directly use a raw > int type, then that's an argument for ONE layer of typedefs. > Use as many layers as makes sense to the people writing the headers, libraries and code. I didn't write this code - I don't know why there are five layers here. I don't know if the reasons for all the layers are still valid, or if some were for historical reasons that are no longer needed. But I am very, very sure these were not added just to annoy people. I am also very, very sure that it does not matter in the slightest. > What about the other five? Are you really not that fussed about the > quality of such code? How many useless layers of abstract types do there > need to be before you express any sort of concern? > How do you know the layers are useless? All you know is that /you/ don't know the point of them. I don't know the point of them either - at least, not all the layers. But I don't assume that means there is no point. > The benefits of >> avoiding disrupting existing code is almost priceless. Do you >> understand the concept of cost/benefit analysis? > > So are the benefits of replacing a huge complex mess full of patches for > historical bugs with something new, smaller, simpler and snappier. > What bugs? There is no indication that this definition of clock_t causes anyone else any trouble - and it only causes /you/ trouble because you are determined to make it a problem. Smaller? Who cares about saving a few lines of code? Snappier? It makes no difference to the resulting code, and the difference to compilation speed will be too small to measure. If there really were a problem here, and there really were a way to change things without causing /real/ issues with /real/ existing code, then it would have been changed already. The maintainers of these headers and libraries are not idiots, or masochists - if there were benefits to be gained from changes that outweighed the risks and costs, then changes would be made. But as they are not idiots or masochists, they will not bother changing something that works perfectly well as it is. >> The big difference is that there is no rot here. > > That's not my view. If my own code starts looking like that, then I will > fix it. > > People are not >> bothered by the definition of clock_t - it is an implementation detail, >> just like the definition of the clock() function. > > Trying writing your own language that has to call clock() from the > nearest C library. > I don't care. Really, in the grand scheme of things, it does not matter. The effort it takes you here is utterly irrelevant compared to the risk of affecting all other code that uses clock(). That is partly because it is something you, as the author of the wrapper, needs to do just once. And is partly because it is /not/ hard - these things are only hard for you because you would rather have something to moan about than to use appropriate tools and language features. >>> Which one conveys more information just from the given context? >> >> With meaningless type names like A, B, C, and meaningless field names, >> then neither gives much information. So it is a silly question. > > Those names aren't meant to be meaningful. They are meant to convey the > fact that each member, whatever it happens to be in real code, has a > matching private type. If you want real names, try: > > dev_t st_dev; > ino_t st_ino; > mode_t st_mode; > nlink_t st_nlink; > uid_t st_uid; > gid_t st_gid; > blksize_t st_blksize; > That makes plenty of sense to me. The underlying types here have changed over time - uid_t used to be 16-bit, now it is 32-bit. And some, such as nlink_t, depend on whether you are using a 32-bit or 64-bit system, or x32 (which uses 64-bit mode on x86 systems, but with 32-bit pointers). There are lots of different combinations that have been used, and may still be used - far and away the easiest way to handle this is to use typedefs for each of these parts. (In the Linux kernel, there are about 30 such typedefs. That is not a lot, considering the number of system calls and different types of objects.) >> If the type names were appropriate, then they would add more information >> - that much is obvious. > > The have the same information as in the member name - see above. That > example is, frankly, ridiculous. > You simply don't understand the point. Perhaps, having read my paragraph above, you now have a better idea. > (And it was me who had to track down all those types to find out what > the hell they were.) > What? They are all clear enough in the Linux headers. And - I know this is going to annoy you - "tracking down" this information is typically a matter of holding your mouse pointer over an identifier in your code, if you are able to use appropriate development tools. Failing that, a few seconds with google should get you the answer. We are not living in the 1980's any more. You don't have to do everything in as manual and time-consuming way as possible.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2018-11-28 01:22 +0000 |
| Message-ID | <05mLD.656101$aw7.71699@fx04.am4> |
| In reply to | #138330 |
On 27/11/2018 22:40, David Brown wrote:
> On 27/11/2018 17:00, Bart wrote:
>> a matching private type. If you want real names, try:
>>
>> dev_t st_dev;
>> uid_t st_uid;
> That makes plenty of sense to me. The underlying types here have
> changed over time - uid_t used to be 16-bit, now it is 32-bit.
In how many places is a uid_t actually used? In most situations, you
just need an int type wide enough to contain a uid_t.
And unless the struct needs to exactly reflect a mandated layout, it's
not really needed there either.
If that st_uid field is int16 but later becomes int32, then you just
change it to int32. Why, in how many places is that width absolutely
critical?
> some, such as nlink_t, depend on whether you are using a 32-bit or
> 64-bit system, or x32 (which uses 64-bit mode on x86 systems, but with
> 32-bit pointers).
Well, so what? I must have declared many thousands of such variables,
parameters and fields over the years, probably tens of thousands.
If they need to increase from 16 to 32 bits, then they just do so.
Sometimes, the 'int' size itself will increase from 16 to 32 to 64 at
the same time as you switch platforms, so it's automatic.
It's only in C code, especially header code, that there seems to be an
absolute obsession with applying layers of typedefs to the most basic types.
As a good example, see my Original Post.
> What? They are all clear enough in the Linux headers. And - I know
> this is going to annoy you - "tracking down" this information is
> typically a matter of holding your mouse pointer over an identifier in
> your code, if you are able to use appropriate development tools.
So you can hold your mouse over the code fragment above, and it will
tell you what they are? Without any other context, that's impressive.
(If I google 'man uid_t' the first hit is a stackoverflow question, 'is
uid_t signed or unsigned?'. One answer is: 'after some typedefs/defines,
it's defined as a __U32_TYPE which is unsigned int on my system'.
So apparently some others are having problems too.
That __32_TYPE is very telling as well. This is the kind of crap we're
trying to eliminate.)
> Failing that, a few seconds with google should get you the answer.
You'd think that the headers for MY operating system on MY platform for
MY disk operating system would be a lot less cagey about the actual types.
(This is my version for 64-bit Windows; this system has
char/short/int/long/long long as 8/16/32/32/64, and uses C struct
alignment rules:
struct _stat {
unsigned int st_dev;
unsigned short st_ino;
unsigned short st_mode;
short st_nlink;
short st_uid;
short st_gid;
unsigned long st_rdev;
unsigned int st_size;
unsigned long long int st_atime;
unsigned long long int st_mtime;
unsigned long long int st_ctime;
};
Look Ma, no typedefs! The information I've provided above is enough,
even without wading through myriad header files, or getting your tool to
do the wading, to duplicate that layout in any language.)
> We are not living in the 1980's any more. You don't have to do
> everything in as manual and time-consuming way as possible.
Exactly, it's not the 1980s any more. But apparently that means
different things to different people.
To me it means throwing out all the old rubbish, to you it means keeping
all of it, but using new technology to help deal with it.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2018-11-28 15:57 +1300 |
| Message-ID | <g66ehgF8pfeU5@mid.individual.net> |
| In reply to | #138332 |
On 28/11/2018 14:22, Bart wrote: > On 27/11/2018 22:40, David Brown wrote: >> On 27/11/2018 17:00, Bart wrote: > >>> a matching private type. If you want real names, try: >>> >>> dev_t st_dev; >>> uid_t st_uid; > >> That makes plenty of sense to me. The underlying types here have >> changed over time - uid_t used to be 16-bit, now it is 32-bit. > > In how many places is a uid_t actually used? In most situations, you > just need an int type wide enough to contain a uid_t. If you happen to be a system programmer on a POSIX platform, quite often. If you don't you probably don't care. > And unless the struct needs to exactly reflect a mandated layout, it's > not really needed there either. There as a time when RAM was expensive and wasted space in structures was frowned upon. > If that st_uid field is int16 but later becomes int32, then you just > change it to int32. Why, in how many places is that width absolutely > critical? Well it might be 16 bit on some systems. -- Ian.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-11-28 08:29 +0100 |
| Message-ID | <ptlg4l$pcf$1@dont-email.me> |
| In reply to | #138332 |
On 28/11/2018 02:22, Bart wrote:
> On 27/11/2018 22:40, David Brown wrote:
>> On 27/11/2018 17:00, Bart wrote:
>
>>> a matching private type. If you want real names, try:
>>>
>>> dev_t st_dev;
>>> uid_t st_uid;
>
>> That makes plenty of sense to me. The underlying types here have
>> changed over time - uid_t used to be 16-bit, now it is 32-bit.
>
> In how many places is a uid_t actually used? In most situations, you
> just need an int type wide enough to contain a uid_t.
>
I don't do the kind of programming where you would use these types, so I
can't tell you how much they are needed. But I can tell you they are
often used in structs, and you'd better get the type size /right/ or the
struct layout will be wrong.
> And unless the struct needs to exactly reflect a mandated layout, it's
> not really needed there either.
>
The vital part is that it has a /consistent/ layout. So it is not the
exact layout that matters - details of that will change with, for
example, the sizes of types like uid_t. But it is critical that all the
code in the same system that passes these structs around, all uses the
same layout. It is not going to go down well if the kernel uses one
size for the layout of its structs, and your code uses a different size
because you don't like using named types and prefer to guess.
> If that st_uid field is int16 but later becomes int32, then you just
> change it to int32. Why, in how many places is that width absolutely
> critical?
Type "uid_t" turns up in 76 files in the Linux kernel tree (according to
a search with <https://elixir.bootlin.com/linux/latest/ident/uid_t>.)
Sure, when the kernel moved from 16-bit uid's to 32-bit uid's, it would
be possible to change them all - the count would have been lower in
those days. But how many /applications/ use it? There are a great many
of them (all the low-level utilities, for example). These would all
need to be changed. The amount of work involved would be enormous.
And for what gain? So that you can write "int32_t" instead of "uid_t" ?
>
>> some, such as nlink_t, depend on whether you are using a 32-bit or
>> 64-bit system, or x32 (which uses 64-bit mode on x86 systems, but with
>> 32-bit pointers).
>
> Well, so what? I must have declared many thousands of such variables,
> parameters and fields over the years, probably tens of thousands.
>
> If they need to increase from 16 to 32 bits, then they just do so.
> Sometimes, the 'int' size itself will increase from 16 to 32 to 64 at
> the same time as you switch platforms, so it's automatic.
>
> It's only in C code, especially header code, that there seems to be an
> absolute obsession with applying layers of typedefs to the most basic
> types.
No one has an "obsession" about having layers of typedefs. People try
to write clear, maintainable and portable code - and that means
abstracting such types. This is neither rocket science nor an obsession.
>
> As a good example, see my Original Post.
>
>> What? They are all clear enough in the Linux headers. And - I know
>> this is going to annoy you - "tracking down" this information is
>> typically a matter of holding your mouse pointer over an identifier in
>> your code, if you are able to use appropriate development tools.
>
> So you can hold your mouse over the code fragment above, and it will
> tell you what they are? Without any other context, that's impressive.
>
You need the right headers in your code, obviously. But yes, modern
IDE's /are/ impressive tools.
> (If I google 'man uid_t' the first hit is a stackoverflow question, 'is
> uid_t signed or unsigned?'. One answer is: 'after some typedefs/defines,
> it's defined as a __U32_TYPE which is unsigned int on my system'.
>
> So apparently some others are having problems too.
All you can see from that is that others are curious, or want to know -
there is a vast gulf between "I want to know this" and "This is causing
me problems".
And it shows you that if you do want to know the answer here, it's a few
seconds away - not the huge detective operation that you seem to need
for every pointless question you can imagine.
>
> That __32_TYPE is very telling as well. This is the kind of crap we're
> trying to eliminate.)
It is not "crap", and no "we" are not trying to eliminate it.
>
>> Failing that, a few seconds with google should get you the answer.
>
> You'd think that the headers for MY operating system on MY platform for
> MY disk operating system would be a lot less cagey about the actual types.
>
> (This is my version for 64-bit Windows; this system has
> char/short/int/long/long long as 8/16/32/32/64, and uses C struct
> alignment rules:
>
> struct _stat {
> unsigned int st_dev;
> unsigned short st_ino;
> unsigned short st_mode;
> short st_nlink;
> short st_uid;
> short st_gid;
> unsigned long st_rdev;
> unsigned int st_size;
> unsigned long long int st_atime;
> unsigned long long int st_mtime;
> unsigned long long int st_ctime;
> };
>
> Look Ma, no typedefs!
And that is why no one would let you near serious code.
> The information I've provided above is enough,
> even without wading through myriad header files, or getting your tool to
> do the wading, to duplicate that layout in any language.)
>
>> We are not living in the 1980's any more. You don't have to do
>> everything in as manual and time-consuming way as possible.
>
> Exactly, it's not the 1980s any more. But apparently that means
> different things to different people.
>
> To me it means throwing out all the old rubbish, to you it means keeping
> all of it, but using new technology to help deal with it.
>
You don't throw out old stuff that is working and useful. You /do/
throw out old stuff that is no longer useful because it has been
completely replaced.
Much of the code base in the software world is still perfectly good,
partly because it was written by people who understood about
maintainability and portability, and appropriately used language
features like "typedef", macros and conditional compilation (your
favourite three parts of C).
On the other hand, the development tools and methodologies you use from
the dark ages have been replaced long ago, and anyone serious about
programming uses decent, modern tools. (Or emacs :-) ).
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2018-11-28 11:38 +0000 |
| Message-ID | <y6vLD.301445$5A2.62978@fx25.am4> |
| In reply to | #138341 |
On 28/11/2018 07:29, David Brown wrote:
> On 28/11/2018 02:22, Bart wrote:
>> That __32_TYPE is very telling as well. This is the kind of crap we're
>> trying to eliminate.)
>
> It is not "crap", and no "we" are not trying to eliminate it.
It IS crap. Why on earth the need to introduce YET ANOTHER INTEGER TYPE
I've never heard of? It's apparently unsigned, and presumably 32 bits
wide. So what's wrong with using one of the many dozens of integer types
already stipulated by the Standard?
This demonstrates the point I made, that despite uint32_t and all the
rest being introduced, no one bothers to use it! And uint32_t has been
around for 20 years.
As to why you /don't/ want to eliminate it: if you had that in your own
code base and you realised it was no longer needed (or it never was
needed) would you keep it in?
C appears to have a significant problem with its primitive types.
>> Look Ma, no typedefs!
>
> And that is why no one would let you near serious code.
Why not? Is a struct definition no good unless the type of every member
is a typedef?
> On the other hand, the development tools and methodologies you use from
> the dark ages have been replaced long ago, and anyone serious about
> programming uses decent, modern tools. (Or emacs :-) ).
I'm not the one using a language unchanged for coming up to half a
century, and where practically every program makes up its own aliases
for basic types.
The language I use in place of C has been modernised, and acknowledges
the fact that every target of interest is likely to be 64 bits. It uses
a consistently named and exact-sized set of integer types.
Its 'int' type is an alias for int64. Not like C where 'int64_t' is
likely an alias for either long or long long, neither of which have a
precisely defined width! It seems to have got that bit back to front.
M C
64-bit signed int int64 long int (Linux)
long long int (Win)
int64_t [1]
64-bit zero literal 0 0L (Linux)
0LL (Windows)
INT64_C(0) [1]
print 64-bit 'a' print a print("%ld",a) (Linux)
print("%lld",a) (Win)
print("%I64d",a) (MS)
print(PRI64 a) [2]
read 64-bit 'a' read a scanf("%ld",&a) (Linux)
scanf("%lld",&a) (Win)
scanf(SCNd64,&a) [1,3]
[1] requires stdint.h
[2] requires inttypes.h
[3] or some such code
Remind me, who's the one using stuff from the dark ages again?
[toc] | [prev] | [next] | [standalone]
| From | Anton Shepelev <anton.txt@g{oogle}mail.com> |
|---|---|
| Date | 2018-11-28 16:02 +0300 |
| Message-ID | <20181128160255.a809bcf108a209e14cfc8f91@g{oogle}mail.com> |
| In reply to | #138347 |
Bart:
>Its 'int' type is an alias for int64. Not like C where
>'int64_t' is likely an alias for either long or long long,
>neither of which have a precisely defined width! It seems
>to have got that bit back to front.
I was convinced during the prevous discussion of this
subject that native (platform-dependent) numeric types are a
logical basis of a type system for a language desinged to
work on many platforms. When compiled on different
platforms, a program will have different capabilies, such as
being able to process either 2^16 or 2^32 reocords, but the
developer can be certain that it uses the reasonably fast
native types, for which machine code instruction are
available, rather a slow emulation of of a non-native type.
> M C
>print 64-bit 'a' print a print("%ld",a) (Linux)
> print("%lld",a) (Win)
> print("%I64d",a) (MS)
> print(PRI64 a) [2]
>
>read 64-bit 'a' read a scanf("%ld",&a) (Linux)
> scanf("%lld",&a) (Win)
> scanf(SCNd64,&a) [1,3]
Does your language have function overloading? Comparison
with printf/scan is not fair because the latter functions
are more flexible.
--
() ascii ribbon campaign - against html e-mail
/\ http://preview.tinyurl.com/qcy6mjc [archived]
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2018-11-28 13:35 +0000 |
| Message-ID | <%QwLD.536311$Tt4.18167@fx12.am4> |
| In reply to | #138353 |
On 28/11/2018 13:02, Anton Shepelev wrote:
> Bart:
>
>> Its 'int' type is an alias for int64. Not like C where
>> 'int64_t' is likely an alias for either long or long long,
>> neither of which have a precisely defined width! It seems
>> to have got that bit back to front.
>
> I was convinced during the prevous discussion of this
> subject that native (platform-dependent) numeric types are a
> logical basis of a type system for a language desinged to
> work on many platforms. When compiled on different
> platforms, a program will have different capabilies, such as
> being able to process either 2^16 or 2^32 reocords, but the
> developer can be certain that it uses the reasonably fast
> native types, for which machine code instruction are
> available, rather a slow emulation of of a non-native type.
This is where using an open 'int' type comes into play, that can be
chosen to be one or another specific size. But other languages now will
define int on top of a fixed-size type.
However, I found that most targets that are not embedded microprocessors
now tend to have 64-bit cores. Concentrating on those offers the
opportunity to greatly simplify type systems.
>> print 64-bit 'a' print a print("%ld",a) (Linux)
>> read 64-bit 'a' read a scanf("%ld",&a) (Linux)
> Does your language have function overloading?
No. ('print' and 'read' are statements that translate to sequences of
function calls; see sig for example.)
> Comparison
> with printf/scan is not fair because the latter functions
> are more flexible.
Not really. The scanf family can do some pattern-matching, but many find
it hard to use. When you just want to do a simple read, you still need
to use scanf, or somehow capture the input before applying atoi etc.
If I need to use those features, then nothing stops me calling scanf,
sprintf etc as foreign functions. However C can't use my print or read
statements.
So my language has the choice of 'print a' or 'printf("%lld",a)', C
doesn't. (Further, I can use "%lld" more confidently than in C, where an
'int64_t' operand used with "%lld" causes compile warnings on Linux.)
--
bart
Source code:
int a
read a
print a
Generated native code (the 0s being pushed are null pointers to format
option, not used here in the source; the read function takes input from
a current line buffer):
push 0
call msys.m$read_i64
mov [Dframe-8], D0
call msys.m$print_startcon
push 0
push word64 [Dframe-8]
call msys.m$print_i64
call msys.m$print_end
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2018-11-28 08:14 -0600 |
| Message-ID | <qd8tvdtg4rfec9lq77bd5513b47hskpucc@4ax.com> |
| In reply to | #138353 |
On Wed, 28 Nov 2018 16:02:55 +0300, Anton Shepelev
<anton.txt@g{oogle}mail.com> wrote:
>Bart:
>
>>Its 'int' type is an alias for int64. Not like C where
>>'int64_t' is likely an alias for either long or long long,
>>neither of which have a precisely defined width! It seems
>>to have got that bit back to front.
>
>I was convinced during the prevous discussion of this
>subject that native (platform-dependent) numeric types are a
>logical basis of a type system for a language desinged to
>work on many platforms. When compiled on different
>platforms, a program will have different capabilies, such as
>being able to process either 2^16 or 2^32 reocords, but the
>developer can be certain that it uses the reasonably fast
>native types, for which machine code instruction are
>available, rather a slow emulation of of a non-native type.
The case could be made that such machine dependent types would be
better done with int_fast*_t style typedefs via a platform dependent
stdint.h, and have the basic types be fixed sizes.
Of course that language would hardly be C.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2018-11-28 13:33 +0000 |
| Message-ID | <87h8g1pbs7.fsf@bsb.me.uk> |
| In reply to | #138347 |
Bart <bc@freeuk.com> writes:
> Not like C where 'int64_t' is likely an alias for either long or long
> long, neither of which have a precisely defined width!
That wording is going to confuse some people. int64_t is guaranteed to
be a 64-bit integer type (with no padding bits and that uses 2's
complement for negative values). It will and alias for either long or
long long only when that guarantee can be met.
> M C
>
> 64-bit signed int int64 long int (Linux)
> long long int (Win)
> int64_t [1]
>
> 64-bit zero literal 0 0L (Linux)
> 0LL (Windows)
> INT64_C(0) [1]
>
> print 64-bit 'a' print a print("%ld",a) (Linux)
> print("%lld",a) (Win)
> print("%I64d",a) (MS)
> print(PRI64 a) [2]
>
> read 64-bit 'a' read a scanf("%ld",&a) (Linux)
> scanf("%lld",&a) (Win)
> scanf(SCNd64,&a) [1,3]
Readers who want to learn C should note that this is, again, misleading
(at best). Not only is "print("%ld",a) (Linux)" wrong in at least three
ways (which I know you are not interested in), the table also avoids
discussing the advantages of C.
The reader (at least this reader) is left wondering how a 32- or 16-bit
zero literal is written in M, how you might write, say, an unsigned
32-bit integer as hex in M, and how M reports input errors.
--
Ben.
[toc] | [prev] | [next] | [standalone]
Page 4 of 9 — ← Prev page 1 2 3 [4] 5 6 7 8 9 Next page →
Back to top | Article view | comp.lang.c
csiph-web