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 14 of 20 — ← Prev page 1 … 12 13 [14] 15 16 … 20 Next page →
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2021-08-12 16:52 -0700 |
| Message-ID | <87czqii5kd.fsf@nosuchdomain.example.com> |
| In reply to | #162370 |
Bart <bc@freeuk.com> writes:
[SNIP]
>> 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?
I do not "admit" it. The word "admit" implies that I've previously
stated otherwise. I have not. I certainly *acknowledge* it.
> Because it seems to me that you've always claimed these parts as distinct.
Yes, depending on what you mean by "distinct". The distinct components
are, in many cases, provided as a bundle. Sometimes the components are
all provided by the same provider. Sometimes they're provided by two or
more providers and somebody else creates the bundle, perhaps as part of
something larger. (For example, both gcc and glibc are pre-installed on
Ubuntu, at least in the configurations I've used.)
It is not typical for an end user to assemble the distinct components
into a working implementation.
Even if, for example, the compiler and the standard library are
tightly couple and provided in a single downloadable bundle, there
is still a clear internal distinction between them. There's no
particular requirement that they must be internally distinct, but
they (almost?) always are in practice, because it doesn't make
sense for them not to be.
Here's what you wrote:
| According to Keith, every C implementation consists of assorted
| components like this:
|
| * Possibly, a discrete preprocessor
| * Compiler
| * Standard headers
| * Assembler
| * Linker
| * Standard library
| * Extensions
|
| which everyone who ever installs an implementation is expected to obtain
| from different sources and mix and match to create a custom C system.
That is false; I did not say that. Typically "everyone who ever
installs an implementation" installs some bundle that already includes
the components that make up a C implementation.
Is it possible that you actually believed when you made that statement
that that was what I had said? I don't know *how* you could have
reached that conclusion.
--
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 | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2021-08-12 22:22 -0400 |
| Message-ID | <CHkRI.21412$6p.6928@fx36.iad> |
| In reply to | #162371 |
On 8/12/21 7:52 PM, Keith Thompson wrote: > Bart <bc@freeuk.com> writes: > [SNIP] >>> 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? > > I do not "admit" it. The word "admit" implies that I've previously > stated otherwise. I have not. I certainly *acknowledge* it. > >> Because it seems to me that you've always claimed these parts as distinct. > > Yes, depending on what you mean by "distinct". The distinct components > are, in many cases, provided as a bundle. Sometimes the components are > all provided by the same provider. Sometimes they're provided by two or > more providers and somebody else creates the bundle, perhaps as part of > something larger. (For example, both gcc and glibc are pre-installed on > Ubuntu, at least in the configurations I've used.) > > It is not typical for an end user to assemble the distinct components > into a working implementation. > > Even if, for example, the compiler and the standard library are > tightly couple and provided in a single downloadable bundle, there > is still a clear internal distinction between them. There's no > particular requirement that they must be internally distinct, but > they (almost?) always are in practice, because it doesn't make > sense for them not to be. > > Here's what you wrote: > > | According to Keith, every C implementation consists of assorted > | components like this: > | > | * Possibly, a discrete preprocessor > | * Compiler > | * Standard headers > | * Assembler > | * Linker > | * Standard library > | * Extensions > | > | which everyone who ever installs an implementation is expected to obtain > | from different sources and mix and match to create a custom C system. > > That is false; I did not say that. Typically "everyone who ever > installs an implementation" installs some bundle that already includes > the components that make up a C implementation. > > Is it possible that you actually believed when you made that statement > that that was what I had said? I don't know *how* you could have > reached that conclusion. > Slight disagreement. To the Standard, there is ONLY a complete implementation. That implementation might be buildable out of building blocks, but as far as the Standard is concerned, it is the responsibility of the entity that puts it all together to make sure the results is 'Conforming'. GCC, for example, it just a piece of an implementation, mostly the piece called the 'compiler' (which I don't think is actually a defined term for the Standard), and includes documentation for how to combine it with the other pieces. THere are library vendors who will provide other pieces of the implementation, and documentation of how to combine it with other pieces to make an implementation. THen someone takes these pieces and creates the actual implementation. They depend on the documentation from the various component vendors to help them ensure that they make a 'Conforming' Implementation. If they did the job right, it will be (or at least as close as practical software will be to meeting some specification). Sometimes the integrator intentionally makes the combination non-conforming because that meets their needs better (perhaps adding a non-conforming extension to the implementation). This is perfectly fine too, 'Conformance' isn't the only criteria to judge an implementation by.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2021-08-12 19:51 -0700 |
| Message-ID | <878s16hxb6.fsf@nosuchdomain.example.com> |
| In reply to | #162372 |
Richard Damon <Richard@Damon-Family.org> writes:
> On 8/12/21 7:52 PM, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>> [SNIP]
>>>> 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?
>>
>> I do not "admit" it. The word "admit" implies that I've previously
>> stated otherwise. I have not. I certainly *acknowledge* it.
>>
>>> Because it seems to me that you've always claimed these parts as distinct.
>>
>> Yes, depending on what you mean by "distinct". The distinct components
>> are, in many cases, provided as a bundle. Sometimes the components are
>> all provided by the same provider. Sometimes they're provided by two or
>> more providers and somebody else creates the bundle, perhaps as part of
>> something larger. (For example, both gcc and glibc are pre-installed on
>> Ubuntu, at least in the configurations I've used.)
>>
>> It is not typical for an end user to assemble the distinct components
>> into a working implementation.
>>
>> Even if, for example, the compiler and the standard library are
>> tightly couple and provided in a single downloadable bundle, there
>> is still a clear internal distinction between them. There's no
>> particular requirement that they must be internally distinct, but
>> they (almost?) always are in practice, because it doesn't make
>> sense for them not to be.
>>
>> Here's what you wrote:
>>
>> | According to Keith, every C implementation consists of assorted
>> | components like this:
>> |
>> | * Possibly, a discrete preprocessor
>> | * Compiler
>> | * Standard headers
>> | * Assembler
>> | * Linker
>> | * Standard library
>> | * Extensions
>> |
>> | which everyone who ever installs an implementation is expected to obtain
>> | from different sources and mix and match to create a custom C system.
>>
>> That is false; I did not say that. Typically "everyone who ever
>> installs an implementation" installs some bundle that already includes
>> the components that make up a C implementation.
>>
>> Is it possible that you actually believed when you made that statement
>> that that was what I had said? I don't know *how* you could have
>> reached that conclusion.
>>
>
> Slight disagreement.
>
> To the Standard, there is ONLY a complete implementation.
>
> That implementation might be buildable out of building blocks, but as
> far as the Standard is concerned, it is the responsibility of the entity
> that puts it all together to make sure the results is 'Conforming'.
>
> GCC, for example, it just a piece of an implementation, mostly the piece
> called the 'compiler' (which I don't think is actually a defined term
> for the Standard), and includes documentation for how to combine it with
> the other pieces.
>
> THere are library vendors who will provide other pieces of the
> implementation, and documentation of how to combine it with other pieces
> to make an implementation.
>
> THen someone takes these pieces and creates the actual implementation.
> They depend on the documentation from the various component vendors to
> help them ensure that they make a 'Conforming' Implementation. If they
> did the job right, it will be (or at least as close as practical
> software will be to meeting some specification).
>
> Sometimes the integrator intentionally makes the combination
> non-conforming because that meets their needs better (perhaps adding a
> non-conforming extension to the implementation). This is perfectly fine
> too, 'Conformance' isn't the only criteria to judge an implementation by.
Hmm. I agree with you, and I'm not sure how you disagree (slightly)
with me. The discussion was about typical implementations.
--
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 | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2021-10-01 13:49 -0700 |
| Message-ID | <868rzctqqq.fsf@linuxsc.com> |
| In reply to | #162371 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: > Bart <bc@freeuk.com> writes: > [SNIP] > >>> 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? > > I do not "admit" it. The word "admit" implies that I've > previously stated otherwise. [...] In normal English usage the word "admit" neither requires nor implies a previous statement to the contrary. For example, in court a defendent may admit guilt without have made any previous statement regarding guilt or innocence before pleading guilty. Books and newspaper articles offer countless other examples.
[toc] | [prev] | [next] | [standalone]
| From | antispam@math.uni.wroc.pl |
|---|---|
| Date | 2021-08-12 16:52 +0000 |
| Message-ID | <sf3jjj$kbl$1@z-news.wcss.wroc.pl> |
| In reply to | #162352 |
Bart <bc@freeuk.com> wrote:
> On 12/08/2021 09:29, David Brown wrote:
> > On 12/08/2021 00:00, Bart wrote:
>
> 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!)
I used the following with 'strcpy' and 'strlen':
#include <stdio.h>
#include <string.h>
char str[60*1000];
extern char * get_str(void);
int
main(void) {
char * s;
char * ns;
for (int i=0; i<100000; ++i) {
ns = get_str();
s = str;
strcpy(s, ns);
s += strlen(ns);
strcpy(s, ns);
s += strlen(ns);
strcpy(s, ns);
s += strlen(ns);
strcpy(s, ns);
s += strlen(ns);
strcpy(s, ns);
}
puts(str);
return 0;
}
but redirected output to '/dev/null'.
time ./b5a > /dev/null
real 0m0.400s
user 0m0.400s
sys 0m0.000s
so 400ms for this version doing 100000
With 'sprintf':
#include <stdio.h>
#include <string.h>
char str[60*1000];
extern char * get_str(void);
int
main(void) {
char * s;
char * ns;
for (int i=0; i<100000; ++i) {
ns = get_str();
s = str;
s += sprintf(s, "%s", ns);
s += sprintf(s, "%s", ns);
s += sprintf(s, "%s", ns);
s += sprintf(s, "%s", ns);
sprintf(s, "%s", ns);
}
puts(str);
return 0;
}
time ./b5c > /dev/null
real 0m0.473s
user 0m0.468s
sys 0m0.000s
BTW: For my tests I used 'get_str', so I renamed yours to 'get_str'
to fit.
> 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.)
Well, there are various design points. On short strings on my
machine I get similar time as you with 'sprintf' and 2.4s
using 'strcat' + 'strlen'. But on longer strings seem to be
much faster (as I wrote on my machine string handling is via
SSE instructions).
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | antispam@math.uni.wroc.pl |
|---|---|
| Date | 2021-08-12 18:45 +0000 |
| Message-ID | <sf3q8n$u9$1@z-news.wcss.wroc.pl> |
| In reply to | #162362 |
antispam@math.uni.wroc.pl wrote:
> Bart <bc@freeuk.com> wrote:
> > On 12/08/2021 09:29, David Brown wrote:
> > > On 12/08/2021 00:00, Bart wrote:
> >
> > 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!)
>
> I used the following with 'strcpy' and 'strlen':
>
> #include <stdio.h>
> #include <string.h>
>
> char str[60*1000];
>
> extern char * get_str(void);
>
> int
> main(void) {
> char * s;
> char * ns;
> for (int i=0; i<100000; ++i) {
> ns = get_str();
> s = str;
> strcpy(s, ns);
> s += strlen(ns);
> strcpy(s, ns);
> s += strlen(ns);
> strcpy(s, ns);
> s += strlen(ns);
> strcpy(s, ns);
> s += strlen(ns);
> strcpy(s, ns);
> }
> puts(str);
> return 0;
> }
>
> but redirected output to '/dev/null'.
>
> time ./b5a > /dev/null
>
> real 0m0.400s
> user 0m0.400s
> sys 0m0.000s
>
> so 400ms for this version doing 100000
>
> With 'sprintf':
>
> #include <stdio.h>
> #include <string.h>
>
> char str[60*1000];
>
> extern char * get_str(void);
>
> int
> main(void) {
> char * s;
> char * ns;
> for (int i=0; i<100000; ++i) {
> ns = get_str();
> s = str;
> s += sprintf(s, "%s", ns);
> s += sprintf(s, "%s", ns);
> s += sprintf(s, "%s", ns);
> s += sprintf(s, "%s", ns);
> sprintf(s, "%s", ns);
> }
> puts(str);
> return 0;
> }
>
> time ./b5c > /dev/null
>
> real 0m0.473s
> user 0m0.468s
> sys 0m0.000s
>
> BTW: For my tests I used 'get_str', so I renamed yours to 'get_str'
> to fit.
>
> > 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.)
>
> Well, there are various design points. On short strings on my
> machine I get similar time as you with 'sprintf' and 2.4s
> using 'strcat' + 'strlen'. But on longer strings seem to be
> much faster (as I wrote on my machine string handling is via
> SSE instructions).
A little correction, I messed up sources and binaries and
'strcpy' version was doing onlyu four copies in the loop.
I also tried version using 'memcpy' instead of 'strcpy',
the critical fragment being:
l = strlen(ns);
memcpy(s, ns, l+1);
s += l;
Now the results are:
time ./b5a > /dev/null
real 0m0.476s
user 0m0.468s
sys 0m0.000s
time ./b5c > /dev/null
real 0m0.475s
user 0m0.472s
sys 0m0.000s
time ./b5d > /dev/null
real 0m0.500s
user 0m0.488s
sys 0m0.000s
where 'b5a' uses 'strcpy', 'b5c' uses 'sprintf' and 'b5d' uses
'memcpy'. As you see 'strcpy' variant and 'sprintf' have
almost the same speed, while 'memcpy' is slightly slower.
FYI, for 'strcpy' + 'strlen' and 'sprintf' this means 6.57
characters per clock. 'memcpy' + 'strlen' is doing only
6.25 characters per clock.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-08-12 22:17 +0100 |
| Message-ID | <sf4366$uej$1@dont-email.me> |
| In reply to | #162362 |
On 12/08/2021 17:52, antispam@math.uni.wroc.pl wrote:
> Bart <bc@freeuk.com> wrote:
>> On 12/08/2021 09:29, David Brown wrote:
>>> On 12/08/2021 00:00, Bart wrote:
>>
>> 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!)
>
> I used the following with 'strcpy' and 'strlen':
>
> #include <stdio.h>
> #include <string.h>
>
> char str[60*1000];
>
> extern char * get_str(void);
>
> int
> main(void) {
> char * s;
> char * ns;
> for (int i=0; i<100000; ++i) {
> ns = get_str();
> s = str;
> strcpy(s, ns);
> s += strlen(ns);
> strcpy(s, ns);
> s += strlen(ns);
> strcpy(s, ns);
> s += strlen(ns);
> strcpy(s, ns);
> s += strlen(ns);
> strcpy(s, ns);
> }
> puts(str);
> return 0;
> }
This combination is generally faster than strcat on my machine, even
without extracting the getstr() call into one variable. (That's intended
to represent some arbitrary string, that can change on each call.)
In some cases it was double the speed of strcat.
It was faster even when I put both into a single function 'strcpylen',
so needing one call to getstr. But trying to replace those two calls
inside strcpylen with an actual copying loop, to eliminate a separate
strlen, was much slower (between strcat and my sprintf).
In any case, I've seen no evidence that sprintf can be reliably faster
than strcat or strcpy etc. It's also more untidy to call.
[toc] | [prev] | [next] | [standalone]
| From | antispam@math.uni.wroc.pl |
|---|---|
| Date | 2021-08-11 21:09 +0000 |
| Message-ID | <sf1e9g$14$1@z-news.wcss.wroc.pl> |
| In reply to | #162320 |
Bart <bc@freeuk.com> 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):
Again this nonsense with unoptimized benchmarks. Write your
benchmark to realisticaly simulate actual load. If you
have real code and compiler optimizes part of it out of
existence, then this is good things, means that task
can be done simpler/faster than what programmer expected.
> 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?
On may machine, using cc -O2 I get:
time ./b2
five
real 0m0.049s
user 0m0.044s
sys 0m0.004s
Assembler output for the crucial part is:
movl $10000000, %eax #, ivtmp_1
.p2align 4,,10
.p2align 3
.L2:
movl $8293, %ecx #,
movl $32, %esi #,
subl $1, %eax #, ivtmp_1
movw %si, 18+str(%rip) #, MEM[(void *)&str + 14B]
movl $543518319, str(%rip) #, MEM[(void *)&str]
movl $544175988, 4+str(%rip) #, MEM[(void *)&str + 4B]
movl $1701996660, 8+str(%rip) #, MEM[(void *)&str + 8B]
movw %cx, 12+str(%rip) #, MEM[(void *)&str + 8B]
movl $1920298854, 14+str(%rip) #, MEM[(void *)&str + 14B]
movq %rdx, s(%rip) # tmp98, s
movl $1702259046, 19+str(%rip) #, MEM[(void *)&str + 19B]
movb $0, 23+str(%rip) #, MEM[(void *)&str + 19B]
jne .L2 #,
leaq 19+str(%rip), %rdi #,
call puts@PLT
As you see, there are no call to 'sprintf' but the code is dully
doing all interation that you prescribed and putting characters
in buffer. And FYI, there is no string line "one", ..., etc
in the assembly, all string copying is done via integer moves.
BTW: Even with -O0 (or no optimization flag) is see no calls
to 'sprintf', but loop is slower and take 0.246s. This
is 5 times slower than optimized loop above and clearly
shows that unoptimized benchmarks make no sense.
BTW2: You write code using 'sprintf' if you know that compiler
will optimize it (as it did above). Otherwise look what is
fast in compiler you use (your bcc???).
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-08-11 23:13 +0100 |
| Message-ID | <sf1i29$jdp$1@dont-email.me> |
| In reply to | #162340 |
On 11/08/2021 22:09, antispam@math.uni.wroc.pl wrote:
> Bart <bc@freeuk.com> 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):
>
> Again this nonsense with unoptimized benchmarks. Write your
> benchmark to realisticaly simulate actual load. If you
> have real code and compiler optimizes part of it out of
> existence, then this is good things, means that task
> can be done simpler/faster than what programmer expected.
No it is a bad thing. You want such a test to tell you a general thing:
is strcat to concatenate multiple short strings generally better than
multiple calls to sprintf?
That it can optimise both away in this specific, silly benchmark tells
you nothing.
See my reply to David Brown a few minutes ago where I did enable
optimisation on my compilers, with a revised test.
>> 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?
>
> On may machine, using cc -O2 I get:
>
> time ./b2
> five
>
> real 0m0.049s
> user 0m0.044s
> sys 0m0.004s
>
> Assembler output for the crucial part is:
>
> movl $10000000, %eax #, ivtmp_1
> .p2align 4,,10
> .p2align 3
> .L2:
> movl $8293, %ecx #,
> movl $32, %esi #,
> subl $1, %eax #, ivtmp_1
> movw %si, 18+str(%rip) #, MEM[(void *)&str + 14B]
> movl $543518319, str(%rip) #, MEM[(void *)&str]
> movl $544175988, 4+str(%rip) #, MEM[(void *)&str + 4B]
> movl $1701996660, 8+str(%rip) #, MEM[(void *)&str + 8B]
> movw %cx, 12+str(%rip) #, MEM[(void *)&str + 8B]
> movl $1920298854, 14+str(%rip) #, MEM[(void *)&str + 14B]
> movq %rdx, s(%rip) # tmp98, s
> movl $1702259046, 19+str(%rip) #, MEM[(void *)&str + 19B]
> movb $0, 23+str(%rip) #, MEM[(void *)&str + 19B]
> jne .L2 #,
> leaq 19+str(%rip), %rdi #,
> call puts@PLT
This is what I get for the c.c module of my last past, with gcc -O3 -S
(comments and other noise deleted):
printf:
push r12 #
push rbx #
sub rsp, 56 #,
lea rbx, 88[rsp] # tmp86,
mov QWORD PTR 88[rsp], rdx #,
mov r12, rcx # __format, tmp89
mov ecx, 1 #,
mov QWORD PTR 96[rsp], r8 #,
mov QWORD PTR 104[rsp], r9 #,
mov QWORD PTR 40[rsp], rbx # MEM[(char * *)&__local_argv], tmp86
call [QWORD PTR __imp___acrt_iob_func[rip]] #
mov r8, rbx #, tmp86
mov rdx, r12 #, __format
mov rcx, rax # _2, tmp90
call __mingw_vfprintf #
add rsp, 56 #,
pop rbx #
pop r12 #
ret
.LC0:
sprintf.constprop.0:
sub rsp, 56 #,
lea rdx, .LC0[rip] #,
lea rcx, str[rip] #,
mov QWORD PTR 80[rsp], r8 #,
lea r8, 80[rsp] # tmp86,
mov QWORD PTR 88[rsp], r9 #,
mov QWORD PTR 40[rsp], r8 # MEM[(char * *)&__local_argv], tmp86
call __mingw_vsprintf #
add rsp, 56 #,
ret
sprintf.constprop.1:
sub rsp, 56 #,
lea rdx, .LC0[rip] #,
mov QWORD PTR 80[rsp], r8 #,
lea r8, 80[rsp] # tmp86,
mov QWORD PTR 88[rsp], r9 #,
mov QWORD PTR 40[rsp], r8 # MEM[(char * *)&__local_argv], tmp86
call __mingw_vsprintf #
add rsp, 56 #,
ret
.LC1:
.ascii "%d\12\0"
.LC2:
.ascii "time1 %d\12\0"
.LC3:
.ascii "time2 %d\12\0"
.LC4:
.ascii "\0"
.section .text.startup,"x"
main:
push r13 #
push r12 #
push rbp #
push rdi #
push rsi #
push rbx #
sub rsp, 40 #,
mov esi, 1000000 # ivtmp_24,
lea rbx, str[rip] # tmp134,
call __main #
call clock #
mov edi, eax # t, tmp135
.L6:
call getstr #
mov rcx, rbx #, tmp134
mov rdx, rax # _1, tmp136
call strcpy #
call getstr #
mov rcx, rbx #, tmp134
mov rdx, rax # _2, tmp137
call strcat #
call getstr #
mov rcx, rbx #, tmp134
mov rdx, rax # _3, tmp138
call strcat #
call getstr #
mov rcx, rbx #, tmp134
mov rdx, rax # _4, tmp139
call strcat #
call getstr #
mov rcx, rbx #, tmp134
mov rdx, rax # _5, tmp140
call strcat #
sub esi, 1 # ivtmp_24,
jne .L6 #,
lea rcx, str[rip] #,
lea rbp, str[rip] # tmp131,
call puts #
lea rcx, str[rip] #,
lea rsi, .LC0[rip] # tmp132,
call strlen #
lea rcx, .LC1[rip] #,
mov rdx, rax # tmp118, tmp141
call printf #
call clock #
lea rcx, .LC2[rip] #,
sub eax, edi # tmp142, t
mov edi, 1000000 # ivtmp_23,
mov edx, eax # tmp120, tmp142
call printf #
call clock #
mov r13d, eax # t, tmp143
.L7:
call getstr #
mov rdx, rsi #, tmp132
mov rcx, rbp #, tmp131
mov r8, rax # tmp144,
call sprintf.constprop.0 #
movsx rbx, eax # _43, tmp145
call getstr #
add rbx, rbp # s, tmp131
mov rdx, rsi #, tmp132
mov rcx, rbx #, s
mov r8, rax # tmp146,
call sprintf.constprop.1 #
cdqe
add rbx, rax # s, _47
call getstr #
mov rcx, rbx #, s
mov rdx, rsi #, tmp132
mov r8, rax # tmp148,
call sprintf.constprop.1 #
cdqe
add rbx, rax # s, _51
call getstr #
mov rdx, rsi #, tmp132
mov rcx, rbx #, s
mov r8, rax # tmp150,
call sprintf.constprop.1 #
movsx r12, eax # _55, tmp151
call getstr #
add r12, rbx # s, s
mov rdx, rsi #, tmp132
mov r8, rax # tmp152,
mov rcx, r12 #, s
call sprintf.constprop.1 #
sub edi, 1 # ivtmp_23,
jne .L7 #,
lea rcx, str[rip] #,
call puts #
lea rcx, str[rip] #,
call strlen #
lea rcx, .LC1[rip] #,
mov rdx, rax # tmp127, tmp153
call printf #
call clock #
lea rcx, .LC3[rip] #,
sub eax, r13d # tmp154, t
mov edx, eax # tmp129, tmp154
call printf #
lea rcx, .LC4[rip] #,
call puts #
xor eax, eax #
add rsp, 40 #,
pop rbx #
pop rsi #
pop rdi #
pop rbp #
pop r12 #
pop r13 #
ret
str:
.space 100000
.ident "GCC: (tdm64-1) 10.3.0"
I guess this is again either all my fault for not knowing what options I
need to make the code as sweet as yours, or Windows' for being such a
crap OS, or both.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-08-11 23:30 +0100 |
| Message-ID | <sf1j2u$6h1$1@dont-email.me> |
| In reply to | #162344 |
On 11/08/2021 23:13, Bart wrote: > On 11/08/2021 22:09, antispam@math.uni.wroc.pl wrote: >> Bart <bc@freeuk.com> wrote: > This is what I get for the c.c module of my last past, with gcc -O3 -S > (comments and other noise deleted): > > printf: > push r12 # ... > I guess this is again either all my fault for not knowing what options I > need to make the code as sweet as yours, or Windows' for being such a > crap OS, or both. Better is this godbolt link to that same module (using gcc x64 11.2): https://godbolt.org/z/Yz9vEzhaY The displayed code is a lot cleaner and clearer. I'm not even sure what OS it's for! (It doesn't look like Win64, so at least you can't be Windows-bashing with it.) However there are explicit calls to both strcat and sprintf. Changing the latter to snprintf makes it even longer (not sure how that helps save cycles as SL said).
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2021-08-12 10:39 +0200 |
| Message-ID | <sf2mnq$69m$1@dont-email.me> |
| In reply to | #162345 |
On 12/08/2021 00:30, Bart wrote: > On 11/08/2021 23:13, Bart wrote: >> On 11/08/2021 22:09, antispam@math.uni.wroc.pl wrote: >>> Bart <bc@freeuk.com> wrote: > >> This is what I get for the c.c module of my last past, with gcc -O3 -S >> (comments and other noise deleted): >> >> printf: >> push r12 # > ... >> I guess this is again either all my fault for not knowing what options >> I need to make the code as sweet as yours, or Windows' for being such >> a crap OS, or both. > > Better is this godbolt link to that same module (using gcc x64 11.2): > > https://godbolt.org/z/Yz9vEzhaY > > The displayed code is a lot cleaner and clearer. It is not "cleaner and clearer" - it is much messier because you have put everything into one big function combined with clock timing stuff and outputs. To make code "clean and clear", structure it properly - put different things in different functions, and then it is possible to see the relevant differences in the results. > I'm not even sure what > OS it's for! (It doesn't look like Win64, so at least you can't be > Windows-bashing with it.) You display your ignorance proudly, as though it were a medal. Bizarre. If you look at the list of compilers available, it is quickly apparent that this particular compiler is native gcc on x86 Linux. Other options available include MSVC running under Wine, and various cross-compilers. No matter - one of the points of this kind of test is that it is looking at the compiler output alone, with little or no OS-specific details. > > However there are explicit calls to both strcat and sprintf. Changing > the latter to snprintf makes it even longer (not sure how that helps > save cycles as SL said). Yes indeed - after adding the "getstr" to your code, gcc no longer optimises the code the same way.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-08-12 12:26 +0100 |
| Message-ID | <sf30he$3gc$1@dont-email.me> |
| In reply to | #162351 |
On 12/08/2021 09:39, David Brown wrote: > On 12/08/2021 00:30, Bart wrote: >> On 11/08/2021 23:13, Bart wrote: >>> On 11/08/2021 22:09, antispam@math.uni.wroc.pl wrote: >>>> Bart <bc@freeuk.com> wrote: >> >>> This is what I get for the c.c module of my last past, with gcc -O3 -S >>> (comments and other noise deleted): >>> >>> printf: >>> push r12 # >> ... >>> I guess this is again either all my fault for not knowing what options >>> I need to make the code as sweet as yours, or Windows' for being such >>> a crap OS, or both. >> >> Better is this godbolt link to that same module (using gcc x64 11.2): >> >> https://godbolt.org/z/Yz9vEzhaY >> >> The displayed code is a lot cleaner and clearer. > > It is not "cleaner and clearer" - it is much messier because you have > put everything into one big function combined with clock timing stuff > and outputs. I was talking about the assembly code To make code "clean and clear", structure it properly - > put different things in different functions, and then it is possible to > see the relevant differences in the results. > >> I'm not even sure what >> OS it's for! (It doesn't look like Win64, so at least you can't be >> Windows-bashing with it.) > > You display your ignorance proudly, as though it were a medal. Bizarre. Ignorance about what? I genuinely don't know what machines these compilers target, because it doesn't tell you. Not for GCC x64 anyway. Yes, I can see from the call sequences that it is not Win64 ABI, and is probably 'SYS V', but that's about it. The important thing is that it shows more realistic code than you and antispam posted. It should have been clear that that my original code could collapse down to nothing if optimised, something I even said would happen. You both should instead have put together a more solid test that compared the merits of strcat and sprintf that would hold up better. Instead you are just more interested in bart-bashing points. And in the end, which of those two functions is better; what conclusion have you reached by trashing my own test? You vaguely suggest that sprintf is better, but where's your benchmark?
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2021-08-12 16:44 +0200 |
| Message-ID | <sf3c4m$m4h$1@dont-email.me> |
| In reply to | #162353 |
On 12/08/2021 13:26, Bart wrote: > On 12/08/2021 09:39, David Brown wrote: >> On 12/08/2021 00:30, Bart wrote: >>> On 11/08/2021 23:13, Bart wrote: >>>> On 11/08/2021 22:09, antispam@math.uni.wroc.pl wrote: >>>>> Bart <bc@freeuk.com> wrote: >>> >>>> This is what I get for the c.c module of my last past, with gcc -O3 -S >>>> (comments and other noise deleted): >>>> >>>> printf: >>>> push r12 # >>> ... >>>> I guess this is again either all my fault for not knowing what options >>>> I need to make the code as sweet as yours, or Windows' for being such >>>> a crap OS, or both. >>> >>> Better is this godbolt link to that same module (using gcc x64 11.2): >>> >>> https://godbolt.org/z/Yz9vEzhaY >>> >>> The displayed code is a lot cleaner and clearer. >> >> It is not "cleaner and clearer" - it is much messier because you have >> put everything into one big function combined with clock timing stuff >> and outputs. > > I was talking about the assembly code The same applies to the assembly code as to the source code here. (That is not always the case, of course.) > > To make code "clean and clear", structure it properly - >> put different things in different functions, and then it is possible to >> see the relevant differences in the results. >> >>> I'm not even sure what >>> OS it's for! (It doesn't look like Win64, so at least you can't be >>> Windows-bashing with it.) >> >> You display your ignorance proudly, as though it were a medal. Bizarre. > > Ignorance about what? I genuinely don't know what machines these > compilers target, because it doesn't tell you. Not for GCC x64 anyway. > It tells you "running under Wine" for the Windows-only compilers. That should be a big clue. You can also look at the documentation for it. > Yes, I can see from the call sequences that it is not Win64 ABI, and is > probably 'SYS V', but that's about it. > > The important thing is that it shows more realistic code than you and > antispam posted. It should have been clear that that my original code > could collapse down to nothing if optimised, something I even said would > happen. No, your later examples are not more realistic than your earlier ones, and putting the two algorithms into one function along with other boilerplate code instead of two simple functions (that's what my complaint was about) is not more realistic in any sense. Show me a /realistic/ use-case for combining the same simple string to itself a million times. > > You both should instead have put together a more solid test that > compared the merits of strcat and sprintf that would hold up better. > Why? All I was doing was showing that the test you gave was pointless. The result was that you then produced a slightly less pointless test, which is an improvement. > Instead you are just more interested in bart-bashing points. > > And in the end, which of those two functions is better; what conclusion > have you reached by trashing my own test? You vaguely suggest that > sprintf is better, but where's your benchmark? > My conclusion from trashing your test is that your test was pointless. It gave no indication whether one function was better than the other in any way. Later modifications to your test showed that strcat was faster than sprintf in that particular meaningless and unrealistic example. I don't have /any/ concrete conclusions about the relative speeds of these functions. I can estimate that in general, strcat will usually be faster than sprintf as independent library functions, and also that in some cases sprintf might be faster. And I can certainly conclude that it will all depend on details of the code, the compiler, optimisations, library implementations, and no doubt also the system it is running on. Timing meaningless code is usually pointless. If you have a program that does a lot of string manipulation, and you have investigated and discovered that the string manipulation is a serious bottleneck and does not run as fast as you want, then make timings of different algorithms and functions for that code. (If the speed is not a problem, then of course you aim for source-code clarity and maintainability, rather than speed.) That is the lesson /you/ should take away from all this.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-08-12 17:20 +0100 |
| Message-ID | <sf3hoa$vto$1@dont-email.me> |
| In reply to | #162355 |
On 12/08/2021 15:44, David Brown wrote: > On 12/08/2021 13:26, Bart wrote: > Show me a /realistic/ use-case for combining the same simple string to > itself a million times. Show me a use-case for testing vehicles by driving round and round the same circular track. It seems you just don't get benchmarks. Many are necessarily repetitive, and need to concentrate on a specific thing that is being tested. And all are meaningless. I could change my getstr() routine to return a random string of random length, but that makes it harder to measure and compare results, and you would just find another reason to discredit it. Here's a challenge for you: some students each present you with an opaque implementation of [for example] strcat (but renamed to avoid confusion). You need to grade according them according to how efficient (ie. how fast) they are on a range of test inputs. How would you go about testing them? Don't forget you're not allowed to use loops, or apply the same inputs more than once. How would you distinguish an entry which is fast because of technique, from one which is fast because of a clever compiler which can take advantage of the specific test context? What would you think of a compiler smart enough to recognise the function as doing what strcat does, and replaces it with the highly-optimised built-in strcat; would you consider that a good or bad thing, from the point of view of doing your job?
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2021-08-12 20:00 +0200 |
| Message-ID | <sf3nki$c30$1@dont-email.me> |
| In reply to | #162361 |
On 12/08/2021 18:20, Bart wrote: > On 12/08/2021 15:44, David Brown wrote: >> On 12/08/2021 13:26, Bart wrote: > > >> Show me a /realistic/ use-case for combining the same simple string to >> itself a million times. > > > Show me a use-case for testing vehicles by driving round and round the > same circular track. There are plenty, as you well know. Pushing an analogy past its breaking point does not make you right. > > It seems you just don't get benchmarks. Many are necessarily repetitive, > and need to concentrate on a specific thing that is being tested. And > all are meaningless. I did not say benchmarks are not useful - they are, in some cases, when they can be used to measure something useful. I objected to your characteristic of your code as "realistic", which it most certainly is not. > > I could change my getstr() routine to return a random string of random > length, but that makes it harder to measure and compare results, and you > would just find another reason to discredit it. > That would change the kind of benchmark, perhaps giving more useful results (without improving the realism at all). But it is still not clear what you would be testing or how it relates to speeds and bottlenecks in /real/ code. If the speed of string concatenation in real world code (of a particular type) is limited by cache speeds rather than processor speeds, then the function that gives the fastest results will be the one that uses fewer memory accesses - not the one that wins on such limited synthetic benchmarks. At the moment, all you are doing is benchmarking the speed of your benchmark, which is not relevant to real programming. > Here's a challenge for you: some students each present you with an > opaque implementation of [for example] strcat (but renamed to avoid > confusion). You need to grade according them according to how efficient > (ie. how fast) they are on a range of test inputs. > > How would you go about testing them? Don't forget you're not allowed to > use loops, or apply the same inputs more than once. > I would want to know under what circumstances the functions are intended to be used. Otherwise, the question is meaningless. > How would you distinguish an entry which is fast because of technique, > from one which is fast because of a clever compiler which can take > advantage of the specific test context? > > What would you think of a compiler smart enough to recognise the > function as doing what strcat does, and replaces it with the > highly-optimised built-in strcat; would you consider that a good or bad > thing, from the point of view of doing your job? Those are all good questions to consider before deciding how the implementations should be judged. Usually, I'd pick the one that is most clearly correctly implemented. Black box implementations get zero marks on that score, regardless of whether they passed or failed any tests.
[toc] | [prev] | [next] | [standalone]
| From | antispam@math.uni.wroc.pl |
|---|---|
| Date | 2021-08-12 00:44 +0000 |
| Message-ID | <sf1qu8$i4i$1@z-news.wcss.wroc.pl> |
| In reply to | #162344 |
Bart <bc@freeuk.com> wrote:
> On 11/08/2021 22:09, antispam@math.uni.wroc.pl wrote:
> > Bart <bc@freeuk.com> 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):
> >
> > Again this nonsense with unoptimized benchmarks. Write your
> > benchmark to realisticaly simulate actual load. If you
> > have real code and compiler optimizes part of it out of
> > existence, then this is good things, means that task
> > can be done simpler/faster than what programmer expected.
>
> No it is a bad thing. You want such a test to tell you a general thing:
> is strcat to concatenate multiple short strings generally better than
> multiple calls to sprintf?
AFAICS DFS result showed than on his machine sprintf was
worse. Note I was not the person who advocated use of
'sprintf' -- without testing it is potential trap (as
you and DFS showed). If one wants highest speed, IIRC
BSD folks had a version of strcpy that returned pointer
to destination. This could be fastest, but is nonstandard
so less chance for optimized version in compiler.
> That it can optimise both away in this specific, silly benchmark tells
> you nothing.
Benchmark tells you that compiler can inline very efficient
version of 'sprintf' (and 'strcat') for constant string. This
is important special case that is frequent in practice.
> See my reply to David Brown a few minutes ago where I did enable
> optimisation on my compilers, with a revised test.
Yes, that is valid benchmark. I came to similar benchmark
with similar result, for variable argument 'sprintf' goes
to library routine and at least for short strings is
much slower than 'strcat' or 'strcpy' and 'strlen.
On my machine 'sprintf', 'strcat' and 'strcpy' eventually
arrive to hairy SSE code, which in principle could be
quite fast for long strings, but has significant cost
for short strings (still, library 'strlen' is faster
than inline 'rep scanb' on my machine).
> I guess this is again either all my fault for not knowing what options I
> need to make the code as sweet as yours, or Windows' for being such a
> crap OS, or both.
Well, you used variable strings. In principle gcc could have
an optimized version of 'sprintf' for such case, but it seems
that your or my gcc does not have it. However, the point is
that without turning on optimization on you do not know what
tricks gcc will use to speed up (or not :( ) your program.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2021-08-11 10:39 -0700 |
| Message-ID | <fc51810f-a1c6-44a5-9dbd-87368dda1df9n@googlegroups.com> |
| In reply to | #162318 |
On Wednesday, 11 August 2021 at 16:06:38 UTC+1, Scott Lurndal wrote: > > Building it with snprintf() will be far more flexible and efficient. > > Every cycle matters. > People often talk about "bottlenecks" in code. However for a program which launches, performs a calculation, returns a result, and terminates, there are no bottlenecks. Every cycle is equal. However not every line of code is equal. Typically some lines will be executed millions or even billions of times, other lines only once. But a lot of programs don't fit that model. They spend a lot of time idling, waiting for input, and then occasionally present the user with a lag when a long operation is attempted. Efficiency only matters in the laggy code, there's no point in optimising code which executes in under just noticeable time.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2021-08-11 17:52 +0000 |
| Message-ID | <a7UQI.5572$xY.366@fx05.iad> |
| In reply to | #162324 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: >On Wednesday, 11 August 2021 at 16:06:38 UTC+1, Scott Lurndal wrote: >> >> Building it with snprintf() will be far more flexible and efficient. >> >> Every cycle matters. >> >People often talk about "bottlenecks" in code. However for a program >which launches, performs a calculation, returns a result, and terminates, >there are no bottlenecks. Every cycle is equal. However not every line of >code is equal. Typically some lines will be executed millions or even >billions of times, other lines only once. > >But a lot of programs don't fit that model. They spend a lot of time idling, >waiting for input, and then occasionally present the user with a lag when a >long operation is attempted. Efficiency only matters in the laggy code, >there's no point in optimising code which executes in under just noticeable time. You are discounting the fact that prodiction code is generally not running stand-alone bare-metal. In which case there will be other processes/threads/guests waiting for the CPU, so every cycle matters.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2021-08-11 11:41 -0700 |
| Message-ID | <87lf57j030.fsf@nosuchdomain.example.com> |
| In reply to | #162318 |
scott@slp53.sl.home (Scott Lurndal) writes:
> 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.
As Bart's measurements indicate, snprintf() is likely to have
substantial overhead, probably because it has to parse its format
string. I wouldn't assume snprintf() is going to be faster than
strcat() without measuring it for the specific data I'm working with.
The non-standard strlcat() returns the initial length of the destination
plus the length of the source, which can be used to find the end of the
copyied string without re-scanning. (It can be a little tricky to get
the compilation command right on some systems.)
--
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 | DFS <nospam@dfs.com> |
|---|---|
| Date | 2021-08-08 16:00 -0400 |
| Message-ID | <PJWPI.737$M14.441@fx11.iad> |
| In reply to | #162248 |
On 8/8/2021 10:41 AM, Bart wrote:
> On 08/08/2021 13:51, DFS wrote:
>> On 8/7/2021 12:11 PM, Bart wrote:
>>> On 07/08/2021 15:03, DFS wrote:
>>>> On 8/4/2021 1:40 PM, Bart wrote:
>>>>
>>>>
>>>>> A compiler like tcc, at the speed it works with C, would be 2-3
>>>>> times as fast. So 5M lines might take well under 10 seconds, or 15
>>>>> seconds on mine, on my PC. Expect better figures on a high-end PC,
>>>>> even with one core.
>>>>
>>>>
>>>> I recently installed the WinLibs build of gcc for Windows
>>>>
>>>> https://winlibs.com
>>>>
>>>> I compiled a 900-line file using tcc 0.9.27 and the winlibs gcc
>>>> 11.2.0 for Windows.
>>>>
>>>> The gcc executable is 6.8x larger, and the printf() parts of the
>>>> code run like a dog vs tcc. Kind of a bust, as I like snappy code.
>>>
>>> Trying compiling with -s option, which omits symbols from the
>>> executable.
>> That cut the size in half. Cool. Now it's only 3x as large as the
>> tcc .exe.
>>
>
> What are the actual sizes? Because tcc compiles hello.c to 2KB, gcc to
> 47KB, as it contains more built-in stuff (eg. printf in gcc is a wrapper
> function around vprintf).
gcc : 85,435
gcc -s : 41,984
gcc -Os -s: 38,400
tcc : 15,360
tcc -s : 15,360
tcc -Os -s: 15,360
All 6 variations run fine, so tcc apparently ignores various flags in
the compilation:
>>> I'm surprised printf (is that to the screen or directed to a file?)
>>> is slower; that should be little to do with the generated code.
>>
>> It's to the screen. Only thing slightly different than usual is using
>> a width wildcard:
>>
>> printf("%-*s ", longword, matchwords[i]);
>>
>> I replaced it with a hardcoded value but it made no difference.
>>
>> printf("%-16s ", matchwords[i]);
>>
>>
>> The gcc-Windows compiled version does printf() at 1/4 the speed of tcc.
>
> You're right; this program:
>
> #include <stdio.h>
> int main(void) {
> for (int i=0; i<10000; ++i)
> printf("%-16s","1234567890"); // no newlines
> }
>
> runs in 3 seconds with tcc. With gcc, 21 seconds, even optimised. I've
> never noticed before.
>
> My bcc compiler, which also calls printf in msvcrt, does it in 2.3
> seconds for some reason. lccwin is 15 seconds, DM 2.7. MSVC is 2.7 too.
> Clang is 21 seconds (which is taking being a gcc clone to extremes).
>
> All very strange. I don't know how much this is important, or how much
> text you're printing to the screen, since 500 printfs per second is
> still faster than anyone can read it. The problem disappears if you
> redirect to a file.
For example, printf() 726 words split across N left-aligned columns:
Windows:
gcc: 3.07s
tcc: 0.24s
> You can try bypassing printf in gcc by using sprintf to a string for a
> complete line of output, then using puts() on the string. However you
> shouldn't need to do this.
I shouldn't. But I put your idea in place and it works a treat.
printf sprintf/puts
gcc: 3.07s 0.06s
tcc: 0.24s 0.06s
Good suggestion.
I actually had to use sprintf() and strcat() in a loop to build up the line:
for(int j = 1;j<=maxcols;j++) {
sprintf(buff,"%-*s ",longword, words[i++]);
strcat(line,buff);
}
>> I moved the atoi() call out of the loop and the speed increased by
>> 135%, to 14/1000ths of a second!
>>
>> int tlen = atoi(&str[0]);
>> for(i=0;i<wordcnt;i++) {
>> if(strlen(words[i]) == tlen) {
>> matches++;
>> }
>> }
>>
>>
>> Incredible.
>
> Here it might be an idea to calculate strlen() on each word once, and
> store the lengths in a table (this could be done while reading the text
> file). Then strlen() will be outside the loop too.
I've done that in the past, but not in this code.
>>> On my machine, gcc-O3 version 11 compiled one of my 43Kloc programs
>>> (an interpreter) in 22 seconds.
>>>
>>> tcc did it in 0.15 seconds; 150 times faster.
>>>
>>> But when I ran the result on a test input, the gcc-O3-generated
>>> program took nearly 17 seconds, tcc took 35 seconds, just over twice
>>> as long:
>>>
>>>
>>> Compile-speed Runtime
>>> gcc 1.0 1.0
>>> tcc 146.0 2.1
>>>
>>> Bigger=better smaller=better
>>
>>
>> How about the size of the executable?
>
> About the same, comparing tcc with gcc-O0 (857/853KB). gcc-O3 made a
> bigger executable (925KB). The differences are bigger than they appear
> since half the size here is embedded string literals.
>
> But still, not significant in this case. (Maybe there is a gcc option to
> optimise for size, but I don't know what it is.)
-Os
"Optimize for size. -Os enables all -O2 optimizations except those that
often increase code size:
-falign-functions -falign-jumps
-falign-labels -falign-loops
-fprefetch-loop-arrays -freorder-blocks-algorithm=stc
It also enables -finline-functions, causes the compiler to tune for code
size rather than execution speed, and performs further optimizations
designed to reduce code size."
https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html
[toc] | [prev] | [next] | [standalone]
Page 14 of 20 — ← Prev page 1 … 12 13 [14] 15 16 … 20 Next page →
Back to top | Article view | comp.lang.c
csiph-web