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 3 of 9 — ← Prev page 1 2 [3] 4 5 6 7 8 9 Next page →
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2018-11-28 02:44 -0800 |
| Message-ID | <a2afe95d-cdb2-4611-bb1b-3dc6d16c929f@googlegroups.com> |
| In reply to | #138336 |
On Wednesday, November 28, 2018 at 2:42:24 AM UTC, Ian Collins wrote: > On 28/11/2018 09:35, Bart wrote: > > > > But many do do so, and some end up creating new languages where the > > number of types, and their organisation /has/ been simplified compared > > with C. Which is puzzling if the claim that the more the better is to be > > believed. > > Most of what you go on to list are mainly the same as C minus the type > aliases. A good number of C's type aliases are aids to portability > which is not many languages have to worry too much about. > Type aliasing is inherently bad, because it leads to this problem A low-level vector graphics library declares struct point2. A low level drawing package declares struct Point2 Now we want to calculate some shapes with the vector graphics library and display them with the drawing package. So what happens? Our code is littered with conversions which are binary no-ops. Lots of type aliases for integer types is a similar issue. It gets serious when you have to pass arrays of integers. However, yes, it does allow for a fast 16 bit type to be 32 bits on platforms where that is an issue. My argument would be that if you have to worry about micro-optimisation to that extent, you probably know the platform you are targeting anyway.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2018-11-28 23:52 +1300 |
| Message-ID | <g67aasF8pfeU8@mid.individual.net> |
| In reply to | #138344 |
On 28/11/2018 23:44, Malcolm McLean wrote: > On Wednesday, November 28, 2018 at 2:42:24 AM UTC, Ian Collins wrote: >> On 28/11/2018 09:35, Bart wrote: >>> >>> But many do do so, and some end up creating new languages where the >>> number of types, and their organisation /has/ been simplified compared >>> with C. Which is puzzling if the claim that the more the better is to be >>> believed. >> >> Most of what you go on to list are mainly the same as C minus the type >> aliases. A good number of C's type aliases are aids to portability >> which is not many languages have to worry too much about. >> > Type aliasing is inherently bad, because it leads to this problem > > A low-level vector graphics library declares struct point2. > A low level drawing package declares struct Point2 > > Now we want to calculate some shapes with the vector graphics library > and display them with the drawing package. So what happens? Our code > is littered with conversions which are binary no-ops. > > Lots of type aliases for integer types is a similar issue. It gets > serious when you have to pass arrays of integers. > > However, yes, it does allow for a fast 16 bit type to be 32 bits on > platforms where that is an issue. My argument would be that if you > have to worry about micro-optimisation to that extent, you probably > know the platform you are targeting anyway. Is size_t a micro-optimisation? ptrdiff_t? Or any other type who's size depends on the target? -- Ian.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2018-11-28 03:42 -0800 |
| Message-ID | <14d7f3a9-d6b5-4618-b4e0-3898deda1f0f@googlegroups.com> |
| In reply to | #138345 |
On Wednesday, November 28, 2018 at 10:52:22 AM UTC, Ian Collins wrote: > On 28/11/2018 23:44, Malcolm McLean wrote: > > On Wednesday, November 28, 2018 at 2:42:24 AM UTC, Ian Collins wrote: > >> On 28/11/2018 09:35, Bart wrote: > >>> > >>> But many do do so, and some end up creating new languages where the > >>> number of types, and their organisation /has/ been simplified compared > >>> with C. Which is puzzling if the claim that the more the better is to be > >>> believed. > >> > >> Most of what you go on to list are mainly the same as C minus the type > >> aliases. A good number of C's type aliases are aids to portability > >> which is not many languages have to worry too much about. > >> > > Type aliasing is inherently bad, because it leads to this problem > > > > A low-level vector graphics library declares struct point2. > > A low level drawing package declares struct Point2 > > > > Now we want to calculate some shapes with the vector graphics library > > and display them with the drawing package. So what happens? Our code > > is littered with conversions which are binary no-ops. > > > > Lots of type aliases for integer types is a similar issue. It gets > > serious when you have to pass arrays of integers. > > > > However, yes, it does allow for a fast 16 bit type to be 32 bits on > > platforms where that is an issue. My argument would be that if you > > have to worry about micro-optimisation to that extent, you probably > > know the platform you are targeting anyway. > > Is size_t a micro-optimisation? ptrdiff_t? Or any other type who's size > depends on the target? > No it's not. The micro-optimisation is to use "int" as a general purpose array index. In a higher-level language, you'd only have one integer type, and it would have to be large enough to index any array. That's size_t / ptrdiff_t in C terms.
[toc] | [prev] | [next] | [standalone]
| From | Anton Shepelev <anton.txt@g{oogle}mail.com> |
|---|---|
| Date | 2018-11-28 15:48 +0300 |
| Message-ID | <20181128154828.4943695f58b13b35fe9688ab@g{oogle}mail.com> |
| In reply to | #138344 |
Malcolm McLean: >Type aliasing is inherently bad, because it leads to this >problem > >A low-level vector graphics library declares struct point2. >A low level drawing package declares struct Point2 > >Now we want to calculate some shapes with the vector >graphics library and display them with the drawing package. >So what happens? Our code is littered with conversions >which are binary no-ops. Is not it mere luck that `point2' and `Point2' can alias? Do not you have to convert between them properly in general case or to make reliable code that won't break if, for example, the .x and .y fields in one of the structures are swapped? -- () ascii ribbon campaign - against html e-mail /\ http://preview.tinyurl.com/qcy6mjc [archived]
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2018-11-28 05:24 -0800 |
| Message-ID | <e1dde9c0-0d99-49a9-8dbc-2ae287d512ec@googlegroups.com> |
| In reply to | #138351 |
On Wednesday, November 28, 2018 at 12:48:37 PM UTC, Anton Shepelev wrote: > Malcolm McLean: > > >Type aliasing is inherently bad, because it leads to this > >problem > > > >A low-level vector graphics library declares struct point2. > >A low level drawing package declares struct Point2 > > > >Now we want to calculate some shapes with the vector > >graphics library and display them with the drawing package. > >So what happens? Our code is littered with conversions > >which are binary no-ops. > > Is not it mere luck that `point2' and `Point2' can alias? > Do not you have to convert between them properly in general > case or to make reliable code that won't break if, for > example, the .x and .y fields in one of the structures are > swapped? > Not really. There's a strong convention that x precedes y, and x is the horizontal axis going from left to right. However the example was to illustrate the problem with type aliasing. You get the same problem if an audio buffer is declared as short * in one place and int16_t * in another. The introduction of int16_t alleviates the problem that short might not be 16 bits, but it creates another potential problem. Then if short is 32 bits, usually the audio code will still work, it will just waste 50% of memory. That's probably better than not working at all (int16_t unavailable).
[toc] | [prev] | [next] | [standalone]
| From | Anton Shepelev <anton.txt@g{oogle}mail.com> |
|---|---|
| Date | 2018-11-28 17:30 +0300 |
| Message-ID | <20181128173021.757481d342a885233afb98c7@g{oogle}mail.com> |
| In reply to | #138355 |
Malcolm McLean: A low-level vector graphics library declares struct point2. A low level drawing package declares struct Point2 Now we want to calculate some shapes with the vector graphics library and display them with the drawing package. So what happens? Our code is littered with conversions which are binary no-ops. Lots of type aliases for integer types is a similar issue. It gets serious when you have to pass arrays of integers. Anton Shepelev: Is not it mere luck that `point2' and `Point2' can alias? Do not you have to convert between them properly in general case or to make reliable code that won't break if, for example, the .x and .y fields in one of the structures are swapped? Malcolm McLean: Not really. There's a strong convention that x precedes y, and x is the horizontal axis going from left to right. However the example was to illustrate the problem with type aliasing. Even so, does not such access violate the rules of strict aliasing? The two structs are still different types... >You get the same problem if an audio buffer is declared as >short * in one place and int16_t * in another. The >introduction of int16_t alleviates the problem that short >might not be 16 bits, but it creates another potential >problem. Then if short is 32 bits, usually the audio code >will still work, it will just waste 50% of memory. That's >probably better than not working at all (int16_t >unavailable). It depends on bit depth. Some high-resolution processing may use float. Is it possible to use a char buffer? -- () ascii ribbon campaign - against html e-mail /\ http://preview.tinyurl.com/qcy6mjc [archived]
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-11-28 13:59 +0100 |
| Message-ID | <ptm3f3$59q$1@dont-email.me> |
| In reply to | #138344 |
On 28/11/18 11:44, Malcolm McLean wrote: > On Wednesday, November 28, 2018 at 2:42:24 AM UTC, Ian Collins wrote: >> On 28/11/2018 09:35, Bart wrote: >>> >>> But many do do so, and some end up creating new languages where the >>> number of types, and their organisation /has/ been simplified compared >>> with C. Which is puzzling if the claim that the more the better is to be >>> believed. >> >> Most of what you go on to list are mainly the same as C minus the type >> aliases. A good number of C's type aliases are aids to portability >> which is not many languages have to worry too much about. >> > Type aliasing is inherently bad, because it leads to this problem Even if what you write below were true, and that this is a problem, that would not mean that type aliasing is "inherently bad". It would mean that type aliasing is not cost-free. And thus you have to balance the benefits to the costs when considering it - just like any other feature. You could just as well say that functions are inherently bad, because of the overhead of function calls and returns. It would be equally meaningless. > > A low-level vector graphics library declares struct point2. > A low level drawing package declares struct Point2 > If you have two modules in the same system, with the same identifier but different details, then you certainly have a problem (or at least a challenge). It does not matter whether these are types, function names, variables, or anything else - this situation is not remotely related to typedef aliases. Solutions include prefixing identifiers (like "vg_point2" for the vector graphics point2 struct), and being careful to keep identifiers static whenever possible. (Moving to C++ with namespaces is another choice - it would be great if C adopted them.) > Now we want to calculate some shapes with the vector graphics library > and display them with the drawing package. So what happens? Our code > is littered with conversions which are binary no-ops. > Conversions which are binary no-ops are zero cost at run-time, and not a problem there. You can argue that they are a cost in the source code, in that you need to add them in the right place even though they ultimately have no effect on the generated object code. You can equally argue that they are a benefit in the source code, because they can make the purpose of code clearer, and perhaps provide extra checking. (This would be better with strong types rather than just aliases.) > Lots of type aliases for integer types is a similar issue. It gets > serious when you have to pass arrays of integers. Pass arrays of the types you want. > > However, yes, it does allow for a fast 16 bit type to be 32 bits on > platforms where that is an issue. My argument would be that if you > have to worry about micro-optimisation to that extent, you probably > know the platform you are targeting anyway. > Multiple integer types gives you the flexibility to balance things like ranges and cache efficiency. Abstract type aliases give you the flexibility to modify and adapt along the way, without re-writing half your code.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2018-11-28 05:33 -0800 |
| Message-ID | <09786842-2b57-43dd-9275-351189eb3562@googlegroups.com> |
| In reply to | #138352 |
On Wednesday, November 28, 2018 at 12:59:24 PM UTC, David Brown wrote: > > Multiple integer types gives you the flexibility to balance things like > ranges and cache efficiency. Abstract type aliases give you the > flexibility to modify and adapt along the way, without re-writing half > your code. > Ok, lets get this clear. I am not arguing against having types for all the integer types supported by the machine, even though personally I would be happier if C had just two integer types, "byte" and "index_t", index_t being large enough to access any array in the program. But if you're balancing rages against cache efficiency, you must have a pretty good idea of what hardware you are running on. So use the 16 bit type if a small integer is more efficient, the 32 bit type if the large integer type is more efficient or gives you a more acceptable safety margin.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2018-11-28 14:31 +0000 |
| Message-ID | <KExLD.733269$Ac3.657141@fx45.iad> |
| In reply to | #138357 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: >On Wednesday, November 28, 2018 at 12:59:24 PM UTC, David Brown wrote: >> >> Multiple integer types gives you the flexibility to balance things like >> ranges and cache efficiency. Abstract type aliases give you the >> flexibility to modify and adapt along the way, without re-writing half >> your code. >> >Ok, lets get this clear. I am not arguing against having types for all >the integer types supported by the machine, even though personally I >would be happier if C had just two integer types, "byte" and "index_t", >index_t being large enough to access any array in the program. It's never going to happen, so all your bitching is pointless trolling.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-11-28 23:19 +0100 |
| Message-ID | <ptn4a6$jn9$1@dont-email.me> |
| In reply to | #138357 |
On 28/11/2018 14:33, Malcolm McLean wrote: > On Wednesday, November 28, 2018 at 12:59:24 PM UTC, David Brown wrote: >> >> Multiple integer types gives you the flexibility to balance things like >> ranges and cache efficiency. Abstract type aliases give you the >> flexibility to modify and adapt along the way, without re-writing half >> your code. >> > Ok, lets get this clear. I am not arguing against having types for all > the integer types supported by the machine, even though personally I > would be happier if C had just two integer types, "byte" and "index_t", > index_t being large enough to access any array in the program. > > But if you're balancing rages against cache efficiency, you must have > a pretty good idea of what hardware you are running on. So use the > 16 bit type if a small integer is more efficient, the 32 bit type > if the large integer type is more efficient or gives you a more > acceptable safety margin. > You don't need to know anything about the hardware to know that an array of data is going to be more efficient on the cache and memory if the elements are smaller.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2018-11-29 01:35 -0800 |
| Message-ID | <556f8456-d9e4-44d7-9e08-a909117de43c@googlegroups.com> |
| In reply to | #138383 |
On Wednesday, November 28, 2018 at 10:19:57 PM UTC, David Brown wrote: > On 28/11/2018 14:33, Malcolm McLean wrote: > > On Wednesday, November 28, 2018 at 12:59:24 PM UTC, David Brown wrote: > >> > >> Multiple integer types gives you the flexibility to balance things like > >> ranges and cache efficiency. Abstract type aliases give you the > >> flexibility to modify and adapt along the way, without re-writing half > >> your code. > >> > > Ok, lets get this clear. I am not arguing against having types for all > > the integer types supported by the machine, even though personally I > > would be happier if C had just two integer types, "byte" and "index_t", > > index_t being large enough to access any array in the program. > > > > But if you're balancing rages against cache efficiency, you must have > > a pretty good idea of what hardware you are running on. So use the > > 16 bit type if a small integer is more efficient, the 32 bit type > > if the large integer type is more efficient or gives you a more > > acceptable safety margin. > > > > You don't need to know anything about the hardware to know that an array > of data is going to be more efficient on the cache and memory if the > elements are smaller. > Actually you do, because a 16-bit access might have to be faked up on top of 32 bit words. You'd still have better cache usage, but that might not compensate.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-11-29 13:25 +0100 |
| Message-ID | <ptols1$t8u$1@dont-email.me> |
| In reply to | #138389 |
On 29/11/18 10:35, Malcolm McLean wrote: > On Wednesday, November 28, 2018 at 10:19:57 PM UTC, David Brown wrote: >> On 28/11/2018 14:33, Malcolm McLean wrote: >>> On Wednesday, November 28, 2018 at 12:59:24 PM UTC, David Brown wrote: >>>> >>>> Multiple integer types gives you the flexibility to balance things like >>>> ranges and cache efficiency. Abstract type aliases give you the >>>> flexibility to modify and adapt along the way, without re-writing half >>>> your code. >>>> >>> Ok, lets get this clear. I am not arguing against having types for all >>> the integer types supported by the machine, even though personally I >>> would be happier if C had just two integer types, "byte" and "index_t", >>> index_t being large enough to access any array in the program. >>> >>> But if you're balancing rages against cache efficiency, you must have >>> a pretty good idea of what hardware you are running on. So use the >>> 16 bit type if a small integer is more efficient, the 32 bit type >>> if the large integer type is more efficient or gives you a more >>> acceptable safety margin. >>> >> >> You don't need to know anything about the hardware to know that an array >> of data is going to be more efficient on the cache and memory if the >> elements are smaller. >> > Actually you do, because a 16-bit access might have to be faked up > on top of 32 bit words. You'd still have better cache usage, but that > might not compensate. > There have been a few chips where writing to a size smaller than the register width is done with a read-modify-write cycle. This applied to some early ARM designs, and the first DEC Alpha chip. Practice quickly showed this was a terrible idea, and all other chips let you write 8-bit, 16-bit, etc., directly (all steps between char and the longest supported by their registers).
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2018-11-28 14:28 +0000 |
| Message-ID | <KCxLD.733268$Ac3.459370@fx45.iad> |
| In reply to | #138344 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: >On Wednesday, November 28, 2018 at 2:42:24 AM UTC, Ian Collins wrote: >> On 28/11/2018 09:35, Bart wrote: >> > >> > But many do do so, and some end up creating new languages where the >> > number of types, and their organisation /has/ been simplified compared >> > with C. Which is puzzling if the claim that the more the better is to be >> > believed. >> >> Most of what you go on to list are mainly the same as C minus the type >> aliases. A good number of C's type aliases are aids to portability >> which is not many languages have to worry too much about. >> >Type aliasing is inherently bad, because it leads to this problem > >A low-level vector graphics library declares struct point2. >A low level drawing package declares struct Point2 Wow! How does anyone write programs in C? It's such a terrible language.
[toc] | [prev] | [next] | [standalone]
| From | Anton Shepelev <anton.txt@g{oogle}mail.com> |
|---|---|
| Date | 2018-11-28 17:33 +0300 |
| Message-ID | <20181128173346.e42330d5cc417b9d556f40ac@g{oogle}mail.com> |
| In reply to | #138364 |
Scott Lurndal to Malcolm McLean: >>A low-level vector graphics library declares struct point2. >>A low level drawing package declares struct Point2 > >Wow! How does anyone write programs in C? It's such a >terrible language. It is the general problem of interface matching, not specific to C. Is it absent from any language? -- () ascii ribbon campaign - against html e-mail /\ http://preview.tinyurl.com/qcy6mjc [archived]
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2018-11-28 06:56 -0800 |
| Message-ID | <1a4f5dac-8004-41f3-8717-063a372a49e1@googlegroups.com> |
| In reply to | #138367 |
On Wednesday, November 28, 2018 at 2:33:54 PM UTC, Anton Shepelev wrote: > Scott Lurndal to Malcolm McLean: > > >>A low-level vector graphics library declares struct point2. > >>A low level drawing package declares struct Point2 > > > >Wow! How does anyone write programs in C? It's such a > >terrible language. > > It is the general problem of interface matching, not > specific to C. Is it absent from any language? > Exactly. But if you've only got one type for an integer, then at least all the integer arguments will match.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2018-11-28 11:53 +0000 |
| Message-ID | <MkvLD.830830$NF7.355462@fx14.am4> |
| In reply to | #138326 |
On 27/11/2018 20:35, Bart wrote: > Go: Missing here is a line of float32/64. (Since the post emphasises the excessive variations of C types, it has to be fair!) > M (mine [128-bit types added]): > > int8/16/32/64/128 > word8/16/32/64/128 > real32/64/128 > (aliases: int=int64, word=word64, real=real64, byte=char=word8) Missing here is a line of aliases for int/word types that depend on the target. Although these can be reduced or eliminated if I can find an alternate solution. (At one time the width part of the type name was a Fortran-style attribute applied to a base type, so that might be another way of doing things.)
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2018-11-28 12:09 +0000 |
| Message-ID | <aAvLD.129975$lKb.124075@fx15.am4> |
| In reply to | #138349 |
On 28/11/2018 11:53, Bart wrote: > On 27/11/2018 20:35, Bart wrote: > >> Go: > > Missing here is a line of float32/64. (Since the post emphasises the > excessive variations of C types, it has to be fair!) > >> M (mine): > Missing here is a line of aliases for int/word types that depend on the Ignore this last post. I've just realised that my list of C types covers integer types only, not floating point! So if anything I was favouring C more than the others.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2018-11-28 01:26 -0800 |
| Message-ID | <843ab436-05a2-4421-923d-d55d97043832@googlegroups.com> |
| In reply to | #138320 |
On Tuesday, November 27, 2018 at 5:48:19 PM UTC, Scott Lurndal wrote: > Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > >On Tuesday, November 27, 2018 at 5:11:30 PM UTC, Scott Lurndal wrote: > >> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > >> >On Tuesday, November 27, 2018 at 3:55:49 PM UTC, David Brown wrote: > >> > >> >> 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? > >> >>=20 > >> >Two out of five programmers contributing to this thread think that > >> >the proliferation of integer types is a problem. > >> > >> Seriously? Do you have any understanding of statistics, confidence > >> intervals and margins of error? > >> > >If you've got only one example, then that doesn't tell you much, it could > >be an outlier. But if you've got two out of a sample of five, then it's > >much less likely that the number is negligible. Of course whilst 40% > >is your best estimate, it could be very much wrong in either direction. > > That "sample of five" is not a random sample, in fact it's basically > self-selected, and any conclusion drawn from it is prima facia invalid. > NO, the point is that you've got a small sample, and two positives. Which tells you that the positives are unlikely to be vanishingly rare. But you're the one who brought up statistics. > > You'll likely find, that of the population of C programmers, 99% don't > give a shit and of the rest, an insignificant percentage believe as > you and Bart do - you must admit the two of you are particular outliers > here. > That's just a guess. I've heard other complaints about the number of integer types in C, but it's not a subject that comes up very often. At the end of the day, there are worse problems with C.
[toc] | [prev] | [next] | [standalone]
| From | mark.bluemel@gmail.com |
|---|---|
| Date | 2018-11-28 02:57 -0800 |
| Message-ID | <431c9b32-76c1-4019-a7e1-22ed0c38373e@googlegroups.com> |
| In reply to | #138343 |
On Wednesday, 28 November 2018 09:26:50 UTC, Malcolm McLean wrote: > On Tuesday, November 27, 2018 at 5:48:19 PM UTC, Scott Lurndal wrote: > > Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > > >On Tuesday, November 27, 2018 at 5:11:30 PM UTC, Scott Lurndal wrote: > > >> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > > >> >Two out of five programmers contributing to this thread think that > > >> >the proliferation of integer types is a problem. > > >> > > >> Seriously? Do you have any understanding of statistics, confidence > > >> intervals and margins of error? > > >> > > >If you've got only one example, then that doesn't tell you much, it could > > >be an outlier. But if you've got two out of a sample of five, then it's > > >much less likely that the number is negligible. Of course whilst 40% > > >is your best estimate, it could be very much wrong in either direction. > > > > That "sample of five" is not a random sample, in fact it's basically > > self-selected, and any conclusion drawn from it is prima facia invalid. > > > NO, the point is that you've got a small sample, and two positives. > Which tells you that the positives are unlikely to be vanishingly rare. > But you're the one who brought up statistics. So that's a "no" to the question about your understanding of statistics, then.
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@alumni.caltech.edu |
|---|---|
| Date | 2018-11-27 09:49 -0800 |
| Message-ID | <c76858ba-dbd9-415e-8884-b2c17bd6352a@googlegroups.com> |
| In reply to | #138318 |
On Tuesday, November 27, 2018 at 12:11:30 PM UTC-5, Scott Lurndal wrote: > Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: ... > >Two out of five programmers contributing to this thread think that > >the proliferation of integer types is a problem. > > Seriously? Do you have any understanding of statistics, confidence > intervals and margins of error? Also, sampling bias: those who find the proliferation of types a problem are far more likely to contribute to this discussion than those who do not.
[toc] | [prev] | [next] | [standalone]
Page 3 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