Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #161260 > unrolled thread
| Started by | James Harris <james.harris.1@gmail.com> |
|---|---|
| First post | 2021-06-06 13:16 +0100 |
| Last post | 2021-06-17 19:30 +0200 |
| Articles | 20 on this page of 391 — 31 participants |
Back to article view | Back to comp.lang.c
Why does C allow structs to have a tag? James Harris <james.harris.1@gmail.com> - 2021-06-06 13:16 +0100
Re: Why does C allow structs to have a tag? David Brown <david.brown@hesbynett.no> - 2021-06-06 15:27 +0200
Re: Why does C allow structs to have a tag? Thiago Adams <thiago.adams@gmail.com> - 2021-06-07 06:00 -0700
Re: Why does C allow structs to have a tag? David Brown <david.brown@hesbynett.no> - 2021-06-07 18:06 +0200
Re: Why does C allow structs to have a tag? Öö Tiib <ootiib@hot.ee> - 2021-06-06 06:34 -0700
Re: Why does C allow structs to have a tag? James Harris <james.harris.1@gmail.com> - 2021-06-06 16:33 +0100
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-06-06 14:59 +0100
Re: Why does C allow structs to have a tag? Kaz Kylheku <563-365-8930@kylheku.com> - 2021-06-06 15:05 +0000
Re: Why does C allow structs to have a tag? Manfred <noname@add.invalid> - 2021-06-06 18:58 +0200
Re: Why does C allow structs to have a tag? David Brown <david.brown@hesbynett.no> - 2021-06-06 21:12 +0200
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-06-06 21:02 +0100
Re: Why does C allow structs to have a tag? Richard Harnden <richard.nospam@gmail.com> - 2021-06-06 21:25 +0100
Re: Why does C allow structs to have a tag? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-06-06 15:13 -0700
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-06-06 23:55 +0100
Re: Why does C allow structs to have a tag? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-06-06 17:02 -0700
Re: Why does C allow structs to have a tag? James Harris <james.harris.1@gmail.com> - 2021-06-07 18:42 +0100
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-06-07 19:39 +0100
Re: Why does C allow structs to have a tag? Manfred <noname@add.invalid> - 2021-06-07 17:15 +0200
Re: Why does C allow structs to have a tag? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-06-07 12:03 -0700
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-06-07 20:55 +0100
Re: Why does C allow structs to have a tag? David Brown <david.brown@hesbynett.no> - 2021-06-07 22:17 +0200
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-06-07 21:54 +0100
Re: Why does C allow structs to have a tag? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-06-07 13:22 -0700
Re: Why does C allow structs to have a tag? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2021-06-07 13:36 -0700
Re: Why does C allow structs to have a tag? David Brown <david.brown@hesbynett.no> - 2021-06-07 08:52 +0200
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-06-07 11:06 +0100
Re: Why does C allow structs to have a tag? David Brown <david.brown@hesbynett.no> - 2021-06-07 13:25 +0200
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-06-07 13:00 +0100
Re: Why does C allow structs to have a tag? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2021-06-07 07:25 -0700
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-06-07 16:31 +0100
Re: Why does C allow structs to have a tag? Kaz Kylheku <563-365-8930@kylheku.com> - 2021-06-07 16:15 +0000
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-06-07 17:53 +0100
Re: Why does C allow structs to have a tag? James Harris <james.harris.1@gmail.com> - 2021-06-07 19:02 +0100
Re: Why does C allow structs to have a tag? Kaz Kylheku <563-365-8930@kylheku.com> - 2021-06-07 22:26 +0000
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-06-08 00:19 +0100
Re: Why does C allow structs to have a tag? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-06-07 17:06 -0700
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-06-08 11:13 +0100
Re: Why does C allow structs to have a tag? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-06-08 11:43 -0700
Re: Why does C allow structs to have a tag? James Harris <james.harris.1@gmail.com> - 2021-06-07 18:54 +0100
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-06-07 19:57 +0100
Re: Why does C allow structs to have a tag? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-06-06 15:10 -0700
Re: Why does C allow structs to have a tag? Kaz Kylheku <563-365-8930@kylheku.com> - 2021-06-06 14:51 +0000
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-06-06 16:05 +0100
Re: Why does C allow structs to have a tag? James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-06-06 14:20 -0400
Re: Why does C allow structs to have a tag? Richard Damon <Richard@Damon-Family.org> - 2021-06-06 15:03 -0400
Re: Why does C allow structs to have a tag? James Harris <james.harris.1@gmail.com> - 2021-06-07 18:38 +0100
Re: Why does C allow structs to have a tag? Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2021-06-08 08:06 -0600
Re: Why does C allow structs to have a tag? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2021-06-08 07:45 -0700
Re: Why does C allow structs to have a tag? Guillaume <message@bottle.org> - 2021-06-08 17:09 +0200
Re: Why does C allow structs to have a tag? Kaz Kylheku <563-365-8930@kylheku.com> - 2021-06-08 16:00 +0000
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-06-08 17:23 +0100
Re: Why does C allow structs to have a tag? Kaz Kylheku <563-365-8930@kylheku.com> - 2021-06-08 18:59 +0000
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-06-09 00:22 +0100
Re: Why does C allow structs to have a tag? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-06-08 16:53 -0700
Re: Why does C allow structs to have a tag? James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-06-09 11:40 -0400
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-06-09 17:36 +0100
Re: Why does C allow structs to have a tag? Kaz Kylheku <563-365-8930@kylheku.com> - 2021-06-09 17:48 +0000
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-06-09 20:19 +0100
Re: Why does C allow structs to have a tag? Kaz Kylheku <563-365-8930@kylheku.com> - 2021-06-09 21:28 +0000
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-06-09 23:47 +0100
Re: Why does C allow structs to have a tag? David Brown <david.brown@hesbynett.no> - 2021-06-10 11:14 +0200
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-06-10 12:38 +0100
Re: Why does C allow structs to have a tag? David Brown <david.brown@hesbynett.no> - 2021-06-10 15:30 +0200
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-06-10 15:18 +0100
Re: Why does C allow structs to have a tag? David Brown <david.brown@hesbynett.no> - 2021-06-10 16:55 +0200
Re: Why does C allow structs to have a tag? Manfred <noname@add.invalid> - 2021-06-10 17:23 +0200
Re: Why does C allow structs to have a tag? David Brown <david.brown@hesbynett.no> - 2021-06-10 20:47 +0200
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-06-10 17:19 +0100
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-06-11 09:52 +0100
Re: Why does C allow structs to have a tag? David Brown <david.brown@hesbynett.no> - 2021-06-11 11:25 +0200
Re: Why does C allow structs to have a tag? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-06-11 12:00 -0700
Re: Why does C allow structs to have a tag? Guillaume <message@bottle.org> - 2021-06-11 21:14 +0200
Re: Why does C allow structs to have a tag? Kaz Kylheku <563-365-8930@kylheku.com> - 2021-06-11 19:46 +0000
Re: Why does C allow structs to have a tag? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-06-11 15:28 -0700
Re: Why does C allow structs to have a tag? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-06-11 15:06 -0700
Re: Why does C allow structs to have a tag? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-06-11 15:08 -0700
Re: Why does C allow structs to have a tag? David Brown <david.brown@hesbynett.no> - 2021-06-12 00:32 +0200
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-06-11 22:32 +0100
Re: Why does C allow structs to have a tag? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-06-11 15:17 -0700
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-06-11 23:29 +0100
Re: Why does C allow structs to have a tag? Kaz Kylheku <563-365-8930@kylheku.com> - 2021-06-11 23:21 +0000
Re: Why does C allow structs to have a tag? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-06-12 00:39 +0100
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-06-12 01:11 +0100
Re: Why does C allow structs to have a tag? Kaz Kylheku <563-365-8930@kylheku.com> - 2021-06-12 00:51 +0000
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-06-12 11:08 +0100
Re: Why does C allow structs to have a tag? Kaz Kylheku <563-365-8930@kylheku.com> - 2021-06-12 16:12 +0000
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-06-12 18:36 +0100
Re: Why does C allow structs to have a tag? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-06-12 13:06 -0700
Re: Why does C allow structs to have a tag? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-06-12 12:42 -0700
Re: Why does C allow structs to have a tag? David Brown <david.brown@hesbynett.no> - 2021-06-12 14:13 +0200
Re: Why does C allow structs to have a tag? Kaz Kylheku <563-365-8930@kylheku.com> - 2021-06-10 15:16 +0000
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-06-10 16:45 +0100
Re: Why does C allow structs to have a tag? Kaz Kylheku <563-365-8930@kylheku.com> - 2021-06-10 16:56 +0000
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-06-10 19:32 +0100
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-06-09 22:37 +0100
Re: Why does C allow structs to have a tag? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-06-09 15:12 -0700
Re: Why does C allow structs to have a tag? Kaz Kylheku <563-365-8930@kylheku.com> - 2021-06-09 23:18 +0000
Re: Why does C allow structs to have a tag? Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2021-06-08 09:25 -0600
Re: Why does C allow structs to have a tag? Kaz Kylheku <563-365-8930@kylheku.com> - 2021-06-08 16:13 +0000
Re: Why does C allow structs to have a tag? Richard Damon <Richard@Damon-Family.org> - 2021-06-08 21:43 -0400
Re: Why does C allow structs to have a tag? John Bode <jfbode1029@gmail.com> - 2021-06-08 15:03 -0500
Re: Why does C allow structs to have a tag? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-06-24 10:33 -0700
Re: Why does C allow structs to have a tag? Öö Tiib <ootiib@hot.ee> - 2021-06-24 13:45 -0700
Re: Why does C allow structs to have a tag? John Bode <jfbode1029@gmail.com> - 2021-07-01 17:57 -0500
Re: Why does C allow structs to have a tag? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-07-11 00:26 -0700
Re: Why does C allow structs to have a tag? John Bode <jfbode1029@gmail.com> - 2021-07-26 09:49 -0500
Re: Why does C allow structs to have a tag? Kaz Kylheku <563-365-8930@kylheku.com> - 2021-07-27 15:47 +0000
Re: Why does C allow structs to have a tag? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-07-27 10:55 -0700
Re: Why does C allow structs to have a tag? Guillaume <message@bottle.org> - 2021-07-27 23:48 +0200
Re: Why does C allow structs to have a tag? scott@slp53.sl.home (Scott Lurndal) - 2021-07-27 22:12 +0000
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-07-28 00:38 +0100
Re: Why does C allow structs to have a tag? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-07-27 18:30 -0700
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-07-28 13:02 +0100
Re: Why does C allow structs to have a tag? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-07-28 07:19 -0700
Re: Why does C allow structs to have a tag? scott@slp53.sl.home (Scott Lurndal) - 2021-07-28 14:06 +0000
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-07-28 15:44 +0100
Re: Why does C allow structs to have a tag? scott@slp53.sl.home (Scott Lurndal) - 2021-07-28 15:21 +0000
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-07-28 17:49 +0100
Re: Why does C allow structs to have a tag? scott@slp53.sl.home (Scott Lurndal) - 2021-07-28 17:21 +0000
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-07-28 23:41 +0100
Re: Why does C allow structs to have a tag? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-07-28 16:07 -0700
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-07-29 02:23 +0100
Re: Why does C allow structs to have a tag? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-07-28 19:20 -0700
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-07-29 11:05 +0100
Re: Why does C allow structs to have a tag? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-07-29 08:12 -0700
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-07-29 16:34 +0100
Re: Why does C allow structs to have a tag? scott@slp53.sl.home (Scott Lurndal) - 2021-07-29 17:10 +0000
Re: Why does C allow structs to have a tag? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-07-29 10:29 -0700
Re: Why does C allow structs to have a tag? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-07-29 10:28 -0700
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-07-29 19:07 +0100
Re: Why does C allow structs to have a tag? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-07-29 11:16 -0700
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-07-29 19:41 +0100
Re: Why does C allow structs to have a tag? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-07-29 12:43 -0700
Re: Why does C allow structs to have a tag? Kaz Kylheku <563-365-8930@kylheku.com> - 2021-07-30 15:06 +0000
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-07-30 16:31 +0100
Re: Why does C allow structs to have a tag? David Brown <david.brown@hesbynett.no> - 2021-07-30 19:49 +0200
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-07-30 20:03 +0100
Re: Why does C allow structs to have a tag? David Brown <david.brown@hesbynett.no> - 2021-07-30 23:16 +0200
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-07-31 01:51 +0100
Re: Why does C allow structs to have a tag? David Brown <david.brown@hesbynett.no> - 2021-07-31 13:42 +0200
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-07-31 14:56 +0100
Re: Why does C allow structs to have a tag? Manfred <noname@add.invalid> - 2021-07-31 19:33 +0200
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-07-31 19:17 +0100
Re: Why does C allow structs to have a tag? Manfred <noname@add.invalid> - 2021-07-31 21:32 +0200
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-07-31 23:10 +0100
Re: Why does C allow structs to have a tag? Manfred <noname@add.invalid> - 2021-08-01 00:43 +0200
Re: Why does C allow structs to have a tag? Richard Damon <Richard@Damon-Family.org> - 2021-07-31 15:54 -0700
Re: Why does C allow structs to have a tag? David Brown <david.brown@hesbynett.no> - 2021-08-04 13:36 +0200
Re: Why does C allow structs to have a tag? David Brown <david.brown@hesbynett.no> - 2021-08-04 13:32 +0200
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-08-04 14:24 +0100
Re: Why does C allow structs to have a tag? David Brown <david.brown@hesbynett.no> - 2021-08-04 16:08 +0200
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-08-04 16:32 +0100
Re: Why does C allow structs to have a tag? scott@slp53.sl.home (Scott Lurndal) - 2021-08-04 16:33 +0000
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-08-04 18:40 +0100
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-08-04 19:31 +0100
Re: Why does C allow structs to have a tag? DFS <nospam@dfs.com> - 2021-08-07 10:03 -0400
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-08-07 17:11 +0100
Re: Why does C allow structs to have a tag? DFS <nospam@dfs.com> - 2021-08-08 08:51 -0400
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-08-08 15:41 +0100
Re: Why does C allow structs to have a tag? Kaz Kylheku <563-365-8930@kylheku.com> - 2021-08-08 17:12 +0000
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-08-08 20:25 +0100
Re: Why does C allow structs to have a tag? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-08-08 20:21 +0100
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-08-08 20:38 +0100
Re: Why does C allow structs to have a tag? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2021-08-08 14:00 -0700
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-08-08 22:16 +0100
Re: Why does C allow structs to have a tag? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-08-08 22:17 +0100
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-08-08 22:32 +0100
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-08-08 23:13 +0100
Re: Why does C allow structs to have a tag? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-08-09 01:46 +0100
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-08-09 10:54 +0100
Re: Why does C allow structs to have a tag? Michael S <already5chosen@yahoo.com> - 2021-08-09 03:59 -0700
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-08-09 13:55 +0100
Re: Why does C allow structs to have a tag? David Brown <david.brown@hesbynett.no> - 2021-08-09 16:08 +0200
Re: Why does C allow structs to have a tag? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2021-08-09 07:53 -0700
Re: Why does C allow structs to have a tag? Michael S <already5chosen@yahoo.com> - 2021-08-09 08:28 -0700
Re: Why does C allow structs to have a tag? Michael S <already5chosen@yahoo.com> - 2021-08-09 08:19 -0700
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-08-09 16:51 +0100
Re: Why does C allow structs to have a tag? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-08-09 16:47 +0100
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-08-09 17:09 +0100
Re: Why does C allow structs to have a tag? Michael S <already5chosen@yahoo.com> - 2021-08-08 15:30 -0700
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-08-09 00:33 +0100
Re: Why does C allow structs to have a tag? DFS <nospam@dfs.com> - 2021-08-08 20:03 -0400
Re: Why does C allow structs to have a tag? Michael S <already5chosen@yahoo.com> - 2021-08-09 01:29 -0700
Re: Why does C allow structs to have a tag? DFS <nospam@dfs.com> - 2021-08-09 15:05 -0400
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-08-09 23:48 +0100
Re: Why does C allow structs to have a tag? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-08-09 16:45 -0700
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-08-10 01:33 +0100
Re: Why does C allow structs to have a tag? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-08-09 17:52 -0700
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-08-10 11:17 +0100
Re: Why does C allow structs to have a tag? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-08-10 11:22 -0700
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-08-10 20:05 +0100
Re: Why does C allow structs to have a tag? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-08-10 13:49 -0700
Re: Why does C allow structs to have a tag? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2021-08-10 03:03 -0700
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-08-10 16:27 +0100
Re: Why does C allow structs to have a tag? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-08-10 11:17 -0700
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-08-10 20:23 +0100
Re: Why does C allow structs to have a tag? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-08-10 14:00 -0700
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-08-10 22:54 +0100
Re: Why does C allow structs to have a tag? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-08-10 15:32 -0700
Re: Why does C allow structs to have a tag? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2021-08-09 17:53 -0700
Re: Why does C allow structs to have a tag? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-08-09 18:27 -0700
Re: Why does C allow structs to have a tag? Michael S <already5chosen@yahoo.com> - 2021-08-10 01:55 -0700
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-08-10 12:19 +0100
Re: Why does C allow structs to have a tag? Michael S <already5chosen@yahoo.com> - 2021-08-10 02:04 -0700
Re: Why does C allow structs to have a tag? Michael S <already5chosen@yahoo.com> - 2021-08-10 09:42 -0700
Re: Why does C allow structs to have a tag? antispam@math.uni.wroc.pl - 2021-08-11 17:19 +0000
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-08-11 20:04 +0100
Re: Why does C allow structs to have a tag? antispam@math.uni.wroc.pl - 2021-08-11 20:19 +0000
Re: Why does C allow structs to have a tag? DFS <nospam@dfs.com> - 2021-08-11 16:51 -0400
Re: Why does C allow structs to have a tag? scott@slp53.sl.home (Scott Lurndal) - 2021-08-11 21:33 +0000
Re: Why does C allow structs to have a tag? DFS <nospam@dfs.com> - 2021-08-11 19:10 -0400
Re: Why does C allow structs to have a tag? antispam@math.uni.wroc.pl - 2021-08-12 16:08 +0000
Re: Why does C allow structs to have a tag? scott@slp53.sl.home (Scott Lurndal) - 2021-08-08 19:56 +0000
Re: Why does C allow structs to have a tag? DFS <nospam@dfs.com> - 2021-08-10 14:35 -0700
Re: Why does C allow structs to have a tag? scott@slp53.sl.home (Scott Lurndal) - 2021-08-10 21:41 +0000
Re: Why does C allow structs to have a tag? DFS <nospam@dfs.com> - 2021-08-10 15:08 -0700
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-08-10 23:22 +0100
Re: Why does C allow structs to have a tag? DFS <nospam@dfs.com> - 2021-08-10 20:15 -0400
Re: Why does C allow structs to have a tag? antispam@math.uni.wroc.pl - 2021-08-11 08:34 +0000
Re: Why does C allow structs to have a tag? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-08-11 11:23 +0100
Re: Why does C allow structs to have a tag? Michael S <already5chosen@yahoo.com> - 2021-08-11 03:46 -0700
Re: Why does C allow structs to have a tag? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-08-11 14:29 +0100
Re: Why does C allow structs to have a tag? Michael S <already5chosen@yahoo.com> - 2021-08-11 07:26 -0700
Re: Why does C allow structs to have a tag? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-10-01 15:04 -0700
Re: Why does C allow structs to have a tag? Michael S <already5chosen@yahoo.com> - 2021-08-11 03:55 -0700
Re: Why does C allow structs to have a tag? scott@slp53.sl.home (Scott Lurndal) - 2021-08-11 13:55 +0000
Re: Why does C allow structs to have a tag? Michael S <already5chosen@yahoo.com> - 2021-08-11 07:07 -0700
Re: Why does C allow structs to have a tag? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-10-01 13:44 -0700
Re: Why does C allow structs to have a tag? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2021-10-01 22:40 -0700
Re: Why does C allow structs to have a tag? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-10-02 01:37 -0700
Re: Why does C allow structs to have a tag? DFS <nospam@dfs.com> - 2021-08-11 14:29 -0400
Re: Why does C allow structs to have a tag? scott@slp53.sl.home (Scott Lurndal) - 2021-08-11 18:54 +0000
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-08-11 20:10 +0100
Re: Why does C allow structs to have a tag? scott@slp53.sl.home (Scott Lurndal) - 2021-08-11 20:04 +0000
Re: Why does C allow structs to have a tag? DFS <nospam@dfs.com> - 2021-08-11 17:04 -0400
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-08-11 11:09 +0100
Re: Why does C allow structs to have a tag? scott@slp53.sl.home (Scott Lurndal) - 2021-08-11 13:52 +0000
Re: Why does C allow structs to have a tag? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2021-08-11 08:01 -0700
Re: Why does C allow structs to have a tag? scott@slp53.sl.home (Scott Lurndal) - 2021-08-11 15:06 +0000
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-08-11 16:47 +0100
Re: Why does C allow structs to have a tag? scott@slp53.sl.home (Scott Lurndal) - 2021-08-11 16:14 +0000
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-08-11 18:27 +0100
Re: Why does C allow structs to have a tag? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2021-08-11 11:01 -0700
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-08-11 19:45 +0100
Re: Why does C allow structs to have a tag? DFS <nospam@dfs.com> - 2021-08-11 15:55 -0400
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-08-11 22:10 +0100
Re: Why does C allow structs to have a tag? David Brown <david.brown@hesbynett.no> - 2021-08-11 22:47 +0200
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-08-11 23:00 +0100
Re: Why does C allow structs to have a tag? David Brown <david.brown@hesbynett.no> - 2021-08-12 10:29 +0200
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-08-12 12:10 +0100
Re: Why does C allow structs to have a tag? David Brown <david.brown@hesbynett.no> - 2021-08-12 16:28 +0200
Re: Why does C allow structs to have a tag? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2021-08-12 08:03 -0700
Re: Why does C allow structs to have a tag? scott@slp53.sl.home (Scott Lurndal) - 2021-08-12 15:52 +0000
Re: Why does C allow structs to have a tag? David Brown <david.brown@hesbynett.no> - 2021-08-12 17:55 +0200
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-08-12 16:59 +0100
Re: Why does C allow structs to have a tag? David Brown <david.brown@hesbynett.no> - 2021-08-12 19:44 +0200
Re: Why does C allow structs to have a tag? antispam@math.uni.wroc.pl - 2021-08-12 19:02 +0000
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-08-12 20:22 +0100
Re: Why does C allow structs to have a tag? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-08-12 11:10 -0700
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-08-12 23:17 +0100
Re: Why does C allow structs to have a tag? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-08-12 16:52 -0700
Re: Why does C allow structs to have a tag? Richard Damon <Richard@Damon-Family.org> - 2021-08-12 22:22 -0400
Re: Why does C allow structs to have a tag? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-08-12 19:51 -0700
Re: Why does C allow structs to have a tag? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-10-01 13:49 -0700
Re: Why does C allow structs to have a tag? antispam@math.uni.wroc.pl - 2021-08-12 16:52 +0000
Re: Why does C allow structs to have a tag? antispam@math.uni.wroc.pl - 2021-08-12 18:45 +0000
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-08-12 22:17 +0100
Re: Why does C allow structs to have a tag? antispam@math.uni.wroc.pl - 2021-08-11 21:09 +0000
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-08-11 23:13 +0100
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-08-11 23:30 +0100
Re: Why does C allow structs to have a tag? David Brown <david.brown@hesbynett.no> - 2021-08-12 10:39 +0200
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-08-12 12:26 +0100
Re: Why does C allow structs to have a tag? David Brown <david.brown@hesbynett.no> - 2021-08-12 16:44 +0200
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-08-12 17:20 +0100
Re: Why does C allow structs to have a tag? David Brown <david.brown@hesbynett.no> - 2021-08-12 20:00 +0200
Re: Why does C allow structs to have a tag? antispam@math.uni.wroc.pl - 2021-08-12 00:44 +0000
Re: Why does C allow structs to have a tag? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2021-08-11 10:39 -0700
Re: Why does C allow structs to have a tag? scott@slp53.sl.home (Scott Lurndal) - 2021-08-11 17:52 +0000
Re: Why does C allow structs to have a tag? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-08-11 11:41 -0700
Re: Why does C allow structs to have a tag? DFS <nospam@dfs.com> - 2021-08-08 16:00 -0400
Re: Why does C allow structs to have a tag? Ike Naar <ike@rie.sdf.org> - 2021-08-09 05:46 +0000
Re: Why does C allow structs to have a tag? Michael S <already5chosen@yahoo.com> - 2021-08-09 01:38 -0700
Re: Why does C allow structs to have a tag? Michael S <already5chosen@yahoo.com> - 2021-08-09 01:57 -0700
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-08-09 10:55 +0100
Re: Why does C allow structs to have a tag? James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-08-04 11:48 -0400
Re: Why does C allow structs to have a tag? David Brown <david.brown@hesbynett.no> - 2021-08-04 19:34 +0200
Re: Why does C allow structs to have a tag? antispam@math.uni.wroc.pl - 2021-07-31 19:18 +0000
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-07-31 22:35 +0100
Re: Why does C allow structs to have a tag? antispam@math.uni.wroc.pl - 2021-07-31 23:51 +0000
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-08-01 01:46 +0100
Re: Why does C allow structs to have a tag? Manfred <noname@add.invalid> - 2021-07-30 17:20 +0200
Re: Why does C allow structs to have a tag? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-07-30 11:16 -0700
Re: Why does C allow structs to have a tag? Manfred <noname@add.invalid> - 2021-07-30 20:24 +0200
Re: Why does C allow structs to have a tag? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-07-30 14:17 -0700
Re: Why does C allow structs to have a tag? Kaz Kylheku <563-365-8930@kylheku.com> - 2021-07-30 14:55 +0000
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-07-30 16:13 +0100
Re: Why does C allow structs to have a tag? "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2021-07-30 09:08 -0700
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-07-30 18:18 +0100
Re: Why does C allow structs to have a tag? scott@slp53.sl.home (Scott Lurndal) - 2021-07-30 17:38 +0000
Re: Why does C allow structs to have a tag? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-07-30 11:17 -0700
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-07-30 20:33 +0100
Re: Why does C allow structs to have a tag? scott@slp53.sl.home (Scott Lurndal) - 2021-07-30 20:10 +0000
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-07-30 21:50 +0100
Re: Why does C allow structs to have a tag? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-07-30 14:49 -0700
Re: Why does C allow structs to have a tag? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-07-30 14:39 -0700
Re: Why does C allow structs to have a tag? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-07-30 14:44 -0700
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-07-31 00:08 +0100
Re: Why does C allow structs to have a tag? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-07-30 16:31 -0700
Re: Why does C allow structs to have a tag? antispam@math.uni.wroc.pl - 2021-07-31 19:57 +0000
Re: Why does C allow structs to have a tag? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-07-30 11:01 -0700
Re: Why does C allow structs to have a tag? David Brown <david.brown@hesbynett.no> - 2021-07-30 23:28 +0200
Re: Why does C allow structs to have a tag? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-07-30 15:19 -0700
Re: Why does C allow structs to have a tag? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-07-30 11:12 -0700
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-07-30 20:26 +0100
Re: Why does C allow structs to have a tag? scott@slp53.sl.home (Scott Lurndal) - 2021-07-30 20:08 +0000
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-07-30 22:10 +0100
Re: Why does C allow structs to have a tag? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-07-30 15:34 -0700
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-07-31 00:13 +0100
Re: Why does C allow structs to have a tag? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-07-30 16:36 -0700
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-07-31 02:23 +0100
Re: Why does C allow structs to have a tag? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-07-30 21:14 -0700
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-07-31 11:27 +0100
Re: Why does C allow structs to have a tag? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-07-31 15:29 -0700
Re: Why does C allow structs to have a tag? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-07-31 15:48 -0700
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-08-01 00:14 +0100
Re: Why does C allow structs to have a tag? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-07-31 16:25 -0700
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-08-01 00:52 +0100
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-08-01 00:29 +0100
Re: Why does C allow structs to have a tag? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-07-31 16:50 -0700
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-08-01 01:16 +0100
Re: Why does C allow structs to have a tag? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-07-31 18:01 -0700
Re: Why does C allow structs to have a tag? gazelle@shell.xmission.com (Kenny McCormack) - 2021-08-01 01:38 +0000
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-08-01 11:41 +0100
Re: Why does C allow structs to have a tag? gazelle@shell.xmission.com (Kenny McCormack) - 2021-08-01 19:14 +0000
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-08-01 11:54 +0100
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-08-01 16:34 +0100
Re: Why does C allow structs to have a tag? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-08-01 14:58 -0700
Re: Why does C allow structs to have a tag? Manfred <noname@invalid.add> - 2021-08-01 19:27 +0200
Re: Why does C allow structs to have a tag? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-07-30 14:43 -0700
Re: Why does C allow structs to have a tag? antispam@math.uni.wroc.pl - 2021-07-30 23:33 +0000
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-07-31 02:11 +0100
Re: Why does C allow structs to have a tag? antispam@math.uni.wroc.pl - 2021-07-31 20:33 +0000
Re: Why does C allow structs to have a tag? Kaz Kylheku <563-365-8930@kylheku.com> - 2021-07-31 02:14 +0000
Re: Why does C allow structs to have a tag? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-07-30 21:23 -0700
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-07-31 11:39 +0100
Re: Why does C allow structs to have a tag? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-07-31 12:58 -0700
Re: Why does C allow structs to have a tag? Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2021-07-31 21:21 +0000
Re: Why does C allow structs to have a tag? Kaz Kylheku <563-365-8930@kylheku.com> - 2021-07-30 14:54 +0000
Re: Why does C allow structs to have a tag? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-07-30 10:47 -0700
Re: Why does C allow structs to have a tag? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-07-30 14:16 -0700
Re: Why does C allow structs to have a tag? Kaz Kylheku <563-365-8930@kylheku.com> - 2021-07-30 14:51 +0000
Re: Why does C allow structs to have a tag? Manfred <noname@add.invalid> - 2021-07-30 20:22 +0200
Re: Why does C allow structs to have a tag? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-07-30 14:07 -0700
Re: Why does C allow structs to have a tag? John Dill <jadill33@gmail.com> - 2021-07-29 06:09 -0700
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-07-29 14:26 +0100
Re: Why does C allow structs to have a tag? scott@slp53.sl.home (Scott Lurndal) - 2021-07-29 13:51 +0000
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-07-29 16:18 +0100
Re: Why does C allow structs to have a tag? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-09-30 05:39 -0700
Re: Why does C allow structs to have a tag? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-07-27 17:14 -0700
Re: Why does C allow structs to have a tag? Kaz Kylheku <563-365-8930@kylheku.com> - 2021-07-28 02:01 +0000
Re: Why does C allow structs to have a tag? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-07-27 19:07 -0700
Re: Why does C allow structs to have a tag? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-07-27 12:32 -0700
Re: Why does C allow structs to have a tag? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-07-27 12:41 -0700
Re: Why does C allow structs to have a tag? John Bode <jfbode1029@gmail.com> - 2021-07-30 09:02 -0500
Re: Why does C allow structs to have a tag? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-30 15:19 +0100
Re: Why does C allow structs to have a tag? John Bode <jfbode1029@gmail.com> - 2021-07-30 10:19 -0500
Re: Why does C allow structs to have a tag? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-30 16:34 +0100
Re: Why does C allow structs to have a tag? scott@slp53.sl.home (Scott Lurndal) - 2021-07-30 15:58 +0000
Re: Why does C allow structs to have a tag? Lowell Gilbert <lgusenet@be-well.ilk.org> - 2021-07-30 11:28 -0400
Re: Why does C allow structs to have a tag? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-09-06 05:20 -0700
Re: Why does C allow structs to have a tag? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-09-06 05:09 -0700
Re: Why does C allow structs to have a tag? Siri Cruise <chine.bleu@yahoo.com> - 2021-06-11 12:33 -0700
Re: Why does C allow structs to have a tag? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2021-06-16 19:39 -0700
Re: Why does C allow structs to have a tag? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-06-17 11:50 +0100
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-06-17 12:02 +0100
Re: Why does C allow structs to have a tag? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-06-17 17:05 +0100
Re: Why does C allow structs to have a tag? David Brown <david.brown@hesbynett.no> - 2021-06-17 13:49 +0200
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-06-17 13:39 +0100
Re: Why does C allow structs to have a tag? David Brown <david.brown@hesbynett.no> - 2021-06-17 15:05 +0200
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-06-17 14:34 +0100
Re: Why does C allow structs to have a tag? David Brown <david.brown@hesbynett.no> - 2021-06-17 18:35 +0200
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-06-17 18:14 +0100
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-06-17 11:29 +0100
Re: Why does C allow structs to have a tag? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2021-06-17 08:22 -0700
Re: Why does C allow structs to have a tag? Kaz Kylheku <563-365-8930@kylheku.com> - 2021-06-17 16:22 +0000
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-06-17 17:57 +0100
Re: Why does C allow structs to have a tag? Kaz Kylheku <563-365-8930@kylheku.com> - 2021-06-17 17:53 +0000
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-06-17 21:27 +0100
Re: Why does C allow structs to have a tag? Öö Tiib <ootiib@hot.ee> - 2021-06-17 17:58 -0700
Re: Why does C allow structs to have a tag? Bart <bc@freeuk.com> - 2021-06-18 11:25 +0100
Re: Why does C allow structs to have a tag? Guillaume <message@bottle.org> - 2021-06-17 19:30 +0200
Page 13 of 20 — ← Prev page 1 … 11 12 [13] 14 15 … 20 Next page →
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2021-08-11 16:14 +0000 |
| Message-ID | <kHSQI.38629$EF2.24792@fx47.iad> |
| In reply to | #162320 |
Bart <bc@freeuk.com> writes: >On 11/08/2021 16:06, Scott Lurndal wrote: >> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: >>> On Wednesday, 11 August 2021 at 14:52:54 UTC+1, Scott Lurndal wrote: >>>> >>>> strcat is almost never the right interface to use. It needs >>>> to scan the entire string to find the terminal nul-byte before >>>> appending. As the string gets longer, each strcat takes longer >>>> than the one before. >>>> >>>> Just keep a pointer to the next element and increment the >>>> pointer each time you add a new element. >>>> >>> Most strings are short. Building up a url with strcat is not going to >>> stress a 3GHz machine. If the strings become huge then, yes, you >>> need to look at more efficient ways of concatenating them. >> >> Building it with snprintf() will be far more flexible and efficient. >> >> Every cycle matters. >> > > >Start with this: No thanks. I've enough to do writing real working production code.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-08-11 18:27 +0100 |
| Message-ID | <sf11ab$bfr$1@dont-email.me> |
| In reply to | #162321 |
On 11/08/2021 17:14, Scott Lurndal wrote: > Bart <bc@freeuk.com> writes: >> On 11/08/2021 16:06, Scott Lurndal wrote: >>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: >>>> On Wednesday, 11 August 2021 at 14:52:54 UTC+1, Scott Lurndal wrote: >>>>> >>>>> strcat is almost never the right interface to use. It needs >>>>> to scan the entire string to find the terminal nul-byte before >>>>> appending. As the string gets longer, each strcat takes longer >>>>> than the one before. >>>>> >>>>> Just keep a pointer to the next element and increment the >>>>> pointer each time you add a new element. >>>>> >>>> Most strings are short. Building up a url with strcat is not going to >>>> stress a 3GHz machine. If the strings become huge then, yes, you >>>> need to look at more efficient ways of concatenating them. >>> >>> Building it with snprintf() will be far more flexible and efficient. >>> >>> Every cycle matters. >>> >> >> >> Start with this: > > No thanks. I've enough to do writing real working production code. > And giving bad, untested advice...
[toc] | [prev] | [next] | [standalone]
| From | Andrey Tarasevich <andreytarasevich@hotmail.com> |
|---|---|
| Date | 2021-08-11 11:01 -0700 |
| Message-ID | <sf1399$mg3$1@dont-email.me> |
| In reply to | #162320 |
On 8/11/2021 8:47 AM, Bart wrote: > > (all unoptimised code to stop it being optimised > out of existence): > ... > then it takes 5.5 seconds. With snprintf() as you suggest, it takes 6.1 > seconds. I thought you said every cycle matters? > ^^^ Timing "unoptimised" code and then talking about "cycles". This does not make a single shred of sense. -- Best regards, Andrey Tarasevich
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-08-11 19:45 +0100 |
| Message-ID | <sf15rl$cia$1@dont-email.me> |
| In reply to | #162326 |
On 11/08/2021 19:01, Andrey Tarasevich wrote: > On 8/11/2021 8:47 AM, Bart wrote: >> >> (all unoptimised code to stop it being optimised out of existence): >> ... >> then it takes 5.5 seconds. With snprintf() as you suggest, it takes >> 6.1 seconds. I thought you said every cycle matters? >> > > ^^^ Timing "unoptimised" code and then talking about "cycles". This does > not make a single shred of sense. > The code we're talking about is functions in a binary library which presumably are already optimised. If I turn on optimisation for my simple loops, then all timings become 0.0 seconds; what on earth use is that? Perhaps you'd like to provide a better test program then? One which tests the efficacy of strcat vs snprintf, rather than a how smart a compiler is in making short work of a pointless, repetitive loop. In a real application, the strings may not be simple literals of a known length, may not be so amenable to inlining, and may not be in a simple loop like this and where results are discarded.
[toc] | [prev] | [next] | [standalone]
| From | DFS <nospam@dfs.com> |
|---|---|
| Date | 2021-08-11 15:55 -0400 |
| Message-ID | <4XVQI.40335$Fx8.28023@fx45.iad> |
| In reply to | #162320 |
On 8/11/2021 11:47 AM, Bart wrote:
> Start with this:
>
> char str[100];
> char* s;
>
> Then a loop like this (all unoptimised code to stop it being optimised
> out of existence):
>
> for (int i=0; i<10000000; ++i) {
> strcpy(str,"one ");
> strcat(str,"two ");
> strcat(str,"three ");
> strcat(str,"four ");
> strcat(str,"five");
> }
> puts(str);
>
>
> took 1 second (on my Windows PC running tcc). If use sprintf():
>
> for (int i=0; i<10000000; ++i) {
> s=str;
> s+=sprintf(s,"%s","one ");
> s+=sprintf(s,"%s","two ");
> s+=sprintf(s,"%s","three ");
> s+=sprintf(s,"%s","four ");
> sprintf(s,"%s","five");
> }
> puts(s);
Did you mean to leave off the s+= in the last line?
> then it takes 5.5 seconds. With snprintf() as you suggest, it takes 6.1
> seconds. I thought you said every cycle matters?
FWIW: also on Windows
compiled with tcc
strcat : 0.7s
sprintf: 6.3s
compiled with Mingw-w64 GCC
strcat : 0.4s
sprintf: 4.4s
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-08-11 22:10 +0100 |
| Message-ID | <sf1ecg$da2$1@dont-email.me> |
| In reply to | #162334 |
On 11/08/2021 20:55, DFS wrote:
> On 8/11/2021 11:47 AM, Bart wrote:
>
>> Start with this:
>>
>> char str[100];
>> char* s;
>>
>> Then a loop like this (all unoptimised code to stop it being optimised
>> out of existence):
>>
>> for (int i=0; i<10000000; ++i) {
>> strcpy(str,"one ");
>> strcat(str,"two ");
>> strcat(str,"three ");
>> strcat(str,"four ");
>> strcat(str,"five");
>> }
>> puts(str);
>>
>>
>> took 1 second (on my Windows PC running tcc). If use sprintf():
>>
>> for (int i=0; i<10000000; ++i) {
>> s=str;
>> s+=sprintf(s,"%s","one ");
>> s+=sprintf(s,"%s","two ");
>> s+=sprintf(s,"%s","three ");
>> s+=sprintf(s,"%s","four ");
>> sprintf(s,"%s","five");
>> }
>> puts(s);
>
>
> Did you mean to leave off the s+= in the last line?
Yes; because s is not needed further in that iteration.
(But the last puts should operate on str, not s, which just shows the
last substring.)
>
>
>> then it takes 5.5 seconds. With snprintf() as you suggest, it takes
>> 6.1 seconds. I thought you said every cycle matters?
>
> FWIW: also on Windows
>
> compiled with tcc
> strcat : 0.7s
> sprintf: 6.3s
>
> compiled with Mingw-w64 GCC
> strcat : 0.4s
> sprintf: 4.4s
I was trying to see whether sprintf/snprintf was more efficient than
strcat for concatenating several short strings, as was postulated.
Well, apparently not for strings totalling only 23 characters. Maybe the
differences would be narrower for longer strings, but I tried it with
strings totalling 158 characters, and there was an even wider gap
between the strcat and sprintf loops.
(Note my gcc seems to do a similar trick here as with printf, in using a
version of sprintf which is not the one in msvcrt.dll. One that is about
1/3 faster, but is still significantly slower than strcat for this test.)
This is really not surprising, since strcat can implemented much more
simply than sprintf.
I tried to find a crossover point, a total length of string at which an
sprintf loop was faster than a strcat one, and there wasn't one! At
least not under a 2.5MB total string anyway.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2021-08-11 22:47 +0200 |
| Message-ID | <sf1d0q$iiu$1@dont-email.me> |
| In reply to | #162320 |
On 11/08/2021 17:47, Bart wrote:
> On 11/08/2021 16:06, Scott Lurndal wrote:
>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>> On Wednesday, 11 August 2021 at 14:52:54 UTC+1, Scott Lurndal wrote:
>>>>
>>>> strcat is almost never the right interface to use. It needs
>>>> to scan the entire string to find the terminal nul-byte before
>>>> appending. As the string gets longer, each strcat takes longer
>>>> than the one before.
>>>>
>>>> Just keep a pointer to the next element and increment the
>>>> pointer each time you add a new element.
>>>>
>>> Most strings are short. Building up a url with strcat is not going to
>>> stress a 3GHz machine. If the strings become huge then, yes, you
>>> need to look at more efficient ways of concatenating them.
>>
>> Building it with snprintf() will be far more flexible and efficient.
>>
>> Every cycle matters.
>>
>
>
> Start with this:
>
> char str[100];
> char* s;
>
> Then a loop like this (all unoptimised code to stop it being optimised
> out of existence):
As you well know, timing unoptimised code is an utterly pointless
exercise. You need to do something to make sure the operations are
carried out, such as judicious use of volatile, or using "global"
variables rather than local ones. Disabling optimisation is like
comparing the speed of cars while forcing them to remain in first gear.
>
> for (int i=0; i<10000000; ++i) {
> strcpy(str,"one ");
> strcat(str,"two ");
> strcat(str,"three ");
> strcat(str,"four ");
> strcat(str,"five");
> }
> puts(str);
>
>
> took 1 second (on my Windows PC running tcc). If use sprintf():
>
> for (int i=0; i<10000000; ++i) {
> s=str;
> s+=sprintf(s,"%s","one ");
> s+=sprintf(s,"%s","two ");
> s+=sprintf(s,"%s","three ");
> s+=sprintf(s,"%s","four ");
> sprintf(s,"%s","five");
> }
> puts(s);
>
> then it takes 5.5 seconds. With snprintf() as you suggest, it takes 6.1
> seconds. I thought you said every cycle matters?
>
<https://godbolt.org/z/954eccfsM>
gcc (and I really mean gcc - no libraries are involved) generates
identical code in both cases, and so I would assume (without testing)
that the speed is the same.
> These all write into the same string. If each iteration uses a newly
> allocated 100-char string, then the strcat loop takes 2.2 seconds, and
> both forms of sprintf take something over 7 seconds.
>
> If I take the second loop above, and write the string directly (so not
> using "%s"), then it makes no difference; it's not the formatting that
> takes the extra time, not for %s anyway, it must be other overheads.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-08-11 23:00 +0100 |
| Message-ID | <sf1had$5p9$1@dont-email.me> |
| In reply to | #162337 |
On 11/08/2021 21:47, David Brown wrote:
> On 11/08/2021 17:47, Bart wrote:
>> Start with this:
>>
>> char str[100];
>> char* s;
>>
>> Then a loop like this (all unoptimised code to stop it being optimised
>> out of existence):
>
> As you well know, timing unoptimised code is an utterly pointless
> exercise. You need to do something to make sure the operations are
> carried out, such as judicious use of volatile, or using "global"
> variables rather than local ones. Disabling optimisation is like
> comparing the speed of cars while forcing them to remain in first gear.
No, it's ensuring that all of them follow the same route. Otherwise each
will find their own shortcuts, or may not bother going anywhere at all
if they see they're simply going to end up back home anyway.
That's helpful if you're trying to compare different cars or different
routes.
>>
>> for (int i=0; i<10000000; ++i) {
>> strcpy(str,"one ");
>> strcat(str,"two ");
>> strcat(str,"three ");
>> strcat(str,"four ");
>> strcat(str,"five");
>> }
>> puts(str);
>>
>>
>> took 1 second (on my Windows PC running tcc). If use sprintf():
>>
>> for (int i=0; i<10000000; ++i) {
>> s=str;
>> s+=sprintf(s,"%s","one ");
>> s+=sprintf(s,"%s","two ");
>> s+=sprintf(s,"%s","three ");
>> s+=sprintf(s,"%s","four ");
>> sprintf(s,"%s","five");
>> }
>> puts(s);
>>
>> then it takes 5.5 seconds. With snprintf() as you suggest, it takes 6.1
>> seconds. I thought you said every cycle matters?
>>
>
> <https://godbolt.org/z/954eccfsM>
>
> gcc (and I really mean gcc - no libraries are involved) generates
> identical code in both cases, and so I would assume (without testing)
> that the speed is the same.
Yeah, but that's taking my test literally, with string literals that the
compiler knows about.
It's possible that a call like sprintf(s, "%s", t) could be optimised
into a strcpy call and even inlined, without needing to know what t is,
however that is not what I'm seeing.
On the following revised test, the string to be concatenated is hidden
from the compiler. The sprintf loop is always slower than the strcat
loop, even using gcc-O3 and clang-O3 and cl /O2.
Maybe on your super-duper computer with link time optimisations and
such, it will be different. But this is what I'm observing with on Windows:
------------------------------------
c.c
------------------------------------
#include <stdio.h>
#include <time.h>
#include <string.h>
extern char* getstr(void);
char str[100000];
int main(void) {
char* s;
int n=1000000;
int t=clock();
for (int i=0; i<n; ++i) {
strcpy(str,getstr());
strcat(str,getstr());
strcat(str,getstr());
strcat(str,getstr());
strcat(str,getstr());
}
puts(str);
printf("%d\n",(int)strlen(str));
printf("time1 %d\n",(int)(clock()-t));
t=clock();
for (int i=0; i<n; ++i) {
s=str;
s+=sprintf(s,"%s",getstr());
s+=sprintf(s,"%s",getstr());
s+=sprintf(s,"%s",getstr());
s+=sprintf(s,"%s",getstr());
sprintf(s,"%s",getstr());
}
puts(str);
printf("%d\n",(int)strlen(str));
printf("time2 %d\n",(int)(clock()-t));
puts("");
}
------------------------------------
d.c
------------------------------------
char* getstr(void){return "ABCDEFGHIJKLMNOPQRSTUVWXYZ ";}
Build as:
gcc -O3 c.c d.c
Run as:
a # or ./a.out on certain OSes
This is what I get on Windows:
------------------------------------------------
C:\c>gcc --version
gcc (tdm64-1) 10.3.0
Copyright (C) 2020 Free Software Foundation, Inc.
<snip>
C:\c>gcc -O3 c.c d.c
C:\c>a
ABCDEFGHIJKLMNOPQRSTUVWXYZ ABCDEFGHIJKLMNOPQRSTUVWXYZ
ABCDEFGHIJKLMNOPQRSTUVWXYZ ABCDEFGHIJKLMNOPQRS
TUVWXYZ ABCDEFGHIJKLMNOPQRSTUVWXYZ
135
time1 144
ABCDEFGHIJKLMNOPQRSTUVWXYZ ABCDEFGHIJKLMNOPQRSTUVWXYZ
ABCDEFGHIJKLMNOPQRSTUVWXYZ ABCDEFGHIJKLMNOPQRS
TUVWXYZ ABCDEFGHIJKLMNOPQRSTUVWXYZ
135
time2 733
------------------------------------------------
clang -O3 gives 196/714.
DMC -o gives 421/1108.
lc -O gives 457/3155.
cl /2 gives 426/742
tcc gives 187/1438
bcc gives 208/1357
gcc -O0 gives 144/865
Finally this loop in my scripting language to do the same task:
function getstr=
"ABCDEFGHIJKLMNOPQRSTUVWXYZ "
end
to 1 million do
s:=getstr()
s+:=getstr()
s+:=getstr()
s+:=getstr()
s+:=getstr()
od
println s
println s.len
took 680ms; faster than gcc-O3 using sprintf.
Someone asserted that using sprintf to do this stuff was more efficient
than strcat; I disagreed. My findings suggested that strcat is faster.
You say your tests (on my program with fixed strings) would have them be
the same speed. So when is sprintf actually faster?
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2021-08-12 10:29 +0200 |
| Message-ID | <sf2m68$2q5$1@dont-email.me> |
| In reply to | #162343 |
On 12/08/2021 00:00, Bart wrote: > On 11/08/2021 21:47, David Brown wrote: >> On 11/08/2021 17:47, Bart wrote: > >>> Start with this: >>> >>> char str[100]; >>> char* s; >>> >>> Then a loop like this (all unoptimised code to stop it being optimised >>> out of existence): >> >> As you well know, timing unoptimised code is an utterly pointless >> exercise. You need to do something to make sure the operations are >> carried out, such as judicious use of volatile, or using "global" >> variables rather than local ones. Disabling optimisation is like >> comparing the speed of cars while forcing them to remain in first gear. > > No, it's ensuring that all of them follow the same route. Otherwise each > will find their own shortcuts, or may not bother going anywhere at all > if they see they're simply going to end up back home anyway. How many years have you been playing this game? Compilers can do what they want with the code - whatever flags you give them. Compilers can and do make optimisations despite your attempts to say "unoptimised". There is no such thing as "unoptimised" code, just as there is no such thing as "optimised" code (except in very small test cases). There is only a question of applying different types of transforms and passes, and of "trying harder" or not. You don't know the passes and transforms used by any particular compiler under any given circumstance with any given piece of code. (I believe that applies even to the tools you wrote yourself, as you only seem to know what they do by trial and error.) And when testing the speed of something, you give them a fair chance - you don't cripple them first. If you understood more than just your personally self-limited subset of C, perhaps read a bit of the standards, perhaps listened a bit when others explain things to you (instead of merely whining about it all being too complicated or not the way /you/ would have done it), you'd know this. And you would know how to write code in a way that you can test the speed of constructs /without/ throwing the baby out with the bathwater. >> >> <https://godbolt.org/z/954eccfsM> >> >> gcc (and I really mean gcc - no libraries are involved) generates >> identical code in both cases, and so I would assume (without testing) >> that the speed is the same. > > Yeah, but that's taking my test literally, with string literals that the > compiler knows about. > Yes. You gave what you thought was a test, and called a test, and I showed that it is not only irrelevant, but it shows that you were wrong. Now, /in general/ I would expect strcpy() and other related functions to be faster than using sprintf or snprintf. I would also expect them to be inlined much better. But in the particular case of your test, there is no difference. And in the particular cases Scott had been discussing, I imagine there are other factors that also mean sprintf is a more efficient option. (I have no idea what those circumstances might be - you'd have to ask him - but I doubt if Scott was thinking of code like yours.) > It's possible that a call like sprintf(s, "%s", t) could be optimised > into a strcpy call and even inlined, without needing to know what t is, > however that is not what I'm seeing. > > On the following revised test, the string to be concatenated is hidden > from the compiler. The sprintf loop is always slower than the strcat > loop, even using gcc-O3 and clang-O3 and cl /O2. > > Maybe on your super-duper computer with link time optimisations and > such, it will be different. But this is what I'm observing with on Windows: > I don't really care what you are getting "on Windows" - you don't know what you are testing, and don't even understand that you don't know what you are testing, so the details don't matter. You are not comparing apples with apples - you are not even comparing apples with oranges. You are comparing a mystery fruit with another mystery fruit which might or might not be the same kind. That is why I used godbolt for looking at the details - there we /do/ know what is being tested, with the results being assembly that we can compare, dependent on the source code, the compiler chosen, and the flags - but not libraries, OS's, computers, or any other messy details. (Obviously such code generation comparisons only work for some kinds of testing, but they are vastly better than "I tried using some toolchain I have, but I don't know what it is, how it works or how to use it".) Your new test code does stop gcc (trunk version, which is a development version of gcc 12) from turning the sprintf into strcat. Without knowing any other details, I would expect the sprintf version to be slower. > > Someone asserted that using sprintf to do this stuff was more efficient > than strcat; I disagreed. My findings suggested that strcat is faster. > All your findings show is that for your setup and your test programs, strcat is faster. Neither your setup nor your test program are realistic for real coding - certainly not in circumstances where the programmer understands about execution speed and in a program for which that is important. Don't get me wrong here - I fully expect that for a simple short test string, strcat will be faster than sprintf. I just don't think you have thought about any possible complicating circumstances or effects that occur in the real programming world, before leaping off with another "test" program in your eagerness to "prove" someone wrong (and then, inevitably, to throw in some code in one of your personal languages to "prove" that it is "better" than C). > You say your tests (on my program with fixed strings) would have them be > the same speed. So when is sprintf actually faster? Since I am not making the claim about sprintf and strcat speeds, and have not used them in a way that lets me judge their relative speeds in different circumstances, I can only make some guesses as to when sprintf might be faster. First, note that a library implementation of sprintf could quite happily have an optimisation that first checks if the format string is "%s" and has dedicated handling for that rather common case. This would mean sprintf, used like this, would be about as fast as strcpy. Second, note that if you are dealing with very long strings, then strcat() must traverse the entire string so far in order to find the end. The sprintf version does not. As the size of the strings grow, this traversal will totally dominate the timing, making sprintf faster. (Even more efficient would be functions like strlcat, or the other variations that have been made over the years that return more useful results than strcat that avoid the need to re-establish the length of the string every time. It would be nice to have seen some of these standardised and codified in the C standards.)
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-08-12 12:10 +0100 |
| Message-ID | <sf2vk1$t6o$1@dont-email.me> |
| In reply to | #162350 |
On 12/08/2021 09:29, David Brown wrote:
> On 12/08/2021 00:00, Bart wrote:
> Yes. You gave what you thought was a test, and called a test, and I
> showed that it is not only irrelevant, but it shows that you were wrong.
>
>
> Now, /in general/ I would expect strcpy() and other related functions to
> be faster than using sprintf or snprintf. I would also expect them to
> be inlined much better.
Malcolm suggested that use of strcat was fine for assembling short
strings, SL suggested using snprintf every time because 'every cycle
counts'.
However, if compilers can optimise that aggressively, why don't they
also optimise strcat into sprintf if it is actually faster?
My assumption was that in real code, strcat and sprintf are actually
being called as functions. Specifically, as functions in an internal
library that is already compiled.
In that case, you want to know whether CALLING strcat in a loop was
faster or slower than calling sprintf in a loop.
One way of ensuring that optimisers don't interfere with such code (by
ending up not calling a function, or not doing anything) is to turn off
optimisation. Or by writing a more elaborate test, but even then you can
never be sure what a compiler might sneakily be doing to invalid your tests.
As it turned out, my more elaborate, optimised test confirmed the
results of the simpler, non-optimised one - strcat loops were faster.
(Another way of doing it is to call strcat and sprintf via the FFI of
another language, eg. mine, which also confirmed it.)
>> It's possible that a call like sprintf(s, "%s", t) could be optimised
>> into a strcpy call and even inlined, without needing to know what t is,
>> however that is not what I'm seeing.
>>
>> On the following revised test, the string to be concatenated is hidden
>> from the compiler. The sprintf loop is always slower than the strcat
>> loop, even using gcc-O3 and clang-O3 and cl /O2.
>>
>> Maybe on your super-duper computer with link time optimisations and
>> such, it will be different. But this is what I'm observing with on Windows:
>>
>
> I don't really care what you are getting "on Windows" - you don't know
> what you are testing, and don't even understand that you don't know what
> you are testing, so the details don't matter. You are not comparing
> apples with apples - you are not even comparing apples with oranges.
> You are comparing a mystery fruit with another mystery fruit which might
> or might not be the same kind.
>
> That is why I used godbolt for looking at the details - there we /do/
> know what is being tested,
That doesn't tell you much about non-optimising compilers, or attempts
to call C functions from other languages, which is MY interest.
You may also be distributing C source and don't know what someone is
going to do with it.
The optimisations are just a bonus when you eventually get around to
using an optimising C compiler in some cases, but your program must work
adequately without that.
So please accept that we have different aims and different interests.
> Don't get me wrong here - I fully expect that for a simple short test
> string, strcat will be faster than sprintf.
Try this version of getstr():
char* getstr(void){
enum {N=10000};
static char* s=NULL;
if (s) return s;
s=malloc(N+1);
memset(s,'A',N);
s[N]=0;
return s;
}
You may need to adjust the timing loop in the other module for fewer
iterations, and ensure the str[] array is big enough for 5 copies. (And
maybe comment out the bits that print the strings!)
You might be surprised at the results.
(With N=1000000 here, and 100 iterations, gcc-O3 gave me figures of
440/2320 msec - sprintf was still several times slower.)
> I just don't think you have
> thought about any possible complicating circumstances or effects that
> occur in the real programming world, before leaping off with another
> "test" program in your eagerness to "prove" someone wrong (and then,
> inevitably, to throw in some code in one of your personal languages to
> "prove" that it is "better" than C).
No, I was just fed up with Scott Lurndal treating me with contempt. He
said something I'd challenged then refused to back it up, claiming he
was too busy.
That interpreted code (which uses counted strings) was as fast as the C
loop using sprintf was a bit of a surprise to me, but I found it
interesting to share.
If you don't like me using my personal languge, here it is in Python:
--------------------
def getstr():
return "ABCDEFGHIJKLMNOPQRSTUVWXYZ "
for i in range(1000000):
s=""
s+=getstr()
s+=getstr()
s+=getstr()
s+=getstr()
s+=getstr()
print (s)
print (len(s))
--------------------
This took 1.8 seconds with CPython (1/2 to 1/3 the speed of the sprintf
loop) and 0.2 seconds with PyPy (several times the speed of the C). This
language uses counted strings too.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2021-08-12 16:28 +0200 |
| Message-ID | <sf3b5u$eou$1@dont-email.me> |
| In reply to | #162352 |
On 12/08/2021 13:10, Bart wrote:
> On 12/08/2021 09:29, David Brown wrote:
>> On 12/08/2021 00:00, Bart wrote:
>
>> Yes. You gave what you thought was a test, and called a test, and I
>> showed that it is not only irrelevant, but it shows that you were wrong.
>>
>>
>> Now, /in general/ I would expect strcpy() and other related functions to
>> be faster than using sprintf or snprintf. I would also expect them to
>> be inlined much better.
>
> Malcolm suggested that use of strcat was fine for assembling short
> strings, SL suggested using snprintf every time because 'every cycle
> counts'.
>
Other people can answer for their own opinions and comments.
> However, if compilers can optimise that aggressively, why don't they
> also optimise strcat into sprintf if it is actually faster?
>
Did you read what I wrote? It is likely, as far as I can guess, that
sprintf will be faster than strcat in cases where you have long strings
and where the return value from sprintf can be used to avoid re-scanning
strings to find their endpoints. I would imagine that is a little too
niche for optimisations, and would also be dependent on the library
implementation. This makes it very different from optimising library
calls into inlined code or clearly simpler functions.
There are always limits to optimisation - sometimes an optimisation is
theoretically possible, but a given compiler doesn't implement it. And
there are often cases where an optimisation might seem to be obviously
valid, when there are actually good reasons why the compiler can't be
sure the optimisation is correct. The folks that write high-end
compilers are really good at making sure there are no unwarranted
assumptions in their optimisations.
> My assumption was that in real code, strcat and sprintf are actually
> being called as functions. Specifically, as functions in an internal
> library that is already compiled.
>
That was an assumption - it was not a requirement, either from Scott's
posts or from your own test code. If your statements rely on that kind
of thing, say so.
> In that case, you want to know whether CALLING strcat in a loop was
> faster or slower than calling sprintf in a loop.
>
> One way of ensuring that optimisers don't interfere with such code (by
> ending up not calling a function, or not doing anything) is to turn off
> optimisation. Or by writing a more elaborate test, but even then you can
> never be sure what a compiler might sneakily be doing to invalid your
> tests.
Turning off optimisations is a silly way to do this - it is a silly way
to do anything, really. But you didn't learn that the last 99 times it
has come up, so I don't expect you to have a light-bulb moment here either.
>
> As it turned out, my more elaborate, optimised test confirmed the
> results of the simpler, non-optimised one - strcat loops were faster.
>
No one disputes the expected relative speeds of typical library
implementations of strcat and sprintf when dealing with short strings in
code such as these examples. That does not make your tests helpful or
relevant.
>
>>> It's possible that a call like sprintf(s, "%s", t) could be optimised
>>> into a strcpy call and even inlined, without needing to know what t is,
>>> however that is not what I'm seeing.
>>>
>>> On the following revised test, the string to be concatenated is hidden
>>> from the compiler. The sprintf loop is always slower than the strcat
>>> loop, even using gcc-O3 and clang-O3 and cl /O2.
>>>
>>> Maybe on your super-duper computer with link time optimisations and
>>> such, it will be different. But this is what I'm observing with on
>>> Windows:
>>>
>>
>> I don't really care what you are getting "on Windows" - you don't know
>> what you are testing, and don't even understand that you don't know what
>> you are testing, so the details don't matter. You are not comparing
>> apples with apples - you are not even comparing apples with oranges.
>> You are comparing a mystery fruit with another mystery fruit which might
>> or might not be the same kind.
>>
>> That is why I used godbolt for looking at the details - there we /do/
>> know what is being tested,
>
> That doesn't tell you much about non-optimising compilers, or attempts
> to call C functions from other languages, which is MY interest.
No one (sane and knowledgable) cares about the speed of code generated
by non-optimising compilers, or compilers with the optimisation turned off.
No one (sane and knowledgable) who calls library functions from another
language cares about the results of a compiler running test code - they
care about the /library/, its implementation, and efficiency.
So if you are interested in the performance of strcat and sprintf when
used from a different language, look at the library, not the C compiler.
Examine and test things that are /relevant/, either to the discussions
here or relevant to your own interests.
>
> You may also be distributing C source and don't know what someone is
> going to do with it.
>
> The optimisations are just a bonus when you eventually get around to
> using an optimising C compiler in some cases, but your program must work
> adequately without that.
>
> So please accept that we have different aims and different interests.
>
>> Don't get me wrong here - I fully expect that for a simple short test
>> string, strcat will be faster than sprintf.
>
> Try this version of getstr():
>
> char* getstr(void){
> enum {N=10000};
> static char* s=NULL;
>
> if (s) return s;
>
> s=malloc(N+1);
> memset(s,'A',N);
> s[N]=0;
> return s;
> }
>
> You may need to adjust the timing loop in the other module for fewer
> iterations, and ensure the str[] array is big enough for 5 copies. (And
> maybe comment out the bits that print the strings!)
>
> You might be surprised at the results.
>
> (With N=1000000 here, and 100 iterations, gcc-O3 gave me figures of
> 440/2320 msec - sprintf was still several times slower.)
>
I haven't claimed that sprintf is faster - I merely gave a possible
explanation why it might be faster, for some situations.
But looking at the code generated for your latest change, I notice
something vital - gcc (on godbolt) is converting many of the "strcat"
calls into "stpcpy" calls. stpcpy is not a standard C function, but is
(AFAICS) in POSIX standards. It is like strcpy, except it returns a
pointer to the end of the combined string - and is thus vastly more
efficient in this case.
Try your timings with "-std=c99", which stops gcc from using functions
that are not in the C standard (and, obviously, not in the source code).
There is a suggestion to add stpcpy (and spncpy) to the C standards:
<http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2352.htm>
(These threads do sometimes end up revealing interesting things.)
>
>> I just don't think you have
>> thought about any possible complicating circumstances or effects that
>> occur in the real programming world, before leaping off with another
>> "test" program in your eagerness to "prove" someone wrong (and then,
>> inevitably, to throw in some code in one of your personal languages to
>> "prove" that it is "better" than C).
>
> No, I was just fed up with Scott Lurndal treating me with contempt. He
> said something I'd challenged then refused to back it up, claiming he
> was too busy.
>
> That interpreted code (which uses counted strings) was as fast as the C
> loop using sprintf was a bit of a surprise to me, but I found it
> interesting to share.
>
> If you don't like me using my personal languge, here it is in Python:
>
> --------------------
> def getstr():
> return "ABCDEFGHIJKLMNOPQRSTUVWXYZ "
>
> for i in range(1000000):
> s=""
> s+=getstr()
> s+=getstr()
> s+=getstr()
> s+=getstr()
> s+=getstr()
>
> print (s)
> print (len(s))
> --------------------
>
> This took 1.8 seconds with CPython (1/2 to 1/3 the speed of the sprintf
> loop) and 0.2 seconds with PyPy (several times the speed of the C). This
> language uses counted strings too.
Python is much more useful as an example, since it is something other
people can and do use.
Counted strings are going to do better in a test like this. There are
many different data structures that can be used to hold string data,
each with their benefits and disadvantages. That is another reason why
blanket statements (whether by you or by Scott) without context about
the relative speed of two functions or techniques are usually
meaningless. You have to compare real-world speeds in the situations
you are using them.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2021-08-12 08:03 -0700 |
| Message-ID | <a26053df-a375-48b1-a3bd-6e8a1caf4557n@googlegroups.com> |
| In reply to | #162354 |
On Thursday, 12 August 2021 at 15:28:27 UTC+1, David Brown wrote: > On 12/08/2021 13:10, Bart wrote: > > On 12/08/2021 09:29, David Brown wrote: > >> On 12/08/2021 00:00, Bart wrote: > > > >> Yes. You gave what you thought was a test, and called a test, and I > >> showed that it is not only irrelevant, but it shows that you were wrong. > >> > >> > >> Now, /in general/ I would expect strcpy() and other related functions to > >> be faster than using sprintf or snprintf. I would also expect them to > >> be inlined much better. > > > > Malcolm suggested that use of strcat was fine for assembling short > > strings, SL suggested using snprintf every time because 'every cycle > > counts'. > > > Other people can answer for their own opinions and comments. > > Python is much more useful as an example, since it is something other > people can and do use. > > Counted strings are going to do better in a test like this. There are > many different data structures that can be used to hold string data, > each with their benefits and disadvantages. That is another reason why > blanket statements (whether by you or by Scott) without context about > the relative speed of two functions or techniques are usually > meaningless. You have to compare real-world speeds in the situations > you are using them. > Very few people use C for heavy string processing. They use C for a little bit of minor string processing in programs which are basically doing something else. And, interestingly enough, C is a good choice for implementing a string processing package itself. But C isn't a good choice for the application- specific code which calls that string processing package. If you are just doing minor string processing, efficiency doesn't matter. The processing time wil be dominated by other things, or it will be so short that it's not an issue at all. Not all cycles are equal, because most machines spend a lot of cycles idling. Only a cycle which the user/customer notices is worth eliminating. If you are doing major string processing, my experience here is with bioinformatics, where data is often either large numbers (tens of thousands) of strings representing genes, of a few hundred to low thousands of characters long, or small numbers (tens) of string representing entire neucleotide sequences, which can be up to a billion characters long (the human genome is 3,000 mega base pairs, spread over 22 normal chromosomes and two sex chromosomes). However time pressures aren't tight - a few hours to do an analysis might not be good, but it's not catastrophic. In practise you need to avoid N by N operations. I used MatLab, because it was lab policy that everyone used MatLab, not because of its string handling capabilities.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2021-08-12 15:52 +0000 |
| Message-ID | <qtbRI.4636$Mc.1527@fx34.iad> |
| In reply to | #162354 |
David Brown <david.brown@hesbynett.no> writes: >On 12/08/2021 13:10, Bart wrote: >> On 12/08/2021 09:29, David Brown wrote: >>> On 12/08/2021 00:00, Bart wrote: >> >>> Yes. You gave what you thought was a test, and called a test, and I >>> showed that it is not only irrelevant, but it shows that you were wrong. >>> >>> >>> Now, /in general/ I would expect strcpy() and other related functions to >>> be faster than using sprintf or snprintf. I would also expect them to >>> be inlined much better. >> >> Malcolm suggested that use of strcat was fine for assembling short >> strings, SL suggested using snprintf every time because 'every cycle >> counts'. >> > >Other people can answer for their own opinions and comments. Except I have no interest in arguing with Bart. Particularly when he misrepresents what I said by conflating two different arguments.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2021-08-12 17:55 +0200 |
| Message-ID | <sf3g9s$jqi$1@dont-email.me> |
| In reply to | #162357 |
On 12/08/2021 17:52, Scott Lurndal wrote: > David Brown <david.brown@hesbynett.no> writes: >> On 12/08/2021 13:10, Bart wrote: >>> On 12/08/2021 09:29, David Brown wrote: >>>> On 12/08/2021 00:00, Bart wrote: >>> >>>> Yes. You gave what you thought was a test, and called a test, and I >>>> showed that it is not only irrelevant, but it shows that you were wrong. >>>> >>>> >>>> Now, /in general/ I would expect strcpy() and other related functions to >>>> be faster than using sprintf or snprintf. I would also expect them to >>>> be inlined much better. >>> >>> Malcolm suggested that use of strcat was fine for assembling short >>> strings, SL suggested using snprintf every time because 'every cycle >>> counts'. >>> >> >> Other people can answer for their own opinions and comments. > > Except I have no interest in arguing with Bart. Particularly when > he misrepresents what I said by conflating two different arguments. > Fair enough. If you think expanding on your posts might be of interest to others here, then please do so.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-08-12 16:59 +0100 |
| Message-ID | <sf3ggk$m9i$1@dont-email.me> |
| In reply to | #162354 |
On 12/08/2021 15:28, David Brown wrote: > On 12/08/2021 13:10, Bart wrote: >> That doesn't tell you much about non-optimising compilers, or attempts >> to call C functions from other languages, which is MY interest. > > No one (sane and knowledgable) cares about the speed of code generated > by non-optimising compilers, or compilers with the optimisation turned off. > > No one (sane and knowledgable) who calls library functions from another > language cares about the results of a compiler running test code - they > care about the /library/, its implementation, and efficiency. That is just your opinion. Many of us do care about it, since unoptimised code can give highly useful trade-offs (like 100 times faster build speeds - ask any Rust developer whether they would like a 100x faster build just once). Any native code non-optimising compiler can still generate code that will wipe the floor with any interpreted scripting language. So there is a place for such implementations. (I'd also imagine that my non-optimising compilers would generate faster code on your machine, than gcc-O3 on mine.) > So if you are interested in the performance of strcat and sprintf when > used from a different language, look at the library, not the C compiler. You could just write a benchmark if the results are actually in dispute. Just stating an opinion wouldn't be enough for Scott, but then neither are hard facts apparently. >> (With N=1000000 here, and 100 iterations, gcc-O3 gave me figures of >> 440/2320 msec - sprintf was still several times slower.) >> > > I haven't claimed that sprintf is faster - I merely gave a possible > explanation why it might be faster, for some situations. You said it's probably faster for short strings. It seems it can be faster for much longer ones, but presumably not quoye as long as DFS's. > But looking at the code generated for your latest change, I notice > something vital - gcc (on godbolt) is converting many of the "strcat" > calls into "stpcpy" calls. stpcpy is not a standard C function, but is > (AFAICS) in POSIX standards. It is like strcpy, except it returns a > pointer to the end of the combined string - and is thus vastly more > efficient in this case. strcat is a very simple function - at least in spec - and thus could lend itself easily to optimisation. I use it extensively from outside of C, but usually in cases that are not speed-critical (such as generating diagnostic listings, or synthesising command strings for system()). But I rarely use any *printf functions via FFIs; format strings just don't belong outside of C. For building text files in-memory by concatenating, a method I also use all the time, I use streamlined functions of my own. > That is another reason why > blanket statements (whether by you or by Scott) without context about > the relative speed of two functions or techniques are usually > meaningless. You have to compare real-world speeds in the situations > you are using them. Funny how one remark by Scott that was likely erroneous and misleading attracts virtually no comment. But someone TRIES to show that they are wrong, and you try to annihilate them.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2021-08-12 19:44 +0200 |
| Message-ID | <sf3mm1$4kk$1@dont-email.me> |
| In reply to | #162359 |
On 12/08/2021 17:59, Bart wrote: > On 12/08/2021 15:28, David Brown wrote: >> On 12/08/2021 13:10, Bart wrote: > >>> That doesn't tell you much about non-optimising compilers, or attempts >>> to call C functions from other languages, which is MY interest. >> >> No one (sane and knowledgable) cares about the speed of code generated >> by non-optimising compilers, or compilers with the optimisation turned >> off. >> >> No one (sane and knowledgable) who calls library functions from another >> language cares about the results of a compiler running test code - they >> care about the /library/, its implementation, and efficiency. > > That is just your opinion. Many of us do care about it, since > unoptimised code can give highly useful trade-offs (like 100 times > faster build speeds - ask any Rust developer whether they would like a > 100x faster build just once). I have no experience of Rust. But I can tell assure you that "gcc -O0" does not run 100 times faster than "gcc -O2", and is nowhere near as useful. It is rare for the speed of C compilation - even when optimised - to be of a significant hinder to professional (or serious hobby) C developers. I'm sure there are /some/ people out there regularly recompiling the Linux kernel natively on a Pi 1, but there can't be many. There are possibly some who mistakenly think compilation without optimisation is a good way to do a quick check of code quality. Regardless, how many of those that you think intentionally compile with optimisations disabled are particularly interested in the run-time speed of the resulting code? > > Any native code non-optimising compiler can still generate code that > will wipe the floor with any interpreted scripting language. > For most (for a very vague, hand-waving and unsubstantiated measurement of "most") code, run-time speed is not particularly important. I did not say that people don't run compilers without optimisations. I said that people who care about the speed of the results don't run compilers without optimisations. (Actually, I did miss out a class of programmers who may run compilers without optimisations, while caring about speed. There are some commercial toolchains where there are price differences for licenses or versions with and without optimisations.) > So there is a place for such implementations. > > (I'd also imagine that my non-optimising compilers would generate faster > code on your machine, than gcc-O3 on mine.) > So what? If I want code to be fast, I enable optimisations. If I want it to be small, I enable optimisations. If I want static error checking to catch errors in my code at the earliest opportunity, I enable optimisations. If I don't care about any of that, then C is highly unlikely to be the right language for the task. I cannot imagine any circumstance in which I'd want to disable optimisation during code development. >> So if you are interested in the performance of strcat and sprintf when >> used from a different language, look at the library, not the C compiler. > > You could just write a benchmark if the results are actually in dispute. > Just stating an opinion wouldn't be enough for Scott, but then neither > are hard facts apparently. > No one has given any hard facts to counter his personal experience, and your opinions are not likely to be attributed much weight. (I know /I/ can't write a benchmark to counter his post, because I believe he was thinking of particular use-cases, and I don't know what they are.) Nevertheless, my point stands - if you are interested in the speed of library functions, then concentrate on the library functions, not the compiler. (That's assuming you know what library you are using, of course.) > >>> (With N=1000000 here, and 100 iterations, gcc-O3 gave me figures of >>> 440/2320 msec - sprintf was still several times slower.) >>> >> >> I haven't claimed that sprintf is faster - I merely gave a possible >> explanation why it might be faster, for some situations. > > You said it's probably faster for short strings. It seems it can be > faster for much longer ones, but presumably not quoye as long as DFS's. > I said sprintf is going to be faster for /longer/ strings, because (in code sequences like your test code) it avoids the need to continually re-scan strings to find their length. That is, I think, quite obvious. (It's always possible that I jumbled my words in a post and wrote the opposite of what I meant. I'm sure you'll let me know if that was the case.) >> But looking at the code generated for your latest change, I notice >> something vital - gcc (on godbolt) is converting many of the "strcat" >> calls into "stpcpy" calls. stpcpy is not a standard C function, but is >> (AFAICS) in POSIX standards. It is like strcpy, except it returns a >> pointer to the end of the combined string - and is thus vastly more >> efficient in this case. > > strcat is a very simple function - at least in spec - and thus could > lend itself easily to optimisation. > Yes. > I use it extensively from outside of C, but usually in cases that are > not speed-critical (such as generating diagnostic listings, or > synthesising command strings for system()). > > But I rarely use any *printf functions via FFIs; format strings just > don't belong outside of C. > Format strings of various sorts are used in many languages. But I can fully understand not wanting C-specific printf and format strings in other languages. > For building text files in-memory by concatenating, a method I also use > all the time, I use streamlined functions of my own. > >> That is another reason why >> blanket statements (whether by you or by Scott) without context about >> the relative speed of two functions or techniques are usually >> meaningless. You have to compare real-world speeds in the situations >> you are using them. > > > Funny how one remark by Scott that was likely erroneous and misleading > attracts virtually no comment. But someone TRIES to show that they are > wrong, and you try to annihilate them. > I don't know that Scott's remark was erroneous or misleading - but it could certainly have helped with some more explanation. (Then we might be in a position to judge better whether or not it was correct.) I haven't been trying to "annihilate" you - that's paranoia. I have not even disagreed with your main point about strcat being faster (in general) than sprintf - nor has anyone else, I think. But I /have/ disagreed with some of your methods, and tried to explain why and how to improve on them.
[toc] | [prev] | [next] | [standalone]
| From | antispam@math.uni.wroc.pl |
|---|---|
| Date | 2021-08-12 19:02 +0000 |
| Message-ID | <sf3r8r$25m$1@z-news.wcss.wroc.pl> |
| In reply to | #162363 |
David Brown <david.brown@hesbynett.no> wrote:
> On 12/08/2021 17:59, Bart wrote:
> > On 12/08/2021 15:28, David Brown wrote:
> >> On 12/08/2021 13:10, Bart wrote:
> >
> >>> (With N=1000000 here, and 100 iterations, gcc-O3 gave me figures of
> >>> 440/2320 msec - sprintf was still several times slower.)
> >>>
> >>
> >> I haven't claimed that sprintf is faster - I merely gave a possible
> >> explanation why it might be faster, for some situations.
> >
> > You said it's probably faster for short strings. It seems it can be
> > faster for much longer ones, but presumably not quoye as long as DFS's.
> >
>
> I said sprintf is going to be faster for /longer/ strings, because (in
> code sequences like your test code) it avoids the need to continually
> re-scan strings to find their length. That is, I think, quite obvious.
Well, if you do not see sources it is not obvious. 'strlen'
and 'strcpy' may have highly optimized implementation, while
'sprintf' could use some slow general code. On my machine
'sprintf' clearly is optimized, but takes essentially the
same time as 'strcpy' + 'strlen'. Interestingly, replacing
'strcpy' by 'memcpy' gave slower code.
If you consider that Bart is using what looks like quite recent
gcc toolchain on old version of Window, he may get quite strange
mix of library functions...
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-08-12 20:22 +0100 |
| Message-ID | <sf3sdn$fjc$1@dont-email.me> |
| In reply to | #162363 |
On 12/08/2021 18:44, David Brown wrote: > On 12/08/2021 17:59, Bart wrote: >> That is just your opinion. Many of us do care about it, since >> unoptimised code can give highly useful trade-offs (like 100 times >> faster build speeds - ask any Rust developer whether they would like a >> 100x faster build just once). > > I have no experience of Rust. But I can tell assure you that "gcc -O0" > does not run 100 times faster than "gcc -O2", and is nowhere near as > useful. Unoptimised doesn't mean gcc -O0. For example: C:\oldqx>tm gcc -O0 qq.c -oqqnop.exe TM: 5.05 C:\oldqx>tm gcc -O2 qq.c -oqqopt.exe TM: 16.91 C:\oldqx>tm tcc qq.c -oqqtcc.exe TM: 0.17 gcc-O0 was ony 3.2 times as fast as gcc-O2. But tcc was pretty much 100 times as fast (and 123 times as fast as gcc-O3). As for runtimes: C:\oldqx>tm qqopt fib fib(36) = 14930352 TM: 2.44 C:\oldqx>tm qqnop fib fib(36) = 14930352 TM: 4.28 C:\oldqx>tm qqtcc fib fib(36) = 14930352 TM: 5.24 Here, the trade-off for 100x faster compilation is that runtime is 2.14 times as long. But there are other non-optimising compilers: C:\oldqx>tm mm qq Compiling qq.m---------- to qq.exe TM: 0.20 C:\oldqx>tm qq -fn fib fib(36) = 14930352 TM: 4.11 About 77x faster compilatiOn, and 1.7 times longer runtime. Or I can do this: C:\oldqx>tm qq -asm fib fib(36) = 14930352 TM: 0.74 So 77x faster compilation /and/ 3.3x FASTER runtime. Using my own ways of optimising programs. >> Any native code non-optimising compiler can still generate code that >> will wipe the floor with any interpreted scripting language. >> > > For most (for a very vague, hand-waving and unsubstantiated measurement > of "most") code, run-time speed is not particularly important. Well, the difference between code from gcc-O3 and tcc is generally just over 2:1, and that's for computationally intensive code. You're now saying that runtime speed isn't important after all. I don't get you. Isn't that the main advantage of the optimisation flag on a compiler? You say here: > No one (sane and knowledgable) cares about the speed of code generated > by non-optimising compilers, or compilers with the optimisation turned > off. You seemed utterly dismissive about non-optimising compilers under any circumstances. Now you seem to be acknowledging that perhaps their somewhat poorer performance doesn't matter for a lot of code. > I did not say that people don't run compilers without optimisations. I > said that people who care about the speed of the results don't run > compilers without optimisations. Those people may care about having a lightweight, small-footprint and nippy product; about not having to hang about to build any app; about not needing to deal with innumerable, obscure compiler options; about not having to mess with writing makefiles to ensure that incremental compilation will work - just compile the lot; about creating an app which doesn't care what compiler a third party may use, or which options they choose. They might also want a development system that is responsive even on cheaper, low-end machines. > If I want code to be fast, I enable optimisations. If I want it to be > small, I enable optimisations. If I use -Os on the above qq.c file, I get a 736KB executable. With my MM compiler, it's 748KB; 1.6% bigger, but gcc took 67x longer, and it runs a bit more slowly [than -O2].
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2021-08-12 11:10 -0700 |
| Message-ID | <87h7fuilfh.fsf@nosuchdomain.example.com> |
| In reply to | #162359 |
Bart <bc@freeuk.com> writes:
[...]
> Funny how one remark by Scott that was likely erroneous and misleading
> attracts virtually no comment. But someone TRIES to show that they are
> wrong, and you try to annihilate them.
It's even funnier that I replied to Scott's post, cited your results,
and pointed out that snprintf() is likely to have substantial overhead.
I suppose that doesn't count, since it doesn't fit into your narrative.
And it's hilarious that you have yet to acknowledge that you lied about
something I wrote here, falsely claiming that I had said that the end
user must obtain the components for a C implementation from different
sources and mix and match them.
I don't expect you to admit that you liked, but you could at least
acknowledge that I didn't say what you claim I said.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-08-12 23:17 +0100 |
| Message-ID | <sf46lp$nif$1@dont-email.me> |
| In reply to | #162365 |
On 12/08/2021 19:10, Keith Thompson wrote: > Bart <bc@freeuk.com> writes: > [...] >> Funny how one remark by Scott that was likely erroneous and misleading >> attracts virtually no comment. But someone TRIES to show that they are >> wrong, and you try to annihilate them. > > It's even funnier that I replied to Scott's post, cited your results, > and pointed out that snprintf() is likely to have substantial overhead. > I suppose that doesn't count, since it doesn't fit into your narrative. 'virtually'. Compare the total lines posted trashing my results. > And it's hilarious that you have yet to acknowledge that you lied about > something I wrote here, falsely claiming that I had said that the end > user must obtain the components for a C implementation from different > sources and mix and match them. So then you admit that a C implementation usually comes as a ready-made bundle WITH a compiler, headers, library (or arrangements for the library) INCLUDING functions like printf, and any other tools necessary to turn source into runnable code? Because it seems to me that you've always claimed these parts as distinct.
[toc] | [prev] | [next] | [standalone]
Page 13 of 20 — ← Prev page 1 … 11 12 [13] 14 15 … 20 Next page →
Back to top | Article view | comp.lang.c
csiph-web