Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #136032 > unrolled thread
| Started by | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| First post | 2018-10-02 22:37 +0200 |
| Last post | 2018-12-17 15:18 +0000 |
| Articles | 20 on this page of 211 — 33 participants |
Back to article view | Back to comp.lang.c
Counting lines of a file jacobnavia <jacob@jacob.remcomp.fr> - 2018-10-02 22:37 +0200
Re: Counting lines of a file Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2018-10-02 16:45 -0400
Re: Counting lines of a file Ian Collins <ian-news@hotmail.com> - 2018-10-03 09:51 +1300
Re: Counting lines of a file jacobnavia <jacob@jacob.remcomp.fr> - 2018-10-02 22:55 +0200
Re: Counting lines of a file Keith Thompson <kst-u@mib.org> - 2018-10-02 14:31 -0700
Re: Counting lines of a file jacobnavia <jacob@jacob.remcomp.fr> - 2018-10-02 23:39 +0200
Re: Counting lines of a file Keith Thompson <kst-u@mib.org> - 2018-10-02 16:39 -0700
Re: Counting lines of a file jacobnavia <jacob@jacob.remcomp.fr> - 2018-10-03 08:49 +0200
Re: Counting lines of a file Keith Thompson <kst-u@mib.org> - 2018-10-03 11:46 -0700
Re: Counting lines of a file scott@slp53.sl.home (Scott Lurndal) - 2018-10-02 21:04 +0000
Re: Counting lines of a file dave_thompson_2@comcast.net - 2018-12-14 17:52 -0500
Re: Counting lines of a file Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-12-15 08:14 +0000
Re: Counting lines of a file Nick Bowler <nbowler@draconx.ca> - 2018-10-02 21:24 +0000
Re: Counting lines of a file jacobnavia <jacob@jacob.remcomp.fr> - 2018-10-02 23:32 +0200
Re: Counting lines of a file queequeg@trust.no1 (Queequeg) - 2018-10-03 10:44 +0000
Re: Counting lines of a file jacobnavia <jacob@jacob.remcomp.fr> - 2018-10-03 13:17 +0200
Re: Counting lines of a file David Brown <david.brown@hesbynett.no> - 2018-10-03 14:35 +0200
Re: Counting lines of a file Keith Thompson <kst-u@mib.org> - 2018-10-02 14:25 -0700
Re: Counting lines of a file jacobnavia <jacob@jacob.remcomp.fr> - 2018-10-02 22:54 +0200
Re: Counting lines of a file jacobnavia <jacob@jacob.remcomp.fr> - 2018-10-02 23:43 +0200
Re: Counting lines of a file Andreas Perstinger <andipersti@gmail.com> - 2018-10-05 11:35 +0000
Re: Counting lines of a file Nick Bowler <nbowler@draconx.ca> - 2018-10-02 20:56 +0000
Re: Counting lines of a file jacobnavia <jacob@jacob.remcomp.fr> - 2018-10-02 23:00 +0200
Re: Counting lines of a file Nick Bowler <nbowler@draconx.ca> - 2018-10-02 21:13 +0000
Re: Counting lines of a file jacobnavia <jacob@jacob.remcomp.fr> - 2018-10-02 23:28 +0200
Re: Counting lines of a file queequeg@trust.no1 (Queequeg) - 2018-10-03 10:48 +0000
Re: Counting lines of a file Bart <bc@freeuk.com> - 2018-10-03 12:07 +0100
Re: Counting lines of a file David Brown <david.brown@hesbynett.no> - 2018-10-03 14:49 +0200
Re: Counting lines of a file Bart <bc@freeuk.com> - 2018-10-03 14:25 +0100
Re: Counting lines of a file David Brown <david.brown@hesbynett.no> - 2018-10-03 16:05 +0200
Re: Counting lines of a file scott@slp53.sl.home (Scott Lurndal) - 2018-10-03 14:17 +0000
Re: Counting lines of a file Bart <bc@freeuk.com> - 2018-10-03 16:53 +0100
Re: Counting lines of a file scott@slp53.sl.home (Scott Lurndal) - 2018-10-03 16:07 +0000
Re: Counting lines of a file David Brown <david.brown@hesbynett.no> - 2018-10-04 15:12 +0200
Re: Counting lines of a file Keith Thompson <kst-u@mib.org> - 2018-10-03 11:23 -0700
Re: Counting lines of a file jacobnavia <jacob@jacob.remcomp.fr> - 2018-10-03 20:42 +0200
Re: Counting lines of a file Keith Thompson <kst-u@mib.org> - 2018-10-03 12:03 -0700
Re: Counting lines of a file jacobnavia <jacob@jacob.remcomp.fr> - 2018-10-03 21:45 +0200
Re: Counting lines of a file Ian Collins <ian-news@hotmail.com> - 2018-10-04 08:52 +1300
Re: Counting lines of a file Keith Thompson <kst-u@mib.org> - 2018-10-03 13:26 -0700
Re: Counting lines of a file David Brown <david.brown@hesbynett.no> - 2018-10-04 15:37 +0200
Re: Counting lines of a file Bart <bc@freeuk.com> - 2018-10-04 15:06 +0100
Re: Counting lines of a file David Brown <david.brown@hesbynett.no> - 2018-10-04 21:48 +0200
Re: Counting lines of a file David Brown <david.brown@hesbynett.no> - 2018-10-04 15:28 +0200
Re: Counting lines of a file gazelle@shell.xmission.com (Kenny McCormack) - 2018-10-04 14:16 +0000
Re: Counting lines of a file Keith Thompson <kst-u@mib.org> - 2018-10-04 11:09 -0700
Re: Counting lines of a file David Brown <david.brown@hesbynett.no> - 2018-10-04 22:00 +0200
Re: Counting lines of a file Bart <bc@freeuk.com> - 2018-10-04 21:18 +0100
Re: Counting lines of a file scott@slp53.sl.home (Scott Lurndal) - 2018-10-04 20:28 +0000
Re: Counting lines of a file Bart <bc@freeuk.com> - 2018-10-04 21:59 +0100
Re: Counting lines of a file scott@slp53.sl.home (Scott Lurndal) - 2018-10-04 21:10 +0000
Re: Counting lines of a file Keith Thompson <kst-u@mib.org> - 2018-10-04 15:53 -0700
Re: Counting lines of a file Bart <bc@freeuk.com> - 2018-10-05 00:09 +0100
Re: Counting lines of a file Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-05 02:06 +0100
Re: Counting lines of a file jacobnavia <jacob@jacob.remcomp.fr> - 2018-10-04 22:40 +0200
Re: Counting lines of a file scott@slp53.sl.home (Scott Lurndal) - 2018-10-04 21:13 +0000
Re: Counting lines of a file Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-04 23:09 +0100
Re: Counting lines of a file jacobnavia <jacob@jacob.remcomp.fr> - 2018-10-05 07:47 +0200
Re: Counting lines of a file David Brown <david.brown@hesbynett.no> - 2018-10-05 09:44 +0200
Re: Counting lines of a file jacobnavia <jacob@jacob.remcomp.fr> - 2018-10-05 12:41 +0200
Re: Counting lines of a file David Brown <david.brown@hesbynett.no> - 2018-10-05 16:01 +0200
Re: Counting lines of a file Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-10-22 13:58 +0000
Re: Counting lines of a file David Brown <david.brown@hesbynett.no> - 2018-10-22 16:44 +0200
Re: Counting lines of a file jadill33@gmail.com - 2018-10-08 09:10 -0700
Re: Counting lines of a file Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-05 13:17 +0100
Re: Counting lines of a file already5chosen@yahoo.com - 2018-10-03 11:34 -0700
Re: Counting lines of a file jacobnavia <jacob@jacob.remcomp.fr> - 2018-10-03 13:14 +0200
Re: Counting lines of a file Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-04 00:59 +0100
Re: Counting lines of a file jacobnavia <jacob@jacob.remcomp.fr> - 2018-10-04 08:57 +0200
Re: Counting lines of a file Ian Collins <ian-news@hotmail.com> - 2018-10-04 20:05 +1300
Re: Counting lines of a file Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-04 10:58 +0100
Re: Counting lines of a file Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-10-04 04:06 -0700
Re: Counting lines of a file Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-04 15:35 +0100
Re: Counting lines of a file Bart <bc@freeuk.com> - 2018-10-04 11:48 +0100
Re: Counting lines of a file Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-04 15:30 +0100
Re: Counting lines of a file queequeg@trust.no1 (Queequeg) - 2018-10-04 21:35 +0000
Re: Counting lines of a file jacobnavia <jacob@jacob.remcomp.fr> - 2018-10-05 07:35 +0200
Re: Counting lines of a file Ike Naar <ike@sdf.lonestar.org> - 2018-10-06 23:56 +0000
Re: Counting lines of a file jacobnavia <jacob@jacob.remcomp.fr> - 2018-10-07 09:13 +0200
Re: Counting lines of a file Ike Naar <ike@iceland.freeshell.org> - 2018-10-11 22:14 +0000
Re: Counting lines of a file Ralf Damaschke <rwspam@gmx.de> - 2018-10-11 23:14 +0000
Re: Counting lines of a file antispam@math.uni.wroc.pl - 2018-12-17 20:17 +0000
Re: Counting lines of a file Keith Thompson <kst-u@mib.org> - 2018-10-02 13:59 -0700
Re: Counting lines of a file Bart <bc@freeuk.com> - 2018-10-02 23:07 +0100
Re: Counting lines of a file Bart <bc@freeuk.com> - 2018-10-03 00:08 +0100
Re: Counting lines of a file Keith Thompson <kst-u@mib.org> - 2018-10-02 16:51 -0700
Re: Counting lines of a file "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-02 17:47 -0400
Re: Counting lines of a file Anton Shepelev <anton.txt@g{oogle}mail.com> - 2018-10-03 11:57 +0300
Re: Counting lines of a file James Kuyper <jameskuyper@alumni.caltech.edu> - 2018-10-03 06:30 -0400
Re: Counting lines of a file Anton Shepelev <anton.txt@g{oogle}mail.com> - 2018-10-03 15:37 +0300
Re: Counting lines of a file "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-03 05:20 -0700
Re: Counting lines of a file "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-03 05:33 -0700
Re: Counting lines of a file "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-03 05:55 -0700
Re: Counting lines of a file Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-03 22:33 +0100
Re: Counting lines of a file "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-03 17:43 -0400
Re: Counting lines of a file Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-04 02:49 +0100
Re: Counting lines of a file "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-03 22:06 -0400
Re: Counting lines of a file gazelle@shell.xmission.com (Kenny McCormack) - 2018-10-04 05:20 +0000
Re: Counting lines of a file already5chosen@yahoo.com - 2018-10-04 02:45 -0700
Re: Counting lines of a file Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-04 14:42 +0100
Re: Counting lines of a file Bart <bc@freeuk.com> - 2018-10-04 11:27 +0100
Re: Counting lines of a file already5chosen@yahoo.com - 2018-10-04 03:40 -0700
Re: Counting lines of a file Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-04 15:17 +0100
Re: Counting lines of a file Bart <bc@freeuk.com> - 2018-10-04 18:13 +0100
Re: Counting lines of a file scott@slp53.sl.home (Scott Lurndal) - 2018-10-04 17:47 +0000
Re: Counting lines of a file Bart <bc@freeuk.com> - 2018-10-04 20:49 +0100
Re: Counting lines of a file nobody@example.org (Scott) - 2018-10-05 16:52 +0000
Re: Counting lines of a file Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-05 01:49 +0100
Re: Counting lines of a file Bart <bc@freeuk.com> - 2018-10-05 12:08 +0100
Re: Counting lines of a file Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-06 03:24 +0100
Re: Counting lines of a file Spiros Bousbouras <spibou@gmail.com> - 2018-10-06 03:47 +0000
Re: Counting lines of a file Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-06 14:41 +0100
Re: Counting lines of a file Spiros Bousbouras <spibou@gmail.com> - 2018-10-06 15:05 +0000
Re: Counting lines of a file Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-06 20:08 +0100
Re: Counting lines of a file Bart <bc@freeuk.com> - 2018-10-06 13:02 +0100
Re: Counting lines of a file Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-06 15:51 +0100
Re: Counting lines of a file Bart <bc@freeuk.com> - 2018-10-06 17:15 +0100
Re: Counting lines of a file Keith Thompson <kst-u@mib.org> - 2018-10-06 13:22 -0700
Re: Counting lines of a file Bart <bc@freeuk.com> - 2018-10-06 22:27 +0100
Re: Counting lines of a file Ian Collins <ian-news@hotmail.com> - 2018-10-07 11:55 +1300
Re: Counting lines of a file Bart <bc@freeuk.com> - 2018-10-07 00:02 +0100
Re: Counting lines of a file Ian Collins <ian-news@hotmail.com> - 2018-10-07 12:10 +1300
Re: Counting lines of a file Bart <bc@freeuk.com> - 2018-10-07 01:33 +0100
Re: Counting lines of a file mark.bluemel@gmail.com - 2018-10-08 01:33 -0700
Re: Counting lines of a file Bart <bc@freeuk.com> - 2018-10-08 12:20 +0100
Re: Counting lines of a file Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-06 21:51 +0100
Re: Counting lines of a file already5chosen@yahoo.com - 2018-10-06 12:52 -0700
Re: Counting lines of a file already5chosen@yahoo.com - 2018-10-06 13:01 -0700
Re: Counting lines of a file Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-06 22:01 +0100
Re: Counting lines of a file Keith Thompson <kst-u@mib.org> - 2018-10-06 13:17 -0700
Re: Counting lines of a file antispam@math.uni.wroc.pl - 2018-12-17 20:50 +0000
Re: Counting lines of a file Anton Shepelev <anton.txt@gmail.com> - 2018-10-05 23:09 +0300
Re: Counting lines of a file Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-10-06 04:02 -0700
Re: Counting lines of a file Anton Shepelev <anton.txt@gmail.com> - 2018-10-07 00:29 +0300
Re: Counting lines of a file scott@slp53.sl.home (Scott Lurndal) - 2018-10-04 13:22 +0000
Re: Counting lines of a file "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-04 08:00 -0700
Re: Counting lines of a file scott@slp53.sl.home (Scott Lurndal) - 2018-10-04 15:30 +0000
Re: Counting lines of a file "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-04 08:34 -0700
Re: Counting lines of a file Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-10-04 09:27 -0700
Re: Counting lines of a file "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-04 11:04 -0700
Re: Counting lines of a file Bart <bc@freeuk.com> - 2018-10-03 22:50 +0100
Re: Counting lines of a file Ian Collins <ian-news@hotmail.com> - 2018-10-04 11:30 +1300
Re: Counting lines of a file Keith Thompson <kst-u@mib.org> - 2018-10-03 15:41 -0700
Re: Counting lines of a file Bart <bc@freeuk.com> - 2018-10-04 00:46 +0100
Re: Counting lines of a file Ian Collins <ian-news@hotmail.com> - 2018-10-04 13:01 +1300
Re: Counting lines of a file Bart <bc@freeuk.com> - 2018-10-04 01:22 +0100
Re: Counting lines of a file Ian Collins <ian-news@hotmail.com> - 2018-10-04 13:39 +1300
Re: Counting lines of a file Keith Thompson <kst-u@mib.org> - 2018-10-03 18:23 -0700
Re: Counting lines of a file Bart <bc@freeuk.com> - 2018-10-03 13:33 +0100
Re: Counting lines of a file Anton Shepelev <anton.txt@g{oogle}mail.com> - 2018-10-03 15:40 +0300
Re: Counting lines of a file "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-03 05:57 -0700
Re: Counting lines of a file Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-03 22:19 +0100
Re: Counting lines of a file Ian Collins <ian-news@hotmail.com> - 2018-10-03 11:25 +1300
Re: Counting lines of a file "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-02 18:56 -0400
Re: Counting lines of a file Anton Shepelev <anton.txt@g{oogle}mail.com> - 2018-10-03 12:11 +0300
Re: Counting lines of a file Ian Collins <ian-news@hotmail.com> - 2018-10-03 23:06 +1300
Re: Counting lines of a file Anton Shepelev <ant0n.txt@gmai1.c0m> - 2018-10-03 14:58 +0300
Re: Counting lines of a file Ian Collins <ian-news@hotmail.com> - 2018-10-04 08:08 +1300
Re: Counting lines of a file "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-03 05:06 -0700
Re: Counting lines of a file Anton Shepelev <anton.txt@g{oogle}mail.com> - 2018-10-03 15:13 +0300
Re: Counting lines of a file "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-03 05:26 -0700
Re: Counting lines of a file Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-03 02:59 +0100
Re: Counting lines of a file jacobnavia <jacob@jacob.remcomp.fr> - 2018-10-03 08:57 +0200
Re: Counting lines of a file jacobnavia <jacob@jacob.remcomp.fr> - 2018-10-03 08:59 +0200
Re: Counting lines of a file Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-03 21:54 +0100
Re: Counting lines of a file jacobnavia <jacob@jacob.remcomp.fr> - 2018-10-03 23:26 +0200
Re: Counting lines of a file Bart <bc@freeuk.com> - 2018-10-03 22:41 +0100
Re: Counting lines of a file Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-04 02:23 +0100
Re: Counting lines of a file Keith Thompson <kst-u@mib.org> - 2018-10-03 14:59 -0700
Re: Counting lines of a file Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-04 03:04 +0100
Re: Counting lines of a file jacobnavia <jacob@jacob.remcomp.fr> - 2018-10-03 09:01 +0200
Re: Counting lines of a file Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-03 22:01 +0100
Re: Counting lines of a file jacobnavia <jacob@jacob.remcomp.fr> - 2018-10-03 21:44 +0200
Re: Counting lines of a file "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-03 15:48 -0400
Re: Counting lines of a file Anton Shepelev <anton.txt@gmail.com> - 2018-10-03 23:15 +0300
Re: Counting lines of a file Keith Thompson <kst-u@mib.org> - 2018-10-03 13:35 -0700
Re: Counting lines of a file Anton Shepelev <anton.txt@gmail.com> - 2018-10-04 00:14 +0300
Re: Counting lines of a file Bart <bc@freeuk.com> - 2018-10-03 23:15 +0100
Re: Counting lines of a file Anton Shepelev <anton.txt@gmail.com> - 2018-10-04 23:28 +0300
Re: Counting lines of a file James Kuyper <jameskuyper@alumni.caltech.edu> - 2018-10-03 19:39 -0400
Re: Counting lines of a file Nick Bowler <nbowler@draconx.ca> - 2018-10-04 15:31 +0000
Re: Counting lines of a file Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-04 01:05 +0100
Re: Counting lines of a file jacobnavia <jacob@jacob.remcomp.fr> - 2018-10-04 14:04 +0200
Re: Counting lines of a file Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-04 15:48 +0100
Re: Counting lines of a file jacobnavia <jacob@jacob.remcomp.fr> - 2018-10-05 18:29 +0200
Re: Counting lines of a file Joey Pabalinas <joeypabalinas@gmail.com> - 2018-12-16 07:50 -1000
Re: Counting lines of a file Joey Pabalinas <joeypabalinas@gmail.com> - 2018-12-16 07:54 -1000
Re: Counting lines of a file rbowman <bowman@montana.com> - 2018-12-16 12:51 -0700
Re: Counting lines of a file Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-12-16 20:51 +0000
Re: Counting lines of a file rbowman <bowman@montana.com> - 2018-12-16 14:40 -0700
Re: Counting lines of a file Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-12-16 21:50 +0000
Re: Counting lines of a file Keith Thompson <kst-u@mib.org> - 2018-12-16 15:38 -0800
Re: Counting lines of a file rbowman <bowman@montana.com> - 2018-12-16 20:29 -0700
Re: Counting lines of a file Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-12-18 21:03 +0000
Re: Counting lines of a file Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-12-16 21:17 +0000
Re: Counting lines of a file Joey Pabalinas <joeypabalinas@gmail.com> - 2018-12-16 17:13 -1000
Re: Counting lines of a file rbowman <bowman@montana.com> - 2018-12-16 23:11 -0700
Re: Counting lines of a file Joey Pabalinas <joeypabalinas@gmail.com> - 2018-12-16 22:05 -1000
Re: Counting lines of a file Keith Thompson <kst-u@mib.org> - 2018-12-17 11:52 -0800
Re: Counting lines of a file luser droog <luser.droog@gmail.com> - 2018-12-17 16:01 -0800
Re: Counting lines of a file Keith Thompson <kst-u@mib.org> - 2018-12-17 17:35 -0800
Re: Counting lines of a file fir <profesor.fir@gmail.com> - 2018-12-19 15:54 -0800
Re: Counting lines of a file rbowman <bowman@montana.com> - 2018-12-17 20:01 -0700
Re: Counting lines of a file Ike Naar <ike@iceland.freeshell.org> - 2018-12-18 07:44 +0000
Re: Counting lines of a file nobody@example.org (Scott) - 2018-12-18 09:29 +0000
Re: Counting lines of a file David Brown <david.brown@hesbynett.no> - 2018-12-18 13:18 +0100
Re: Counting lines of a file James Kuyper <jameskuyper@alumni.caltech.edu> - 2018-12-18 06:10 -0800
Re: Counting lines of a file rbowman <bowman@montana.com> - 2018-12-18 08:12 -0700
Re: Counting lines of a file "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-19 07:47 -0800
Re: Counting lines of a file Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-12-16 20:41 +0000
Re: Counting lines of a file scott@slp53.sl.home (Scott Lurndal) - 2018-12-17 15:18 +0000
Page 8 of 11 — ← Prev page 1 … 6 7 [8] 9 10 11 Next page →
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2018-10-03 22:50 +0100 |
| Message-ID | <4RatD.10642$PI.4585@fx25.am4> |
| In reply to | #136143 |
On 03/10/2018 22:33, Ben Bacarisse wrote: > "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes: > <snip> >> Except I would write the above code in a C++ compiler and use >> bool. :-) > > Or you could use a C compiler and use bool. You may be joking, but > someone learning C might get the idea that C does not have a Boolean > type. It has had one for very nearly two decades. > >> I would also use a length determination for the >> file size rather than testing for something like EOF. I did >> that here because of the OP's content. > > They come thick and fast! People learning C should know that it's > almost always better to simply read a stream until EOF is seen, just as > Jacob's code does. Unless you're stuck with a slow library, then fgetc is slow. My main 61MB input file took 3 seconds to process, even optimised, on any compiler using that library. On a version knocked up in my scripting language, it was 5 times faster. > Determining the file size is fiddly and in this > particular case, absolutely the wrong way to do it. (If there *are* any > readers learning C, ask and I'll gladly explain why.) I'm not learning C, but I'll ask anyway; why? (Note this program reads files in binary mode so the file sizes determined both ways should match.) Would it be the same answer if you only wanted a list of file sizes? (Because you don't really want to be reading every byte of every single file as you are not interested in the data.) -- bart
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2018-10-04 11:30 +1300 |
| Message-ID | <g1ku7vFev09U15@mid.individual.net> |
| In reply to | #136146 |
On 04/10/18 10:50, Bart wrote: > On 03/10/2018 22:33, Ben Bacarisse wrote: > >> Determining the file size is fiddly and in this >> particular case, absolutely the wrong way to do it. (If there *are* any >> readers learning C, ask and I'll gladly explain why.) > > I'm not learning C, but I'll ask anyway; why? (Note this program reads > files in binary mode so the file sizes determined both ways should match.) You need to open it, seek to the end and cross your fingers. > Would it be the same answer if you only wanted a list of file sizes? Yes and no, the mechanism is still tricky, but obtaining an accurate result isn't so important - you don't risk reading to much or too little if the file changes between determining the size and attempting to read it. -- Ian.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2018-10-03 15:41 -0700 |
| Message-ID | <lnpnwq4ps0.fsf@kst-u.example.com> |
| In reply to | #136146 |
Bart <bc@freeuk.com> writes:
> On 03/10/2018 22:33, Ben Bacarisse wrote:
>> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
>> <snip>
>>> Except I would write the above code in a C++ compiler and use
>>> bool. :-)
>>
>> Or you could use a C compiler and use bool. You may be joking, but
>> someone learning C might get the idea that C does not have a Boolean
>> type. It has had one for very nearly two decades.
>>
>>> I would also use a length determination for the
>>> file size rather than testing for something like EOF. I did
>>> that here because of the OP's content.
>>
>> They come thick and fast! People learning C should know that it's
>> almost always better to simply read a stream until EOF is seen, just as
>> Jacob's code does.
>
> Unless you're stuck with a slow library, then fgetc is slow. My main
> 61MB input file took 3 seconds to process, even optimised, on any
> compiler using that library. On a version knocked up in my scripting
> language, it was 5 times faster.
Whatever input function you use, it should have a way to tell you that
it's run out of input. For example, fgetc() returnes EOF, fgets()
returns a null pointer, and fread() returns 0. It's best to use that
result to determine when you've reached the end of your input (or an
error condition) rather than using the file size to predict how much
memory is available.
>> Determining the file size is fiddly and in this
>> particular case, absolutely the wrong way to do it. (If there *are* any
>> readers learning C, ask and I'll gladly explain why.)
>
> I'm not learning C, but I'll ask anyway; why? (Note this program reads
> files in binary mode so the file sizes determined both ways should match.)
Not everything that can be read has a size, and the size of a file isn't
necessarily constant. A file could grow while you're reading it. A
file name could refer to a real or virtual device that provides text
input but doesn't have a way of telling you in advance how much. If
your program's input is redirected, it can't determine the size.
> Would it be the same answer if you only wanted a list of file sizes?
> (Because you don't really want to be reading every byte of every single
> file as you are not interested in the data.)
$ echo hello world | wc
1 2 12
How is the wc command supposed to determine the size of its input
without reading it?
(It might be able to do so in some cases, if it knows via
system-specific means that its input is an actual file.)
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2018-10-04 00:46 +0100 |
| Message-ID | <NxctD.538355$%L2.26194@fx15.am4> |
| In reply to | #136150 |
On 03/10/2018 23:41, Keith Thompson wrote: > Bart <bc@freeuk.com> writes: > Not everything that can be read has a size, and the size of a file isn't > necessarily constant. A file could grow while you're reading it. And maybe after reading it. So that the results of the program could be out of date by the time you see them. Or the contents are modified as it's being read, so that the line count is wrong. Or if the file is growing faster than the program can read it, it may not finish for a while, perhaps not until storage is exhausted. Such programs will always display a snapshot of the file statistics at a certain point. For a continuously updated live display, you need a different kind of program. >> Would it be the same answer if you only wanted a list of file sizes? >> (Because you don't really want to be reading every byte of every single >> file as you are not interested in the data.) > > $ echo hello world | wc > 1 2 12 > > How is the wc command supposed to determine the size of its input > without reading it? This is one of the most exasperating things about clc. For decades I've been using facilities for reading file sizes and for reading files into memory all in one go. And it has worked perfectly. But all such techniques are banned from clc because of the preoccupation with reading stuff from stdin, which is a Linux habit. That just adds to a long list of stuff I'm not allowed to do (not here anyway), because of Linux working practices. BTW here's how you can do your example using my method: > echo hello world >temp && lc temp This version is jacob's byte-by-byte read, but it will also work predetermining the file size, before loading it in one block. So, are we trying to program C here, or Linux? -- bart
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2018-10-04 13:01 +1300 |
| Message-ID | <g1l3j7Fev09U16@mid.individual.net> |
| In reply to | #136153 |
On 04/10/18 12:46, Bart wrote: > On 03/10/2018 23:41, Keith Thompson wrote: >> Bart <bc@freeuk.com> writes: > >> Not everything that can be read has a size, and the size of a file isn't >> necessarily constant. A file could grow while you're reading it. > > And maybe after reading it. So that the results of the program could be > out of date by the time you see them. > > Or the contents are modified as it's being read, so that the line count > is wrong. > > Or if the file is growing faster than the program can read it, it may > not finish for a while, perhaps not until storage is exhausted. > > Such programs will always display a snapshot of the file statistics at a > certain point. For a continuously updated live display, you need a > different kind of program. Keith's point that "Not everything that can be read has a size" still holds. >>> Would it be the same answer if you only wanted a list of file sizes? >>> (Because you don't really want to be reading every byte of every single >>> file as you are not interested in the data.) >> >> $ echo hello world | wc >> 1 2 12 >> >> How is the wc command supposed to determine the size of its input >> without reading it? > > This is one of the most exasperating things about clc. > > For decades I've been using facilities for reading file sizes and for > reading files into memory all in one go. And it has worked perfectly. > > But all such techniques are banned from clc because of the preoccupation > with reading stuff from stdin, which is a Linux habit. Bollocks and false. I'm sure most programs written by people here that rely on fast data access use platform specific ways to read files. > That just adds to a long list of stuff I'm not allowed to do (not here > anyway), because of Linux working practices. Bollocks and false. Why are you so hung up on Linux? -- Ian.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2018-10-04 01:22 +0100 |
| Message-ID | <13dtD.348384$GU1.142816@fx34.am4> |
| In reply to | #136155 |
On 04/10/2018 01:01, Ian Collins wrote: > On 04/10/18 12:46, Bart wrote: >> That just adds to a long list of stuff I'm not allowed to do (not here >> anyway), because of Linux working practices. > > Bollocks and false. Why are you so hung up on Linux? /I'm/ the one hung on Linux? I work with files. Files that have a size. If they don't have a size then they are something else and are treated accordingly. But I can't do that here because Linux likes to deal with streams and pipes and anything else except actual files. Tell me, if someone is using an utility like to this to summarise the files in a directory, how many of those are likely to be real files with a known size? I'd say pretty much all of them. But you still have to read them a character at a time? -- bart
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2018-10-04 13:39 +1300 |
| Message-ID | <g1l5prFev09U17@mid.individual.net> |
| In reply to | #136157 |
On 04/10/18 13:22, Bart wrote: > On 04/10/2018 01:01, Ian Collins wrote: >> On 04/10/18 12:46, Bart wrote: > >>> That just adds to a long list of stuff I'm not allowed to do (not here >>> anyway), because of Linux working practices. >> >> Bollocks and false. Why are you so hung up on Linux? > > /I'm/ the one hung on Linux? Yes, you keep referring to things as "Linux this" or "Linux that" which are nothing of the sort. For staters Linux is a relatively new kid on the block who just follows the UNIX way of doing things. Also any platform with a terminal "reads stuff from stdin", even windows. > I work with files. Files that have a size. If they don't have a size > then they are something else and are treated accordingly. > > But I can't do that here because Linux likes to deal with streams and > pipes and anything else except actual files. No, it doesn't. It just follows the UNIX "everything is a file" tradition. Why should we have a different interface for everything we want to read from? > Tell me, if someone is using an utility like to this to summarise the > files in a directory, how many of those are likely to be real files with > a known size? No doubt all of them. > I'd say pretty much all of them. But you still have to read them a > character at a time? No, you don't. - Ian.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2018-10-03 18:23 -0700 |
| Message-ID | <lnlg7e4i9p.fsf@kst-u.example.com> |
| In reply to | #136153 |
Bart <bc@freeuk.com> writes:
> On 03/10/2018 23:41, Keith Thompson wrote:
[...]
>> $ echo hello world | wc
>> 1 2 12
>>
>> How is the wc command supposed to determine the size of its input
>> without reading it?
>
> This is one of the most exasperating things about clc.
>
> For decades I've been using facilities for reading file sizes and for
> reading files into memory all in one go. And it has worked perfectly.
>
> But all such techniques are banned from clc because of the preoccupation
> with reading stuff from stdin, which is a Linux habit.
>
> That just adds to a long list of stuff I'm not allowed to do (not here
> anyway), because of Linux working practices.
What on Earth are you talking about?
You say you like approach X. I point out the advantages of approach Y.
You claim that we're saying you're *not allowed* to use approach X.
Try being less dramatic.
> BTW here's how you can do your example using my method:
>
> > echo hello world >temp && lc temp
>
> This version is jacob's byte-by-byte read, but it will also work
> predetermining the file size, before loading it in one block.
>
>
> So, are we trying to program C here, or Linux?
The article that started this thread specifically mentioned Linux.
If you want a program that can only read from named seekable files,
knock yourself out. I know, from decades of personal experience
(my own and many others') that having programs able to read either
from named files or from standard input has tremendous advantages,
enabling the entire Unix tools ecosystem. Many such programs can
be written using only standard C.
Apparently that's not as popular an approach for Windows users.
If I have to copy my input to a named file before I can feed it to
a program, I'll probably use a different program (or, if I have to,
write a wrapper script that behaves the way I want).
(Unless it's something like a text editor, for which restricting it to
operating on named files makes sense.)
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2018-10-03 13:33 +0100 |
| Message-ID | <HG2tD.402570$Yw.347021@fx31.am4> |
| In reply to | #136093 |
On 03/10/2018 13:20, Rick C. Hodgin wrote:
> On Wednesday, October 3, 2018 at 4:57:46 AM UTC-4, Anton Shepelev wrote:
>> Rick C. Hodgin:
>>
>>> You might also want to check there for \r because not all
>>> line endings are the same on each data file you'll parse.
>>> If you do that, you'll need to move forward for the
>>> opposite condition (find \n, skip forward for every \r,
>>> find \r, skip forward until you pass \n).
>>
>> Sounds too complicated. Since only three line endings are
>> possible: \r, \n, and \r\n, the program can work thus:
>>
>> a. upon encountering an \r, skip a possible following \n
>> and singnal a new line,
>>
>> b. unpon encountering an \n, signal a new line.
>
> I use this algorithm:
>
> 1) Encounter \n, skip any contiguous \r
> 2) Encounter \r, skip any contiguous \n
>
> This accounts for:
>
> 1) \n
> 2) \r
> 3) \n\r
> 4) \r\n
>
> I have seen all four of those line endings over the course of
> the past 30+ years.
I've seen only cr/lf, and lf-only endings.
I did once see a file with cr-only endings (from a Mac I think), but
never again.
So any code that processes binary text (as opposed to non-binary text
when it is accessed via C file functions), will handle those two very
common file formats.
This is in contrast to programs like Notepad, where you give it a source
file from linux, and you just see a rectangular block of text with no
newlines at all.
It takes a simple algorithm to skip past
> them. Something like (initialized here for brevity, untested):
>
> int cr_found = 0;
> int lf_found = 0;
> int crlf_found = 0;
> int lfcr_found = 0;
>
> // Iterate through the file
> while ((c = get_next_char())
> {
> ++line;
> if (c == 13)
> {
> ++cr_found;
> while ((c = get_next_char()) == 10) { ++crlf_found }
>
> } else if (c == 10) {
> ++lf_found;
> while ((c = get_next_char()) == 13) { ++lfcr_found }
>
> } else {
> --line;
> }
> }
>
> // Report on line ending
> if ( (cr_found != crlf_found && crlf_found != 0)
> || (lf_found != lfcr_found && lfcr_found != 0)
> || cr_found != lf_found)
> {
> printf("Line endings inconsistent.\n");
> // ... possibly ask if they want that corrected
> }
>
That doesn't look very simple...
--
bart
[toc] | [prev] | [next] | [standalone]
| From | Anton Shepelev <anton.txt@g{oogle}mail.com> |
|---|---|
| Date | 2018-10-03 15:40 +0300 |
| Message-ID | <20181003154058.215c11223dcdebbd35f54b84@g{oogle}mail.com> |
| In reply to | #136097 |
Bart: >I've seen only cr/lf, and lf-only endings. > >I did once see a file with cr-only endings (from a Mac I >think), but never again. > >So any code that processes binary text (as opposed to non- >binary text when it is accessed via C file functions), will >handle those two very common file formats. Pray handle CR as well, its audience is more than neglibible. -- () ascii ribbon campaign - against html e-mail /\ http://preview.tinyurl.com/qcy6mjc [archived]
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2018-10-03 05:57 -0700 |
| Message-ID | <7130d18c-c234-45d6-9516-5af09b83a38e@googlegroups.com> |
| In reply to | #136097 |
On Wednesday, October 3, 2018 at 8:33:52 AM UTC-4, Bart wrote: > That doesn't look very simple... It's a fairly simple algorithm. I posted a couple follow-ups to demonstrate how it should've been written, and how I actually do my loads on Windows with CR/LF combinations. One of the easiest solutions I've found for dealing with line endings, is to replace all \r characters with \n, and then do a replace of all double \n\n sequences with only \n, and then just use \n as a parser, and when you write it out, write out whatever format the user wants. -- Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2018-10-03 22:19 +0100 |
| Message-ID | <87y3besp8b.fsf@bsb.me.uk> |
| In reply to | #136104 |
"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes: > On Wednesday, October 3, 2018 at 8:33:52 AM UTC-4, Bart wrote: >> That doesn't look very simple... > > It's a fairly simple algorithm. I posted a couple follow-ups > to demonstrate how it should've been written, and how I actually > do my loads on Windows with CR/LF combinations. > > One of the easiest solutions I've found for dealing with line > endings, is to replace all \r characters with \n, and then do > a replace of all double \n\n sequences with only \n, and then > just use \n as a parser, and when you write it out, write out > whatever format the user wants. I feel I should point out, for any readers learning C, that in the normal course of events you don't have to do any of this at all. If you open a file in text mode (as is stdin by default) and you will see a sole '\n' as the line ending. Similarly, for an output file opened in text mode (such as stdout) printing '\n' will generate the system's line ending. You only have to worry about mysterious line ending if you are writing a general utility that is expected to be able to handle "foreign" files -- file that might use a line ending that is not the native OS's line ending. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2018-10-03 11:25 +1300 |
| Message-ID | <g1i9jgFev09U4@mid.individual.net> |
| In reply to | #136032 |
On 03/10/18 09:37, jacobnavia wrote:
> Unix has the "wc" utility to count the lines of a file. It is a pity
> that under linux that program is unusable to count lines in a hierarchy
> of several directories. It requires ZERO terminated file names, and the
> "find" utility produces \n terminated file names, so it is unusable for
> that.
>
> So, I decided to rewrite "wc" as "lc" (for Line Count")
>
> It took me a few hours, and I wanted to post the result here, since it
> is (maybe) a useful program, and the way I wrote it explain some
> opinions I have about software design.
One obvious comment is many variables would be easier to trace if they
were declared when first used :)
> Here it is:
> -----------------------------------------------cut here
> #include <stdio.h>
> #include <stdlib.h>
> #include <stdint.h>
> #include <string.h>
> /* Go through all file names and find out the longest one.
> This allows to align results.
> */
> static int FindMaxFileNameLength(char *argv[])
> {
> int i,len;
> int Maxlen=-1;
> for (i=1; argv[i];i++) {
> len = strlen(argv[i]);
> if (len > Maxlen)
> Maxlen = len;
> }
> return Maxlen;
> }
>
> /* Copy the file name into the first n chars, starting at the leftmost */
> static void PadName(char *buf, char *name,int maxlen)
> {
> memset(buf,' ',maxlen);
> memcpy(buf,name,strlen(name));
> buf[maxlen]=0;
> }
>
> #define CHUNKSIZE 4096
This could be a const rather than a macro.
> static char ** ReadFromStdin(int *pargc)
> {
> // Assumption: No file name exceeds 4K +
> // space for the terminating zero
> char inbuf[4096+1];
> // An array holding the file names that will grow by chunks
> char **fileNameArray = calloc(CHUNKSIZE,sizeof(char *));
> int fileCount = 0; // Counts how many files allocated in this chunk
Call it something like filesInThisChunk and you won't need a comment.
> int totalFileCount=1; //Index into the array. Note: starts at 1!
> char *p; // Used to eliminate the '\n'
Declare in loop and you won't need a comment.
> while (fgets(inbuf,sizeof(inbuf),stdin)) {
> fileNameArray[totalFileCount] = malloc(strlen(inbuf)+1);
> if (fileNameArray[totalFileCount] == NULL)
> return NULL;
> // Eliminate the '\n'.
> // If we do not do this, fopen will fail
> p = strchr(inbuf,'\n');
> if (p) *p=0;
> strcpy(fileNameArray[totalFileCount],inbuf);
> fileCount++;
> totalFileCount++;
> if (fileCount >= CHUNKSIZE) {
> char **tmp = realloc(fileNameArray,
> (totalFileCount+CHUNKSIZE) * sizeof(char *));
> // If reallocation failed return NULL leaking
> // all the memory allocated
> // so far, assuming main will exit and OS will
> // reclaim memory
> if (tmp == NULL)
> return NULL;
> fileNameArray = tmp;
> fileCount = 0;
> }
> }
> *pargc = totalFileCount;
> return fileNameArray;
> }
>
> int main(int argc,char *argv[])
> {
> int fileCount=0;
> int c;
> int titleHasBeenWritten = 0;
> int maxlen;
> int32_t lines=0;
> int64_t bytes=0;
> int64_t totalLines=0;
> int64_t totalBytes=0;
> char *PaddedFileName;
>
> // If called with no arguments print a usage message and exit */
> if (argc < 2) {
> fprintf(stderr,"Usage: lc <files>\n or\nlc -\n");
> return EXIT_FAILURE;
> }
>
Get your preconditions out of the way before declaring variables.
--
Ian.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2018-10-02 18:56 -0400 |
| Message-ID | <pp0t3e$qhc$1@dont-email.me> |
| In reply to | #136061 |
On 10/02/2018 06:25 PM, Ian Collins wrote: > One obvious comment is many variables would be easier to trace if they > were declared when first used :) I disagree completely with that statement. I believe all variables should be declared at the top of a function, and then you initialize them where they're needed, adding also a comment explaining what that variable's used for, though I would argue the name should also give it away, including the use of simple names like p for a ptr, which indicates by its short name that it's a "throwaway" value used only in the immediate code, and does not carry values beyond. > On 03/10/18 09:37, jacobnavia wrote: >> #define CHUNKSIZE 4096 > This could be a const rather than a macro. If you declare it as a const it is also typically visible in the debugger, whereas #define values are not visible. >> char *p; // Used to eliminate the '\n' > Declare in loop and you won't need a comment. I would argue, simply declare here, and then use it in context below so your code indicates why p is needed. > Get your preconditions out of the way before declaring variables. Disagree. Get your preconditions out of the way before /initializing/ variables. I do not believe initializing variables in your declaration area is a good idea. The two should be separate. -- Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Anton Shepelev <anton.txt@g{oogle}mail.com> |
|---|---|
| Date | 2018-10-03 12:11 +0300 |
| Message-ID | <20181003121123.b24fac01556a637b4bf82af0@g{oogle}mail.com> |
| In reply to | #136062 |
Rick C. Hodgin to Ian Collins: >>One obvious comment is many variables would be easier to >>trace if they were declared when first used :) > >I disagree completely with that statement. I believe all >variables should be declared at the top of a function, and >then you initialize them where they're needed I here agree with Rick. I hate it when variable declarations interfere in the actual code. In my opinion, a function comprises two clearly separate parts: the declarative and the imperative. I therefore never mix declaration and initialisation thus: int i = 0; except for constants: const int ATTEMPTS = 5; Once a functions grows too annoyoing to navigate back and forth between the declarative and imperative parts, I refactor it into smaller functions. And it is a good style that hints at refactoring and makes writing spaghetti code harder! >I do not believe initializing variables in your declaration >area is a good idea. The two should be separate. I thought I were the only one holding this principle. Do you know other programmers that defended it, preferably in print? -- () ascii ribbon campaign - against html e-mail /\ http://preview.tinyurl.com/qcy6mjc [archived]
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2018-10-03 23:06 +1300 |
| Message-ID | <g1jik9Fev09U5@mid.individual.net> |
| In reply to | #136077 |
On 03/10/18 22:11, Anton Shepelev wrote: > Rick C. Hodgin to Ian Collins: > >>> One obvious comment is many variables would be easier to >>> trace if they were declared when first used :) >> >> I disagree completely with that statement. I believe all >> variables should be declared at the top of a function, and >> then you initialize them where they're needed > > I here agree with Rick. I hate it when variable > declarations interfere in the actual code. In my opinion, a > function comprises two clearly separate parts: the > declarative and the imperative. I therefore never mix > declaration and initialisation thus: There is no point in either if the preconditions aren't met. -- Ian.
[toc] | [prev] | [next] | [standalone]
| From | Anton Shepelev <ant0n.txt@gmai1.c0m> |
|---|---|
| Date | 2018-10-03 14:58 +0300 |
| Message-ID | <20181003145852.4d45a3d73033cdfbaa2c1f8e@gmai1.c0m> |
| In reply to | #136082 |
Ian Collins to Anton Shepelev: >>I here agree with Rick. I hate it when variable >>declarations interfere in the actual code. In my opinion, >>a function comprises two clearly separate parts: the >>declarative and the imperative. I therefore never mix >>declaration and initialisation thus: > >There is no point in either if the preconditions aren't >met. Indeed, but programs should be written for people, leaving it for the compiler to translate them into a form most suitable for the computer. If stack allocations are time- critical -- which I trow is very rare -- then the compiler should relocate each to the first use of the corresponding variable. -- () ascii ribbon campaign - against html e-mail /\ http://preview.tinyurl.com/qcy6mjc [archived]
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2018-10-04 08:08 +1300 |
| Message-ID | <g1kie5Fev09U7@mid.individual.net> |
| In reply to | #136089 |
On 04/10/18 00:58, Anton Shepelev wrote: > Ian Collins to Anton Shepelev: > >>> I here agree with Rick. I hate it when variable >>> declarations interfere in the actual code. In my opinion, >>> a function comprises two clearly separate parts: the >>> declarative and the imperative. I therefore never mix >>> declaration and initialisation thus: >> >> There is no point in either if the preconditions aren't >> met. > > Indeed, but programs should be written for people, leaving > it for the compiler to translate them into a form most > suitable for the computer. If stack allocations are time- > critical -- which I trow is very rare -- then the compiler > should relocate each to the first use of the corresponding > variable. I was talking about people - a function's preconditions should be the first thing the reader sees. -- Ian.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2018-10-03 05:06 -0700 |
| Message-ID | <1d918d59-d3bb-4e28-b3cc-79558ee478de@googlegroups.com> |
| In reply to | #136077 |
On Wednesday, October 3, 2018 at 5:11:31 AM UTC-4, Anton Shepelev wrote: > Rick C. Hodgin to Ian Collins: > >I do not believe initializing variables in your declaration > >area is a good idea. The two should be separate. > > I thought I were the only one holding this principle. Do > you know other programmers that defended it, preferably in > print? Nope. I have had a few developers I've worked with who have felt the same way, but nothing I've seen published online. -- Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Anton Shepelev <anton.txt@g{oogle}mail.com> |
|---|---|
| Date | 2018-10-03 15:13 +0300 |
| Message-ID | <20181003151343.51809d91d46e0e625c27f5d7@g{oogle}mail.com> |
| In reply to | #136090 |
Rick C. Hodgin to Anton Shepelev: >>Rick C. Hodgin: >> >>>I do not believe initializing variables in your >>>declaration area is a good idea. The two should be >>>separate. >> >>I thought I were the only one holding this principle. Do >>you know other programmers that defended it, preferably in >>print? > >Nope. I have had a few developers I've worked with who >have felt the same way, but nothing I've seen published >online. Was a common style enforced on you all, or did each follow his own convicion with regard to declaration and initialisation? -- () ascii ribbon campaign - against html e-mail /\ http://preview.tinyurl.com/qcy6mjc [archived]
[toc] | [prev] | [next] | [standalone]
Page 8 of 11 — ← Prev page 1 … 6 7 [8] 9 10 11 Next page →
Back to top | Article view | comp.lang.c
csiph-web