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 11 of 20 — ← Prev page 1 … 9 10 [11] 12 13 … 20 Next page →
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2021-08-09 18:27 -0700 |
| Message-ID | <87mtpqf5rp.fsf@nosuchdomain.example.com> |
| In reply to | #162284 |
Andrey Tarasevich <andreytarasevich@hotmail.com> writes:
> On 8/9/2021 4:45 PM, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>> [...]
>>> And when I have to play with C, I prefer my own small C compiler; you
>>> know, that one with the faster printf than gcc/tdm.
>> Really? Your *compiler* implements printf? Not the runtime
>> library?
>> Yes, the distinction matters.
>
> While `printf` is certainly a library feature from the formal point of
> view, it is not unusual to see it implemented as an intrinsic at
> compiler level in modern implementations. GCC will happily replace
>
> printf("Hello World\n");
>
> with
>
> puts("Hello World");
>
> at compile-time.
Yes, a compiler can take advantage of standard guarantees about how
standard library functions behave. But it's practical to do so only in
some very narrow special cases. There still has to be a complete
implementation of printf, including interpreting the format string, and
that's provided by the runtime library.
In principle a compiler can do anything that implements the required
behavior, but as far as I know no compilers do that for printf other
than in a few narrow cases.
--
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 | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2021-08-10 01:55 -0700 |
| Message-ID | <b19a37dc-6933-4c0b-ad68-c49bd4d72b5bn@googlegroups.com> |
| In reply to | #162280 |
On Tuesday, August 10, 2021 at 1:48:31 AM UTC+3, Bart wrote: > On 09/08/2021 09:29, Michael S wrote: > > On Monday, August 9, 2021 at 3:03:15 AM UTC+3, DFS wrote: > >> On 8/8/2021 6:30 PM, Michael S wrote: > >> > >>> Bart and DFS are unique people with unique capabilities. DFS more so, > >> What are you babbling about? > > > > Your shared love to strange tools that wouldn't in top#5 list of choice of professional and likely not in top#10. > You just don't get it. > > When I drive to the shops I like to use my hatchback, I don't need a > 40-ton truck, or a 747, which are how big and cumbersome those > professional tools appear to me. (And if younger I'd jump on my bike.) > > Who cares about the top 10 anyway? Where was the top 10 when I needed a > tiny, fast HLL language for my 8-bit micros which actually ran ON those > same micros? I've used my own languages ever since. > > And when I have to play with C, I prefer my own small C compiler; you > know, that one with the faster printf than gcc/tdm. > > That loooks like mingw-64. The same compiler/libraries that I tried first and that finished the task in 20 msec - 1000 times faster than you (or Bart) reported. > A figure which I think you helped to debunk. But the issue at hand is > what to about the gcc version that runs under the exact same environment > as tcc. > > AFAIK, it's C RTL is based on Microsoft's DLL that was originally distributed with VS2013. > > Recently, they (MSYS2 maintainers) added a variant of library that is called ucrt-something, > > probably based on more up to date Microsoft's DLL. I didn't try it yet. > > > > I didn't see the slowness because I was running it from msys2 command window, i.e. the same environment in which that it was tested by maintainers. > > When I take generated exe file and try to run it in regular windows command window (cmd.exe) > > or in powershell window then I see extreme slowness - order of 4.5 sec in cmd.exe and 6.5 sec in powereshell. > > When I changed the size of cmd window to "traditional" defaults of 80x25, it slowed down to 6 seconds. > OK, that's more helpful. Now run tcc in the same way, or just use any > means to write the equivalent text to a file, and use TYPE to display > it. If that's much faster than doing it from the gcc-compiled program, > then you've reproduced the problem. > > We don't need it 1000 times faster, just as fast as TYPE. > > > >> > >> $gcc -Wall source.c -o prog.exe > >> > >> created a huge executable that ran printf() very slowly. > >> > > > > Huge executive is due to presence of symbols. gcc -s (symbols stripped) is just big, not huge. > > > > Slowness is due to interaction between startup code in mingw64 library and windows command prompt environment, > > probably not provisioned by maintainers since they expect their console programs to be run under msys2. > > > > As said by several people here, under such combo stdout behaves as unbuffered. So, 160,000 system calls. > > By themselves, 160,000 system calls are not particularly slow, but Windows console subsystem seems obliged > > to redraw the whole window each time the character does not fit in window width. > Huh? The timings I get strongly suggest that something that should be > done per-string, is getting done per-character. Nothing to do with > window width, which is anyway a long way the other side of the C runtime > library they both end up calling. > >> gcc Windows: slow 3.15s > >> tcc Windows: quick 0.24s > >> gcc Linux : incredibly quick (like 0.01, no time to blink) > >> > > > > 0.01 I'd call o.k. rather than "incredibly quick" > So what is the upper limit of characters per second that can be > genuinely displayed in a Linux terminal window? > > Assuming a character is a bitmapped 12x16 font, on a 24-bit display, > then writing one character cell (forget antialiasing and such) involves > writing 600 bytes to video memory. The 23Mcps figure of Ben's (I think > 7ms to do 160K characters), would involve writing 13GB/s to video > memory. And that's without handling scrolling. Assuming infinitely fast CPU, the upper limit is a speed of writing characters (not bitmaps!) to main system RAM by app (C RTL) and then reading them back by renderer. So, on high-end desktop with dual-channel DDR4-3200, ~25,000 Mcps. Ben's results are lower by 3 orders of magnitude. There is plenty of room for improvements ;-) Of those billions, only 80x25*60 = 120 Kcps should be processed to bitmaps and transferred to graphics hardware.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-08-10 12:19 +0100 |
| Message-ID | <setnbu$hvb$1@dont-email.me> |
| In reply to | #162286 |
On 10/08/2021 09:55, Michael S wrote: > On Tuesday, August 10, 2021 at 1:48:31 AM UTC+3, Bart wrote: >> So what is the upper limit of characters per second that can be >> genuinely displayed in a Linux terminal window? >> >> Assuming a character is a bitmapped 12x16 font, on a 24-bit display, >> then writing one character cell (forget antialiasing and such) involves >> writing 600 bytes to video memory. The 23Mcps figure of Ben's (I think >> 7ms to do 160K characters), would involve writing 13GB/s to video >> memory. And that's without handling scrolling. > > Assuming infinitely fast CPU, the upper limit is a speed of writing characters (not bitmaps!) to main system RAM by app (C RTL) and then reading them back by renderer. So, on high-end desktop with dual-channel DDR4-3200, ~25,000 Mcps. > Ben's results are lower by 3 orders of magnitude. There is plenty of room for improvements ;-) > Of those billions, only 80x25*60 = 120 Kcps should be processed to bitmaps and transferred to graphics hardware. I really meant the upper limit on a real machoine. Otherwise why not assume an infinitely fast renderer too? I've just tried my 1-1000000 program on Linux (don't ask me which one), running on an RPi4 (arm64 but using 32-bit code, I think on a par with my Windows PC). My 1-1000000 loop was pretty quick, but not instant, at something over 6 seconds (my Windows PC took 88 seconds), with 0 lines of scrollback. Writing the text from a file, using 'cat', was under half that (presumably writing one long string instead of 1000000 short ones, but this made little difference on Windows). However, that test ought to show approx 1000000 different things on the screen (ie. terminal window): for each iteration, a new screen, with a different number on the first row, ought to appear. But 6.4 seconds times 60Hz refresh rate means only about 400 different screenfuls are displayed. This also applies to Windows, which will show 5000 different screenfuls over 88 seconds. At least with gcc/tdm on Windows, you get 40,000 screenshots for your money!
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2021-08-10 02:04 -0700 |
| Message-ID | <c9f2d4b8-119c-4053-b80a-b71fbcfe5298n@googlegroups.com> |
| In reply to | #162280 |
On Tuesday, August 10, 2021 at 1:48:31 AM UTC+3, Bart wrote: > On 09/08/2021 09:29, Michael S wrote: > > On Monday, August 9, 2021 at 3:03:15 AM UTC+3, DFS wrote: > >> On 8/8/2021 6:30 PM, Michael S wrote: > >> > >>> Bart and DFS are unique people with unique capabilities. DFS more so, > >> What are you babbling about? > > > > Your shared love to strange tools that wouldn't in top#5 list of choice of professional and likely not in top#10. > You just don't get it. > > When I drive to the shops I like to use my hatchback, I don't need a > 40-ton truck, or a 747, which are how big and cumbersome those > professional tools appear to me. (And if younger I'd jump on my bike.) I prefer my own feet. > > Who cares about the top 10 anyway? Where was the top 10 when I needed a > tiny, fast HLL language for my 8-bit micros which actually ran ON those > same micros? I've used my own languages ever since. Back in late 70s or early 80s "official" development systems were running on minis that were costing 5-years salary of decent developer. So, tools hosted on something more affordable made a lot of sense, esp. for devs that didn't work for big organization. And obviously the "target" is by definition the most affordable, because you have to have it anyway. Times change. Today a decent development workstation costs less than 1-week salary of crap programmer. > > And when I have to play with C, I prefer my own small C compiler; you > know, that one with the faster printf than gcc/tdm. > > That loooks like mingw-64. The same compiler/libraries that I tried first and that finished the task in 20 msec - 1000 times faster than you (or Bart) reported. > A figure which I think you helped to debunk. But the issue at hand is > what to about the gcc version that runs under the exact same environment > as tcc. > > AFAIK, it's C RTL is based on Microsoft's DLL that was originally distributed with VS2013. > > Recently, they (MSYS2 maintainers) added a variant of library that is called ucrt-something, > > probably based on more up to date Microsoft's DLL. I didn't try it yet. > > > > I didn't see the slowness because I was running it from msys2 command window, i.e. the same environment in which that it was tested by maintainers. > > When I take generated exe file and try to run it in regular windows command window (cmd.exe) > > or in powershell window then I see extreme slowness - order of 4.5 sec in cmd.exe and 6.5 sec in powereshell. > > When I changed the size of cmd window to "traditional" defaults of 80x25, it slowed down to 6 seconds. > OK, that's more helpful. Now run tcc in the same way, or just use any > means to write the equivalent text to a file, and use TYPE to display > it. If that's much faster than doing it from the gcc-compiled program, > then you've reproduced the problem. > > We don't need it 1000 times faster, just as fast as TYPE. > > > >> > >> $gcc -Wall source.c -o prog.exe > >> > >> created a huge executable that ran printf() very slowly. > >> > > > > Huge executive is due to presence of symbols. gcc -s (symbols stripped) is just big, not huge. > > > > Slowness is due to interaction between startup code in mingw64 library and windows command prompt environment, > > probably not provisioned by maintainers since they expect their console programs to be run under msys2. > > > > As said by several people here, under such combo stdout behaves as unbuffered. So, 160,000 system calls. > > By themselves, 160,000 system calls are not particularly slow, but Windows console subsystem seems obliged > > to redraw the whole window each time the character does not fit in window width. > Huh? The timings I get strongly suggest that something that should be > done per-string, is getting done per-character. Nothing to do with > window width, which is anyway a long way the other side of the C runtime > library they both end up calling. > >> gcc Windows: slow 3.15s > >> tcc Windows: quick 0.24s > >> gcc Linux : incredibly quick (like 0.01, no time to blink) > >> > > > > 0.01 I'd call o.k. rather than "incredibly quick" > So what is the upper limit of characters per second that can be > genuinely displayed in a Linux terminal window? > > Assuming a character is a bitmapped 12x16 font, on a 24-bit display, > then writing one character cell (forget antialiasing and such) involves > writing 600 bytes to video memory. The 23Mcps figure of Ben's (I think > 7ms to do 160K characters), would involve writing 13GB/s to video > memory. And that's without handling scrolling.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2021-08-10 09:42 -0700 |
| Message-ID | <f8744545-f3ce-4645-95d7-b47d3ff0b4e4n@googlegroups.com> |
| In reply to | #162280 |
On Tuesday, August 10, 2021 at 1:48:31 AM UTC+3, Bart wrote: > On 09/08/2021 09:29, Michael S wrote: > > On Monday, August 9, 2021 at 3:03:15 AM UTC+3, DFS wrote: > >> On 8/8/2021 6:30 PM, Michael S wrote: > >> > >>> Bart and DFS are unique people with unique capabilities. DFS more so, > >> What are you babbling about? > > > > Your shared love to strange tools that wouldn't in top#5 list of choice of professional and likely not in top#10. > You just don't get it. > > When I drive to the shops I like to use my hatchback, I don't need a > 40-ton truck, or a 747, which are how big and cumbersome those > professional tools appear to me. (And if younger I'd jump on my bike.) > > Who cares about the top 10 anyway? Where was the top 10 when I needed a > tiny, fast HLL language for my 8-bit micros which actually ran ON those > same micros? I've used my own languages ever since. > > And when I have to play with C, I prefer my own small C compiler; you > know, that one with the faster printf than gcc/tdm. > > That loooks like mingw-64. The same compiler/libraries that I tried first and that finished the task in 20 msec - 1000 times faster than you (or Bart) reported. > A figure which I think you helped to debunk. But the issue at hand is > what to about the gcc version that runs under the exact same environment > as tcc. > > AFAIK, it's C RTL is based on Microsoft's DLL that was originally distributed with VS2013. > > Recently, they (MSYS2 maintainers) added a variant of library that is called ucrt-something, > > probably based on more up to date Microsoft's DLL. I didn't try it yet. > > > > I didn't see the slowness because I was running it from msys2 command window, i.e. the same environment in which that it was tested by maintainers. > > When I take generated exe file and try to run it in regular windows command window (cmd.exe) > > or in powershell window then I see extreme slowness - order of 4.5 sec in cmd.exe and 6.5 sec in powereshell. > > When I changed the size of cmd window to "traditional" defaults of 80x25, it slowed down to 6 seconds. > OK, that's more helpful. Now run tcc in the same way, or just use any > means to write the equivalent text to a file, and use TYPE to display > it. If that's much faster than doing it from the gcc-compiled program, > then you've reproduced the problem. > > We don't need it 1000 times faster, just as fast as TYPE. > > > >> > >> $gcc -Wall source.c -o prog.exe > >> > >> created a huge executable that ran printf() very slowly. > >> > > > > Huge executive is due to presence of symbols. gcc -s (symbols stripped) is just big, not huge. > > > > Slowness is due to interaction between startup code in mingw64 library and windows command prompt environment, > > probably not provisioned by maintainers since they expect their console programs to be run under msys2. > > > > As said by several people here, under such combo stdout behaves as unbuffered. So, 160,000 system calls. > > By themselves, 160,000 system calls are not particularly slow, but Windows console subsystem seems obliged > > to redraw the whole window each time the character does not fit in window width. > Huh? The timings I get strongly suggest that something that should be > done per-string, is getting done per-character. Nothing to do with > window width, which is anyway a long way the other side of the C runtime > library they both end up calling. I checked again. Shorter lines that do not cause screen width overflow (Your original test, modified by changing format string to "%-16s\n") are printed faster than ultra-long lines in original test. The difference is not big, around 25%, but consistent. > >> gcc Windows: slow 3.15s > >> tcc Windows: quick 0.24s > >> gcc Linux : incredibly quick (like 0.01, no time to blink) > >> > > > > 0.01 I'd call o.k. rather than "incredibly quick" > So what is the upper limit of characters per second that can be > genuinely displayed in a Linux terminal window? > > Assuming a character is a bitmapped 12x16 font, on a 24-bit display, > then writing one character cell (forget antialiasing and such) involves > writing 600 bytes to video memory. The 23Mcps figure of Ben's (I think > 7ms to do 160K characters), would involve writing 13GB/s to video > memory. And that's without handling scrolling.
[toc] | [prev] | [next] | [standalone]
| From | antispam@math.uni.wroc.pl |
|---|---|
| Date | 2021-08-11 17:19 +0000 |
| Message-ID | <sf10rj$7g9$1@z-news.wcss.wroc.pl> |
| In reply to | #162280 |
Bart <bc@freeuk.com> wrote:
> On 09/08/2021 09:29, Michael S wrote:
> > On Monday, August 9, 2021 at 3:03:15 AM UTC+3, DFS wrote:
> >> On 8/8/2021 6:30 PM, Michael S wrote:
> >>
> >>> Bart and DFS are unique people with unique capabilities. DFS more so,
> >> What are you babbling about?
> >
> > Your shared love to strange tools that wouldn't in top#5 list of choice of professional and likely not in top#10.
>
> You just don't get it.
>
> When I drive to the shops I like to use my hatchback, I don't need a
> 40-ton truck, or a 747, which are how big and cumbersome those
> professional tools appear to me. (And if younger I'd jump on my bike.)
>
> Who cares about the top 10 anyway? Where was the top 10 when I needed a
> tiny, fast HLL language for my 8-bit micros which actually ran ON those
> same micros? I've used my own languages ever since.
>
> And when I have to play with C, I prefer my own small C compiler; you
> know, that one with the faster printf than gcc/tdm.
I like small and fast programs. But here it looks like
you really want to mislead other folks. First, what
you are measuring is speed of Windows console. IIUC
correctly what you wrote in your case Windows console
is fast enough: if you read printed text time spent
in console will be negligible compared to time spent
reading. And if console were too slow simple way
to solve problem is to get faster console: AFAICS
other folks pointed out that Microsoft provides
faster console and consoles from third party
(Cygwin and Msys) are faster too.
Second, any semi-decent tool to measure exection
time will tell you that time spent in your program
is negligible and basically 100% of time is
spent in Windows console. But instead of telling
that Windows console has a quirk which make it
much slower with one way of driving it (which
happen to be used by your gcc/tdm package) you
spin it as "gcc is slower than tcc".
Third, every programmer must understand importance
of being precise: programmer job is tell computer
what to do and if programer is not precise
enough computer will reject the task or do wrong
thing. Other explaned you difference between
gcc and package that you get. This distinction
matters because it tells you where to report
problem. In your case, if you honestly do
not know which part is responsible, then it
is resonable to report problems to whoever is
behind TDM project. OTOH, if you think that
problem is in core gcc, then it is resonable
to report it to gcc folks (since your version
is quite old you may get answer "fixed in
newer release", but that is another topic).
If you identify specific library or tool it
makes sense to report problem to authors
of problematic components.
If report to gcc folks problem with Windows console,
do not expect nice answer: it is not part that
they supply.
Forth, you are jumping to conclusion: you do not
know why printf in your gcc/tdm package is doing
output in the specific way. It may be a bug.
But to do this requires some effort, so there
may be deeper reason. Namely, Windows console
is quirky, and "slow" way may be reasonable
way to get correct output in all cases. I mean,
there are bugs where simple fix is to force
"slow" mode of operation. If "slow" mode is
fast enough, then this may be resonable fix
(fast enoug correct program is much better than
much faster incorrect one). Note: I do not have
specific info, but AFAICS you too do not know why
this is done. Before knowing reasons claim like
"printf gcc/tdm in slower" are jumping to conclusion.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-08-11 20:04 +0100 |
| Message-ID | <sf1712$t4a$1@dont-email.me> |
| In reply to | #162322 |
On 11/08/2021 18:19, antispam@math.uni.wroc.pl wrote: > Bart <bc@freeuk.com> wrote: >> And when I have to play with C, I prefer my own small C compiler; you >> know, that one with the faster printf than gcc/tdm. > > I like small and fast programs. But here it looks like > you really want to mislead other folks. I gave timings for bcc, tcc, gcc**, clang**, CL, DMC and lccwin. There was a mixup over the ones marked ** which is explained below. But some gcc/clang versions were much slower. lccwin was in between. > First, what > you are measuring is speed of Windows console. IIUC > correctly what you wrote in your case Windows console > is fast enough: if you read printed text time spent > in console will be negligible compared to time spent > reading. And if console were too slow simple way > to solve problem is to get faster console: AFAICS > other folks pointed out that Microsoft provides > faster console and consoles from third party > (Cygwin and Msys) are faster too. That's not really relevant. All compilers were running the same program under the same OS and with the same, bog-standard MS Command Prompt. If one compiler exhibits much slower behaviour, then it's odd to suspect the console first. > Second, any semi-decent tool to measure exection > time will tell you that time spent in your program > is negligible and basically 100% of time is > spent in Windows console. But instead of telling > that Windows console has a quirk which make it > much slower with one way of driving it (which > happen to be used by your gcc/tdm package) you > spin it as "gcc is slower than tcc". DFS has observed the effect; I have observed it. Other who haven't observed it haven't been using the same platform or the right compilers. However I've just done another test, and it is only one specific gcc and clang installation which has that problem, at least, of the ones I have. So: gcc/tdm 9.2.0 OK clang/LLVM 11.0.0 OK gcc/11.2.0 Slow, both of these from Winlib link clang 12.0.1 Slow The winlib gcc installs itself in such a way that it becomes the default 'gcc' version, and also confusingly provides clang.exe which then the default 'clang'. I'm now upgraded my gcc/tdm to 10.3.0, and that is slow too: gcc/tdm 10.3.0 Slow (there is no clang) So my comments about gcc/tdm having the problem, although made erroneously, are actually correct. > Third, every programmer must understand importance > of being precise: programmer job is tell computer > what to do and if programer is not precise > enough computer will reject the task or do wrong > thing. Other explaned you difference between > gcc and package that you get. This distinction > matters because it tells you where to report > problem. In your case, if you honestly do > not know which part is responsible, then it > is resonable to report problems to whoever is > behind TDM project. If you look at my first post on the subject (8-8-21 15:41 BST) it was to confirm what DFS had observed, and I suggested a workaround. But everyone seems very keen to challenge what I'd said. > OTOH, if you think that > problem is in core gcc, then it is resonable > to report it to gcc folks (since your version > is quite old you may get answer "fixed in > newer release", but that is another topic). > If you identify specific library or tool it > makes sense to report problem to authors > of problematic components. I really have no idea who's reponsible for what. And I don't care as it's not my product so not my headache. (It's also, now, exhibited on two separate builds: gcc/tdm 10.3.0, from FSF Inc, and gcc 11.2.0 from chap called Brecht Sanders.) > Forth, you are jumping to conclusion: you do not > know why printf in your gcc/tdm package is doing > output in the specific way. No, I don't, but that's what it does.
[toc] | [prev] | [next] | [standalone]
| From | antispam@math.uni.wroc.pl |
|---|---|
| Date | 2021-08-11 20:19 +0000 |
| Message-ID | <sf1bdc$pa9$1@z-news.wcss.wroc.pl> |
| In reply to | #162332 |
Bart <bc@freeuk.com> wrote:
> On 11/08/2021 18:19, antispam@math.uni.wroc.pl wrote:
> > Bart <bc@freeuk.com> wrote:
>
> >> And when I have to play with C, I prefer my own small C compiler; you
> >> know, that one with the faster printf than gcc/tdm.
> >
> > I like small and fast programs. But here it looks like
> > you really want to mislead other folks.
>
> I gave timings for bcc, tcc, gcc**, clang**, CL, DMC and lccwin.
>
> There was a mixup over the ones marked ** which is explained below. But
> some gcc/clang versions were much slower. lccwin was in between.
>
>
> > First, what
> > you are measuring is speed of Windows console. IIUC
> > correctly what you wrote in your case Windows console
> > is fast enough: if you read printed text time spent
> > in console will be negligible compared to time spent
> > reading. And if console were too slow simple way
> > to solve problem is to get faster console: AFAICS
> > other folks pointed out that Microsoft provides
> > faster console and consoles from third party
> > (Cygwin and Msys) are faster too.
>
> That's not really relevant. All compilers were running the same program
> under the same OS and with the same, bog-standard MS Command Prompt.
>
> If one compiler exhibits much slower behaviour, then it's odd to suspect
> the console first.
Why odd. On my Linux machine running program that you
provided I get:
time ./b1
<lot of output>
1234567890 1234567890 1234567890 1234567890 1234567890
real 0m0.282s
user 0m0.012s
sys 0m0.000s
That says that program took 12ms CPU time to run, while real time
between start and finish is 282ms. It is odd to not notice that
most real time is spent _outside_ program. And the clear suspect
for causing bigger real time is console. AFAIK Windows has also
tools that allow you to see this.
And even if you have no tools it is rater easy to estimate time
spent in your program, and even 282ms that I see is much bigger
than any resonable estimate of runtime (and 3s that you reported
is really way off).
And simple way to isolate console effects is output to a file,
you know that this is much faster, so you really have no
excuse.
> > Second, any semi-decent tool to measure exection
> > time will tell you that time spent in your program
> > is negligible and basically 100% of time is
> > spent in Windows console. But instead of telling
> > that Windows console has a quirk which make it
> > much slower with one way of driving it (which
> > happen to be used by your gcc/tdm package) you
> > spin it as "gcc is slower than tcc".
>
> DFS has observed the effect; I have observed it. Other who haven't
> observed it haven't been using the same platform or the right compilers.
The point is what "the effect" is! If you mean execution
time of your program, then without any measurement I know
that it is negligile. If you measured, you will know to.
Or rather, you already know, but you prefer doing propaganda.
Put it differently: when you throw pathological program at
gcc and gcc takes long time to compile it, this is gcc problem.
When library bundled with your gcc install sends output to
window console that causes long execution time in console
that is gcc problem. When your compiler has trouble
with some code this is also gcc problem, without gcc
people would write simpler code that your compiler can
handle.
Note: I do not dispute your observations, but what they
mean.
> > Third, every programmer must understand importance
> > of being precise: programmer job is tell computer
> > what to do and if programer is not precise
> > enough computer will reject the task or do wrong
> > thing. Other explaned you difference between
> > gcc and package that you get. This distinction
> > matters because it tells you where to report
> > problem. In your case, if you honestly do
> > not know which part is responsible, then it
> > is resonable to report problems to whoever is
> > behind TDM project.
>
> If you look at my first post on the subject (8-8-21 15:41 BST) it was to
> confirm what DFS had observed, and I suggested a workaround.
>
> But everyone seems very keen to challenge what I'd said.
DFS can be excused as he apparently does not know what
happened. You know, but prefer misleading formulation.
> > OTOH, if you think that
> > problem is in core gcc, then it is resonable
> > to report it to gcc folks (since your version
> > is quite old you may get answer "fixed in
> > newer release", but that is another topic).
> > If you identify specific library or tool it
> > makes sense to report problem to authors
> > of problematic components.
>
> I really have no idea who's reponsible for what. And I don't care as
> it's not my product so not my headache.
If you do not care, then why so much fuss? Here you are responding
to DFS, but there were many threads started by you.
> (It's also, now, exhibited on two separate builds: gcc/tdm 10.3.0, from
> FSF Inc, and gcc 11.2.0 from chap called Brecht Sanders.)
>
> > Forth, you are jumping to conclusion: you do not
> > know why printf in your gcc/tdm package is doing
> > output in the specific way.
>
> No, I don't, but that's what it does.
>
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | DFS <nospam@dfs.com> |
|---|---|
| Date | 2021-08-11 16:51 -0400 |
| Message-ID | <8LWQI.11440$fI7.7665@fx33.iad> |
| In reply to | #162336 |
On 8/11/2021 4:19 PM, antispam@math.uni.wroc.pl wrote: > DFS can be excused as he apparently does not know what > happened. I didn't know why at first, but Kaz Kylheku explained it: the speed difference in printf() is due to the implementation used in tcc (msvcrt.dll) vs that used in mingw gcc. I tried to find printf() code in the source for gcc 11.1.0, but couldn't. Do you know how to find it?
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2021-08-11 21:33 +0000 |
| Message-ID | <0nXQI.2130$3w6.1020@fx26.iad> |
| In reply to | #162338 |
DFS <nospam@dfs.com> writes: >On 8/11/2021 4:19 PM, antispam@math.uni.wroc.pl wrote: > >> DFS can be excused as he apparently does not know what >> happened. > >I didn't know why at first, but Kaz Kylheku explained it: the speed >difference in printf() is due to the implementation used in tcc >(msvcrt.dll) vs that used in mingw gcc. > >I tried to find printf() code in the source for gcc 11.1.0, but >couldn't. Do you know how to find it? As Keith has attempted to explain to Bart, repeatedly, printf is not part of the compiler. It is just a library function called like any other function. The source for printf will be available in the source package corresponding to the library that your application links with. If it's msvcrt.dll, you'll need to ask Microsoft for the source. https://sourceware.org/git/?p=glibc.git;a=blob;f=stdio-common/printf.c;h=1a98662f9321fae6b04735b99e06a89bef931d51;hb=HEAD
[toc] | [prev] | [next] | [standalone]
| From | DFS <nospam@dfs.com> |
|---|---|
| Date | 2021-08-11 19:10 -0400 |
| Message-ID | <zNYQI.17288$lK.7847@fx41.iad> |
| In reply to | #162342 |
On 8/11/2021 5:33 PM, Scott Lurndal wrote: > DFS <nospam@dfs.com> writes: >> On 8/11/2021 4:19 PM, antispam@math.uni.wroc.pl wrote: >> >>> DFS can be excused as he apparently does not know what >>> happened. >> >> I didn't know why at first, but Kaz Kylheku explained it: the speed >> difference in printf() is due to the implementation used in tcc >> (msvcrt.dll) vs that used in mingw gcc. >> >> I tried to find printf() code in the source for gcc 11.1.0, but >> couldn't. Do you know how to find it? > > As Keith has attempted to explain to Bart, repeatedly, printf is > not part of the compiler. It is just a library function called > like any other function. > > The source for printf will be available in the source package > corresponding to the library that your application links with. > > If it's msvcrt.dll, you'll need to ask Microsoft for the source. > > https://sourceware.org/git/?p=glibc.git;a=blob;f=stdio-common/printf.c;h=1a98662f9321fae6b04735b99e06a89bef931d51;hb=HEAD Thanks
[toc] | [prev] | [next] | [standalone]
| From | antispam@math.uni.wroc.pl |
|---|---|
| Date | 2021-08-12 16:08 +0000 |
| Message-ID | <sf3h1q$cdn$2@z-news.wcss.wroc.pl> |
| In reply to | #162338 |
DFS <nospam@dfs.com> wrote:
> On 8/11/2021 4:19 PM, antispam@math.uni.wroc.pl wrote:
>
> > DFS can be excused as he apparently does not know what
> > happened.
>
> I didn't know why at first, but Kaz Kylheku explained it: the speed
> difference in printf() is due to the implementation used in tcc
> (msvcrt.dll) vs that used in mingw gcc.
That is the trigger. But when you outut to Windows console
almost all time is spent in console code and graphic
processing (possibly inside a GPU). IIRC other folks noted
that char-by-char output slows console quite a lot. Outputting
to a file is simple way to isolate console effects, even with
char-by-char (unbuffered) output file will be much faster
than console (of course, exact speed will depend in speed
of system callse).
> I tried to find printf() code in the source for gcc 11.1.0, but
> couldn't. Do you know how to find it?
As other explained, printf is library function so you should look
for sources of library that you use (but apparently, on Windows
after some intial stage it will go to closed-source Microsoft library).
Inside gcc you may search for 'builtin_printf'. In particular,
gcc may optimize some prinft variants to simpler versions.
In older versions of gcc relevant file was 'gcc/builtins.c'.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2021-08-08 19:56 +0000 |
| Message-ID | <WFWPI.1865$un2.1665@fx04.iad> |
| In reply to | #162250 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>Bart <bc@freeuk.com> writes:
>
>>> 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.
>
>You often post times with no indication of what's being measured. The
>compiler probably has little to do with it. What C library is being
>used? How is the output handled? On my laptop, compiled with gcc
>10.3.0 and linked against libc6 version 2.33, it's almost too fast to
>measure:
>
>$ time ./o >/dev/null
>
>real 0m0.007s
>user 0m0.004s
>sys 0m0.004s
An aggressive optimizer (speed vs space) could optimize it
into a single puts of a 160,000 character string.
[toc] | [prev] | [next] | [standalone]
| From | DFS <nospam@dfs.com> |
|---|---|
| Date | 2021-08-10 14:35 -0700 |
| Message-ID | <FiCQI.401$uk4.259@fx20.iad> |
| In reply to | #162253 |
On 8/8/2021 12:56 PM, Scott Lurndal wrote:
> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>> Bart <bc@freeuk.com> writes:
>>
>>>> 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.
>>
>> You often post times with no indication of what's being measured. The
>> compiler probably has little to do with it. What C library is being
>> used? How is the output handled? On my laptop, compiled with gcc
>> 10.3.0 and linked against libc6 version 2.33, it's almost too fast to
>> measure:
>>
>> $ time ./o >/dev/null
>>
>> real 0m0.007s
>> user 0m0.004s
>> sys 0m0.004s
>
> An aggressive optimizer (speed vs space) could optimize it
> into a single puts of a 160,000 character string.
=================================================================
//option 1: one puts per line (suggested by bart)
int i = 0;
char buff[longword+3];
char line[tcols];
*line = '\0';
while(i < matchcnt) {
for(int j = 1;j<=maxcols;j++) {
sprintf(buff,"%-*s ",longword,matchwords[i++]);
strcat(line,buff);
}
puts(line);
*buff = '\0';
*line = '\0';
}
=================================================================
//option 2: one big string, one puts (per Lurndal)
int i = 0;
char buff[longword+3];
char line[(longword + 3) * matchcnt];
*line = '\0';
while(i < matchcnt) {
for(int j = 1;j<=maxcols;j++) {
sprintf(buff,"%-*s ",longword,matchwords[i++]);
strcat(line,buff);
}
*buff = '\0';
strcat(line,"\n");
}
puts(line);
=================================================================
726 words across 5 columns
option 1: 0.06s
option 2: 0.05s
A significant speed increase.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2021-08-10 21:41 +0000 |
| Message-ID | <poCQI.37363$EF2.25668@fx47.iad> |
| In reply to | #162299 |
DFS <nospam@dfs.com> writes:
>On 8/8/2021 12:56 PM, Scott Lurndal wrote:
>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>> Bart <bc@freeuk.com> writes:
>>>
>>>>> 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.
>>>
>>> You often post times with no indication of what's being measured. The
>>> compiler probably has little to do with it. What C library is being
>>> used? How is the output handled? On my laptop, compiled with gcc
>>> 10.3.0 and linked against libc6 version 2.33, it's almost too fast to
>>> measure:
>>>
>>> $ time ./o >/dev/null
>>>
>>> real 0m0.007s
>>> user 0m0.004s
>>> sys 0m0.004s
>>
>> An aggressive optimizer (speed vs space) could optimize it
>> into a single puts of a 160,000 character string.
>
>=================================================================
>
>//option 1: one puts per line (suggested by bart)
>int i = 0;
>char buff[longword+3];
>char line[tcols];
>*line = '\0';
>while(i < matchcnt) {
> for(int j = 1;j<=maxcols;j++) {
> sprintf(buff,"%-*s ",longword,matchwords[i++]);
> strcat(line,buff);
> }
> puts(line);
> *buff = '\0';
> *line = '\0';
>}
>
>=================================================================
>
>//option 2: one big string, one puts (per Lurndal)
>int i = 0;
>char buff[longword+3];
>char line[(longword + 3) * matchcnt];
>*line = '\0';
>while(i < matchcnt) {
> for(int j = 1;j<=maxcols;j++) {
> sprintf(buff,"%-*s ",longword,matchwords[i++]);
> strcat(line,buff);
> }
> *buff = '\0';
> strcat(line,"\n");
>}
>puts(line);
>
>=================================================================
>
>
>726 words across 5 columns
>option 1: 0.06s
>option 2: 0.05s
>
>A significant speed increase.
I was suggesting that the compiler could have just
stored a 160k string in RO storage and called puts
with a pointer to it. There is no need to construct
it at runtime.
The entire program would reduce to a single call
to puts with a compiler generated constant string.
[toc] | [prev] | [next] | [standalone]
| From | DFS <nospam@dfs.com> |
|---|---|
| Date | 2021-08-10 15:08 -0700 |
| Message-ID | <VNCQI.5685$Ug5.514@fx24.iad> |
| In reply to | #162300 |
On 8/10/2021 2:41 PM, Scott Lurndal wrote:
> DFS <nospam@dfs.com> writes:
>> On 8/8/2021 12:56 PM, Scott Lurndal wrote:
>>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>>> Bart <bc@freeuk.com> writes:
>>>>
>>>>>> 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.
>>>>
>>>> You often post times with no indication of what's being measured. The
>>>> compiler probably has little to do with it. What C library is being
>>>> used? How is the output handled? On my laptop, compiled with gcc
>>>> 10.3.0 and linked against libc6 version 2.33, it's almost too fast to
>>>> measure:
>>>>
>>>> $ time ./o >/dev/null
>>>>
>>>> real 0m0.007s
>>>> user 0m0.004s
>>>> sys 0m0.004s
>>>
>>> An aggressive optimizer (speed vs space) could optimize it
>>> into a single puts of a 160,000 character string.
>>
>> =================================================================
>>
>> //option 1: one puts per line (suggested by bart)
>> int i = 0;
>> char buff[longword+3];
>> char line[tcols];
>> *line = '\0';
>> while(i < matchcnt) {
>> for(int j = 1;j<=maxcols;j++) {
>> sprintf(buff,"%-*s ",longword,matchwords[i++]);
>> strcat(line,buff);
>> }
>> puts(line);
>> *buff = '\0';
>> *line = '\0';
>> }
>>
>> =================================================================
>>
>> //option 2: one big string, one puts (per Lurndal)
>> int i = 0;
>> char buff[longword+3];
>> char line[(longword + 3) * matchcnt];
>> *line = '\0';
>> while(i < matchcnt) {
>> for(int j = 1;j<=maxcols;j++) {
>> sprintf(buff,"%-*s ",longword,matchwords[i++]);
>> strcat(line,buff);
>> }
>> *buff = '\0';
>> strcat(line,"\n");
>> }
>> puts(line);
>>
>> =================================================================
>>
>>
>> 726 words across 5 columns
>> option 1: 0.06s
>> option 2: 0.05s
>>
>> A significant speed increase.
>
> I was suggesting that the compiler could have just
> stored a 160k string in RO storage and called puts
> with a pointer to it. There is no need to construct
> it at runtime.
>
> The entire program would reduce to a single call
> to puts with a compiler generated constant string.
Gotcha.
I just noticed something in my program. Using option 2 above, the
version compiled by tcc crashes when the value in line 3 is large
(1027424). The version compiled by gcc doesn't crash.
Is that a stack overflow issue?
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-08-10 23:22 +0100 |
| Message-ID | <seuu75$il3$1@dont-email.me> |
| In reply to | #162302 |
On 10/08/2021 23:08, DFS wrote:
> On 8/10/2021 2:41 PM, Scott Lurndal wrote:
>> I was suggesting that the compiler could have just
>> stored a 160k string in RO storage and called puts
>> with a pointer to it. There is no need to construct
>> it at runtime.
>>
>> The entire program would reduce to a single call
>> to puts with a compiler generated constant string.
>
> Gotcha.
>
> I just noticed something in my program. Using option 2 above, the
> version compiled by tcc crashes when the value in line 3 is large
> (1027424). The version compiled by gcc doesn't crash.
>
> Is that a stack overflow issue?
>
Yes, you're using VLAs, (maybe in option 1 too if longword and tcols are
not compile-time constants).
Typical stack size is a few MB. It seems the default stack size of tcc
is smaller than of gcc**. tcc crashes with this:
int n=2000000;
char str[n];
memset(str,0,n);
but gcc doesn't, until you change n to 4000000. If I dump the two
executables, then the gcc one contains this:
Stack reserve: 2097152
Stack commit: 4096
tcc's has:
Stack reserve: 1048576
Stack commit: 4096
There are probably ways of increasing the stack size, but better not to
use VLAs for arrays of this size. (Use static arrays or allocate on the
heap.)
(**For the pedantics here, this is not *the* gcc, but my tdm/gcc
version. However the mingw64 version does the same.)
[toc] | [prev] | [next] | [standalone]
| From | DFS <nospam@dfs.com> |
|---|---|
| Date | 2021-08-10 20:15 -0400 |
| Message-ID | <TEEQI.5686$Ug5.143@fx24.iad> |
| In reply to | #162303 |
On 8/10/2021 6:22 PM, Bart wrote:
> On 10/08/2021 23:08, DFS wrote:
>> On 8/10/2021 2:41 PM, Scott Lurndal wrote:
>
>>> I was suggesting that the compiler could have just
>>> stored a 160k string in RO storage and called puts
>>> with a pointer to it. There is no need to construct
>>> it at runtime.
>>>
>>> The entire program would reduce to a single call
>>> to puts with a compiler generated constant string.
>>
>> Gotcha.
>>
>> I just noticed something in my program. Using option 2 above, the
>> version compiled by tcc crashes when the value in line 3 is large
>> (1027424). The version compiled by gcc doesn't crash.
>>
>> Is that a stack overflow issue?
>>
>
> Yes, you're using VLAs, (maybe in option 1 too if longword and tcols are
> not compile-time constants).
They're not. Longword is the longest word (1 to 31) in a result set,
and tcols is the width of your terminal at the time you do the search.
Here's the app: https://imgur.com/a/cQdvAeM
> Typical stack size is a few MB. It seems the default stack size of tcc
> is smaller than of gcc**. tcc crashes with this:
>
> int n=2000000;
> char str[n];
> memset(str,0,n);
>
> but gcc doesn't, until you change n to 4000000. If I dump the two
> executables, then the gcc one contains this:
>
> Stack reserve: 2097152
> Stack commit: 4096
>
> tcc's has:
>
> Stack reserve: 1048576
> Stack commit: 4096
>
> There are probably ways of increasing the stack size, but better not to
> use VLAs for arrays of this size. (Use static arrays or allocate on the
> heap.)
Thanks. I created a static array[10_000_000] outside the function, and
it handled large results sets just fine. But another issue popped up,
using option 2, which concatenates words one by one into that static
array, then does one puts() at the end.
Turns out it's VERY slow for large result sets.
Option 1 Option 2
substring catt: 91 matches found 0.04s 0.038s
substring cat : 3710 matches found 0.20s 0.16s
substring ca : 22793 matches found 1.39s 2.25s
substring c : 128689 matches found 7.75s 57.91s
substring e : 252896 matches found 15.29s 216.58s
Option 1 starts printing immediately, one line at a time. Option 2 sits
there constructing that long string for quite a while. Too long I
think. What might I be doing wrong?
Note: the timing includes time to print to screen. Just finding the
word matches is 0.03s using either option.
=================================================================
//option 1: one puts per line (suggested by bart)
int i = 0;
char buff[longword+3];
char line[tcols];
*line = '\0';
while(i < matchcnt) {
for(int j = 1;j<=maxcols;j++) {
sprintf(buff,"%-*s ",longword,matchwords[i++]);
strcat(line,buff);
}
puts(line);
*buff = '\0';
*line = '\0';
}
=================================================================
//option 2: one big string, one puts (per Lurndal)
static char line[10000000]; //declared outside the func
int i = 0;
char buff[longword+3];
*line = '\0';
while(i < matchcnt) {
for(int j = 1;j<=maxcols;j++) {
sprintf(buff,"%-*s ",longword,matchwords[i++]);
strcat(line,buff);
}
*buff = '\0';
strcat(line,"\n");
}
puts(line);
=================================================================
[toc] | [prev] | [next] | [standalone]
| From | antispam@math.uni.wroc.pl |
|---|---|
| Date | 2021-08-11 08:34 +0000 |
| Message-ID | <sf021q$78n$1@z-news.wcss.wroc.pl> |
| In reply to | #162305 |
DFS <nospam@dfs.com> wrote:
>
> Thanks. I created a static array[10_000_000] outside the function, and
> it handled large results sets just fine. But another issue popped up,
> using option 2, which concatenates words one by one into that static
> array, then does one puts() at the end.
>
> Turns out it's VERY slow for large result sets.
>
> Option 1 Option 2
> substring catt: 91 matches found 0.04s 0.038s
> substring cat : 3710 matches found 0.20s 0.16s
> substring ca : 22793 matches found 1.39s 2.25s
> substring c : 128689 matches found 7.75s 57.91s
> substring e : 252896 matches found 15.29s 216.58s
>
> Option 1 starts printing immediately, one line at a time. Option 2 sits
> there constructing that long string for quite a while. Too long I
> think. What might I be doing wrong?
>
> Note: the timing includes time to print to screen. Just finding the
> word matches is 0.03s using either option.
>
>
> =================================================================
>
> //option 1: one puts per line (suggested by bart)
> int i = 0;
> char buff[longword+3];
> char line[tcols];
> *line = '\0';
> while(i < matchcnt) {
> for(int j = 1;j<=maxcols;j++) {
> sprintf(buff,"%-*s ",longword,matchwords[i++]);
> strcat(line,buff);
> }
> puts(line);
> *buff = '\0';
> *line = '\0';
> }
>
> =================================================================
>
> //option 2: one big string, one puts (per Lurndal)
> static char line[10000000]; //declared outside the func
>
> int i = 0;
> char buff[longword+3];
> *line = '\0';
> while(i < matchcnt) {
> for(int j = 1;j<=maxcols;j++) {
> sprintf(buff,"%-*s ",longword,matchwords[i++]);
> strcat(line,buff);
^^^^^^^^^^^^^^^^^^
> }
> *buff = '\0';
> strcat(line,"\n");
> }
> puts(line);
>
> =================================================================
The 'strcat' in a loop is classic antipattern: it causes quadratic
complexity to to repeated scanning for end of 'line'. Use something
like
char * cp = line;
.....
strcat(cp, buff);
cp += strlen(buff);
....
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2021-08-11 11:23 +0100 |
| Message-ID | <875ywci8k0.fsf@bsb.me.uk> |
| In reply to | #162306 |
antispam@math.uni.wroc.pl writes:
> DFS <nospam@dfs.com> wrote:
<cut>
>> =================================================================
>>
>> //option 1: one puts per line (suggested by bart)
>> int i = 0;
>> char buff[longword+3];
>> char line[tcols];
>> *line = '\0';
>> while(i < matchcnt) {
>> for(int j = 1;j<=maxcols;j++) {
>> sprintf(buff,"%-*s ",longword,matchwords[i++]);
>> strcat(line,buff);
>> }
>> puts(line);
>> *buff = '\0';
>> *line = '\0';
>> }
>>
>> =================================================================
>>
>> //option 2: one big string, one puts (per Lurndal)
>> static char line[10000000]; //declared outside the func
>>
>> int i = 0;
>> char buff[longword+3];
>> *line = '\0';
>> while(i < matchcnt) {
>> for(int j = 1;j<=maxcols;j++) {
>> sprintf(buff,"%-*s ",longword,matchwords[i++]);
>> strcat(line,buff);
> ^^^^^^^^^^^^^^^^^^
>> }
>> *buff = '\0';
>> strcat(line,"\n");
>> }
>> puts(line);
>>
>> =================================================================
>
> The 'strcat' in a loop is classic antipattern: it causes quadratic
> complexity to to repeated scanning for end of 'line'. Use something
> like
>
> char * cp = line;
> .....
> strcat(cp, buff);
> cp += strlen(buff);
> ....
... or get the length first and use memcpy. But my favourite is
cp += snprintf(cp, "%s", whatever);
--
Ben.
[toc] | [prev] | [next] | [standalone]
Page 11 of 20 — ← Prev page 1 … 9 10 [11] 12 13 … 20 Next page →
Back to top | Article view | comp.lang.c
csiph-web