Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #100280 > unrolled thread
| Started by | Alla _ <modelling.data@gmail.com> |
|---|---|
| First post | 2016-12-26 00:31 -0800 |
| Last post | 2016-12-26 14:38 -0800 |
| Articles | 20 on this page of 252 — 20 participants |
Back to article view | Back to comp.lang.c
Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-26 00:31 -0800
Re: Reading lines from a file, eliminating CR and LF Barry Schwarz <schwarzb@dqel.com> - 2016-12-26 01:19 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-26 02:25 -0800
Re: Reading lines from a file, eliminating CR and LF Barry Schwarz <schwarzb@dqel.com> - 2016-12-26 14:04 -0800
Re: Reading lines from a file, eliminating CR and LF BartC <bc@freeuk.com> - 2016-12-26 12:04 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-26 05:49 -0800
Re: Reading lines from a file, eliminating CR and LF BartC <bc@freeuk.com> - 2016-12-26 15:20 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-26 07:31 -0800
Re: Reading lines from a file, eliminating CR and LF Manfred <mx2927@gmail.com> - 2016-12-26 16:44 +0100
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-26 08:00 -0800
Re: Reading lines from a file, eliminating CR and LF BartC <bc@freeuk.com> - 2016-12-26 17:43 +0000
Re: Reading lines from a file, eliminating CR and LF Keith Thompson <kst-u@mib.org> - 2016-12-26 12:03 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-27 23:56 -0800
Re: Reading lines from a file, eliminating CR and LF Richard Heathfield <rjh@cpax.org.uk> - 2016-12-28 09:33 +0000
Re: Reading lines from a file, eliminating CR and LF Manfred <mx2927@gmail.com> - 2016-12-26 17:06 +0100
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-26 09:48 -0800
Re: Reading lines from a file, eliminating CR and LF Manfred <noname@invalid.add> - 2016-12-26 19:03 +0100
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-26 10:39 -0800
Re: Reading lines from a file, eliminating CR and LF BartC <bc@freeuk.com> - 2016-12-26 19:49 +0000
Re: Reading lines from a file, eliminating CR and LF Manfred <noname@invalid.add> - 2016-12-26 20:56 +0100
Re: Reading lines from a file, eliminating CR and LF Keith Thompson <kst-u@mib.org> - 2016-12-26 13:50 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-28 00:27 -0800
Re: Reading lines from a file, eliminating CR and LF Richard Heathfield <rjh@cpax.org.uk> - 2016-12-28 09:35 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-28 10:33 -0800
Re: Reading lines from a file, eliminating CR and LF Richard Heathfield <rjh@cpax.org.uk> - 2016-12-28 20:48 +0000
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-29 15:31 +0000
Re: Reading lines from a file, eliminating CR and LF Richard Heathfield <rjh@cpax.org.uk> - 2016-12-29 18:56 +0000
Re: Reading lines from a file, eliminating CR and LF Barry Schwarz <schwarzb@dqel.com> - 2016-12-29 01:03 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-29 01:33 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-29 00:16 -0800
Re: Reading lines from a file, eliminating CR and LF Richard Heathfield <rjh@cpax.org.uk> - 2016-12-29 14:05 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-29 23:49 -0800
Re: Reading lines from a file, eliminating CR and LF Manfred <noname@invalid.add> - 2016-12-28 15:34 +0100
Re: Reading lines from a file, eliminating CR and LF Keith Thompson <kst-u@mib.org> - 2016-12-28 08:49 -0800
Re: Reading lines from a file, eliminating CR and LF "James R. Kuyper" <jameskuyper@verizon.net> - 2017-01-04 12:55 -0500
Re: Reading lines from a file, eliminating CR and LF Tim Rentsch <txr@alumni.caltech.edu> - 2016-12-29 00:19 -0800
Re: Reading lines from a file, eliminating CR and LF Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-29 13:01 -0800
Re: Reading lines from a file, eliminating CR and LF Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-29 07:35 -0800
Re: Reading lines from a file, eliminating CR and LF supercat@casperkitty.com - 2016-12-29 08:58 -0800
Re: Reading lines from a file, eliminating CR and LF raltbos@xs4all.nl (Richard Bos) - 2017-01-01 15:21 +0000
Re: Reading lines from a file, eliminating CR and LF Keith Thompson <kst-u@mib.org> - 2016-12-29 09:19 -0800
Re: Reading lines from a file, eliminating CR and LF Jean-Marc Bourguet <jm@bourguet.org> - 2016-12-30 08:39 +0100
Re: Reading lines from a file, eliminating CR and LF Keith Thompson <kst-u@mib.org> - 2016-12-30 09:02 -0800
Re: Reading lines from a file, eliminating CR and LF Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-02 02:22 -0800
Re: Reading lines from a file, eliminating CR and LF "Peter \"Shaggy\" Haywood" <phaywood@alphalink.com.au> - 2016-12-31 00:22 +1100
Re: Reading lines from a file, eliminating CR and LF Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-02 03:29 -0800
Re: Reading lines from a file, eliminating CR and LF supercat@casperkitty.com - 2017-01-02 10:09 -0800
Re: Reading lines from a file, eliminating CR and LF Keith Thompson <kst-u@mib.org> - 2017-01-02 14:01 -0800
Re: Reading lines from a file, eliminating CR and LF supercat@casperkitty.com - 2017-01-02 16:35 -0800
Re: Reading lines from a file, eliminating CR and LF Keith Thompson <kst-u@mib.org> - 2017-01-02 16:49 -0800
Re: Reading lines from a file, eliminating CR and LF supercat@casperkitty.com - 2017-01-03 05:32 -0800
Re: Reading lines from a file, eliminating CR and LF Keith Thompson <kst-u@mib.org> - 2017-01-03 08:47 -0800
Re: Reading lines from a file, eliminating CR and LF luser droog <luser.droog@gmail.com> - 2017-01-02 15:39 -0800
Re: Reading lines from a file, eliminating CR and LF supercat@casperkitty.com - 2017-01-02 17:35 -0800
Re: Reading lines from a file, eliminating CR and LF luser droog <luser.droog@gmail.com> - 2017-01-02 20:00 -0800
Re: Reading lines from a file, eliminating CR and LF Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-13 08:24 -0800
Re: Reading lines from a file, eliminating CR and LF Keith Thompson <kst-u@mib.org> - 2017-01-02 13:15 -0800
Re: Reading lines from a file, eliminating CR and LF supercat@casperkitty.com - 2017-01-02 17:00 -0800
Re: Reading lines from a file, eliminating CR and LF Keith Thompson <kst-u@mib.org> - 2017-01-02 19:48 -0800
Re: Reading lines from a file, eliminating CR and LF Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-13 09:32 -0800
Re: Reading lines from a file, eliminating CR and LF Keith Thompson <kst-u@mib.org> - 2017-01-13 12:52 -0800
Re: Reading lines from a file, eliminating CR and LF Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-15 15:46 -0800
Re: Reading lines from a file, eliminating CR and LF Keith Thompson <kst-u@mib.org> - 2017-01-15 16:54 -0800
Re: Reading lines from a file, eliminating CR and LF Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-30 11:25 -0800
Re: Reading lines from a file, eliminating CR and LF supercat@casperkitty.com - 2017-01-30 14:06 -0800
Re: Reading lines from a file, eliminating CR and LF supercat@casperkitty.com - 2016-12-29 06:07 -0800
Re: Reading lines from a file, eliminating CR and LF Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-13 15:11 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-27 09:37 -0800
Re: Reading lines from a file, eliminating CR and LF Manfred <noname@invalid.add> - 2016-12-27 19:29 +0100
Re: Reading lines from a file, eliminating CR and LF luser droog <luser.droog@gmail.com> - 2016-12-27 11:41 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-28 10:30 -0800
Re: Reading lines from a file, eliminating CR and LF luser droog <luser.droog@gmail.com> - 2016-12-28 16:08 -0800
Re: Reading lines from a file, eliminating CR and LF fir <profesor.fir@gmail.com> - 2016-12-27 12:50 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-27 09:59 -0800
Re: Reading lines from a file, eliminating CR and LF Barry Schwarz <schwarzb@dqel.com> - 2016-12-27 10:56 -0800
Re: Reading lines from a file, eliminating CR and LF Keith Thompson <kst-u@mib.org> - 2016-12-27 12:24 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-28 08:35 -0800
Re: Reading lines from a file, eliminating CR and LF Keith Thompson <kst-u@mib.org> - 2016-12-28 09:16 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-28 10:08 -0800
Re: Reading lines from a file, eliminating CR and LF Manfred <noname@invalid.add> - 2016-12-27 22:34 +0100
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-28 08:39 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-28 02:20 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-28 10:11 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-29 00:20 -0800
Re: Reading lines from a file, eliminating CR and LF Manfred <noname@invalid.add> - 2016-12-29 14:56 +0100
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-29 22:35 -0800
Re: Reading lines from a file, eliminating CR and LF Manfred <noname@invalid.add> - 2016-12-30 22:45 +0100
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-31 00:01 +0000
Re: Reading lines from a file, eliminating CR and LF Manfred <noname@invalid.add> - 2016-12-31 03:19 +0100
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-31 00:20 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-31 00:23 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-31 00:29 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-31 11:10 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-31 10:53 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-31 20:24 +0000
Re: Reading lines from a file, eliminating CR and LF Barry Schwarz <schwarzb@dqel.com> - 2016-12-29 00:53 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-29 01:28 -0800
Re: Reading lines from a file, eliminating CR and LF Manfred <noname@invalid.add> - 2016-12-29 14:48 +0100
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-29 22:19 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-29 01:55 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-29 10:14 -0800
Re: Reading lines from a file, eliminating CR and LF Keith Thompson <kst-u@mib.org> - 2016-12-29 11:44 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-30 02:02 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-30 03:13 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-30 14:49 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-30 03:28 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-30 03:45 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-30 13:53 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-30 08:23 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-30 03:50 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-30 13:35 +0000
Re: Reading lines from a file, eliminating CR and LF Richard Heathfield <rjh@cpax.org.uk> - 2016-12-30 15:22 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-30 08:29 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-30 16:51 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-31 10:50 -0800
Re: Reading lines from a file, eliminating CR and LF BartC <bc@freeuk.com> - 2016-12-31 19:02 +0000
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-31 20:10 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-01 04:08 -0800
Re: Reading lines from a file, eliminating CR and LF Richard Heathfield <rjh@cpax.org.uk> - 2017-01-01 12:38 +0000
Re: Reading lines from a file, eliminating CR and LF BartC <bc@freeuk.com> - 2017-01-01 13:45 +0000
Re: Reading lines from a file, eliminating CR and LF BartC <bc@freeuk.com> - 2017-01-01 13:54 +0000
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-01 15:26 +0000
Re: Reading lines from a file, eliminating CR and LF Richard Heathfield <rjh@cpax.org.uk> - 2017-01-01 16:46 +0000
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-01 17:08 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-01 08:13 -0800
Re: Reading lines from a file, eliminating CR and LF Richard Heathfield <rjh@cpax.org.uk> - 2017-01-01 16:47 +0000
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-01 16:53 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-01 09:18 -0800
Re: Reading lines from a file, eliminating CR and LF Manfred <noname@invalid.add> - 2017-01-01 19:20 +0100
Re: Reading lines from a file, eliminating CR and LF Barry Schwarz <schwarzb@dqel.com> - 2017-01-01 15:18 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-02 03:41 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-01 15:07 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-01 09:05 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-01 19:16 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-02 03:39 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-02 04:02 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-02 13:48 +0000
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-02 13:47 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-02 07:21 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-02 18:38 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-02 10:57 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-02 21:48 +0000
POSIX, was: Re: Reading lines from a file, eliminating CR and LF luser droog <luser.droog@gmail.com> - 2017-01-02 15:58 -0800
Re: Reading lines from a file, eliminating CR and LF Barry Schwarz <schwarzb@dqel.com> - 2016-12-31 21:03 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-02 11:30 -0800
Re: Reading lines from a file, eliminating CR and LF Richard Heathfield <rjh@cpax.org.uk> - 2017-01-02 19:45 +0000
Re: Reading lines from a file, eliminating CR and LF Ike Naar <ike@iceland.freeshell.org> - 2017-01-02 19:56 +0000
Re: Reading lines from a file, eliminating CR and LF Richard Heathfield <rjh@cpax.org.uk> - 2017-01-02 21:09 +0000
Re: Reading lines from a file, eliminating CR and LF Ian Collins <ian-news@hotmail.com> - 2017-01-03 11:01 +1300
Re: Reading lines from a file, eliminating CR and LF Richard Heathfield <rjh@cpax.org.uk> - 2017-01-03 12:45 +0000
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-03 14:09 +0000
Re: Reading lines from a file, eliminating CR and LF Richard Heathfield <rjh@cpax.org.uk> - 2017-01-03 15:07 +0000
Re: Reading lines from a file, eliminating CR and LF Ian Collins <ian-news@hotmail.com> - 2017-01-04 09:13 +1300
Re: Reading lines from a file, eliminating CR and LF Ian Collins <ian-news@hotmail.com> - 2017-01-03 11:53 +1300
Re: Reading lines from a file, eliminating CR and LF Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-01-02 15:40 -0800
Re: Reading lines from a file, eliminating CR and LF Ian Collins <ian-news@hotmail.com> - 2017-01-03 13:16 +1300
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-03 00:01 +0000
Re: Reading lines from a file, eliminating CR and LF Ian Collins <ian-news@hotmail.com> - 2017-01-03 13:21 +1300
Re: Reading lines from a file, eliminating CR and LF Ike Naar <ike@iceland.freeshell.org> - 2017-01-03 08:40 +0000
Re: Reading lines from a file, eliminating CR and LF Richard Heathfield <rjh@cpax.org.uk> - 2017-01-03 12:50 +0000
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-03 14:42 +0000
Re: Reading lines from a file, eliminating CR and LF Richard Heathfield <rjh@cpax.org.uk> - 2017-01-03 15:11 +0000
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-03 16:32 +0000
Re: Reading lines from a file, eliminating CR and LF Richard Heathfield <rjh@cpax.org.uk> - 2017-01-03 17:24 +0000
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-03 17:48 +0000
Re: Reading lines from a file, eliminating CR and LF Richard Heathfield <rjh@cpax.org.uk> - 2017-01-03 18:56 +0000
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-03 19:46 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-03 13:37 -0800
Re: Reading lines from a file, eliminating CR and LF Barry Schwarz <schwarzb@dqel.com> - 2017-01-02 13:56 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-03 03:52 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-03 14:20 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-03 13:19 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-04 03:30 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-04 02:23 -0800
Re: Reading lines from a file, eliminating CR and LF mark.bluemel@gmail.com - 2017-01-04 02:56 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-04 07:06 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-04 15:21 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-05 03:01 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-05 11:51 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-05 04:04 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-05 14:23 +0000
Re: Reading lines from a file, eliminating CR and LF Barry Schwarz <schwarzb@dqel.com> - 2017-01-04 12:26 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-05 13:38 -0800
Re: Reading lines from a file, eliminating CR and LF Barry Schwarz <schwarzb@dqel.com> - 2017-01-05 16:25 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-04 12:21 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-05 02:52 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-05 14:13 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-05 07:54 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-05 07:59 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-05 08:12 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-05 17:15 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-05 09:19 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-05 08:28 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-05 17:20 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-05 10:45 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-05 09:02 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-05 19:49 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-05 13:28 -0800
Re: Reading lines from a file, eliminating CR and LF Barry Schwarz <schwarzb@dqel.com> - 2017-01-05 16:14 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-06 00:50 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-06 06:11 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-06 16:33 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-06 12:14 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-07 02:15 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-07 21:51 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-07 03:32 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-07 21:57 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-08 01:51 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-08 02:09 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-07 04:09 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-07 22:05 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-08 03:43 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-08 21:36 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-09 04:33 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-09 21:44 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-09 23:54 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-10 02:04 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-10 11:28 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-10 04:25 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-10 14:14 +0000
Re: Reading lines from a file, eliminating CR and LF Richard Heathfield <rjh@cpax.org.uk> - 2017-01-10 14:52 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-10 07:02 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-12 00:11 -0800
Re: Reading lines from a file, eliminating CR and LF mark.bluemel@gmail.com - 2017-01-12 01:13 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-12 01:41 -0800
Re: Reading lines from a file, eliminating CR and LF Richard Heathfield <rjh@cpax.org.uk> - 2017-01-12 09:55 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-12 10:25 -0800
Re: Reading lines from a file, eliminating CR and LF Barry Schwarz <schwarzb@dqel.com> - 2017-01-08 19:02 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-09 05:27 -0800
Re: Reading lines from a file, eliminating CR and LF Manfred <noname@invalid.add> - 2017-01-07 17:06 +0100
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-07 08:11 -0800
Re: Reading lines from a file, eliminating CR and LF Barry Schwarz <schwarzb@dqel.com> - 2017-01-05 16:04 -0800
Re: Reading lines from a file, eliminating CR and LF Barry Schwarz <schwarzb@dqel.com> - 2017-01-04 12:36 -0800
Re: Reading lines from a file, eliminating CR and LF Keith Thompson <kst-u@mib.org> - 2017-01-04 12:49 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-04 05:19 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-04 15:14 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-05 02:57 -0800
Re: Reading lines from a file, eliminating CR and LF Keith Thompson <kst-u@mib.org> - 2017-01-05 08:24 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-05 02:58 -0800
Re: Reading lines from a file, eliminating CR and LF Barry Schwarz <schwarzb@dqel.com> - 2017-01-04 13:02 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-03 03:37 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-03 02:46 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-03 11:25 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-03 02:43 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-02 22:45 +0000
Re: Reading lines from a file, eliminating CR and LF Barry Schwarz <schwarzb@dqel.com> - 2016-12-29 10:17 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-30 00:42 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-30 00:51 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-29 11:25 +0000
Re: Reading lines from a file, eliminating CR and LF Manfred <noname@invalid.add> - 2016-12-28 20:57 +0100
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-28 23:16 -0800
Re: Reading lines from a file, eliminating CR and LF Barry Schwarz <schwarzb@dqel.com> - 2016-12-26 14:38 -0800
Page 7 of 13 — ← Prev page 1 … 5 6 [7] 8 9 … 13 Next page →
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-01-01 13:54 +0000 |
| Message-ID | <o4b1ki$hh1$1@dont-email.me> |
| In reply to | #100772 |
On 01/01/2017 13:45, BartC wrote:
> On 01/01/2017 12:38, Richard Heathfield wrote:
>> Your solution had hundreds of lines. The above has 21 lines, and a tiny
>> handful of statements. |This is the kind of simplicity for which you
>> should be striving.
>
> Does your code work? I'm getting results of 0.0.
>
> The &endptr is supposed to be char** in the specs.
>
> The value of n doesn't appear to change from 0.
>
> I tweaked it a bit to fix that, and only summed the values, then worked
> out the average at the end.
Here's the code I used instead. (I don't know what that spec is; this
assumes there are 0 or 1 numbers to be read at the start of each line,
and the average of those within the file is the determined. There is no
error checking, eg. a number that has 97 leading spaces that is then
split across two fgets reads.)
int main(void)
{
double d = 0.0;
char* endptr;
double average = 0.0;
double sum = 0.0;
int n = 0;
char line[100] = "";
while(fgets(line, sizeof line, stdin) != NULL)
{
d= strtod(line, &endptr);
if (endptr>line) {
sum += d;
++n;
}
}
if (n)
printf("Average is %f\n", sum/n);
else
puts("No numbers in the file");
return 0;
}
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-01-01 15:26 +0000 |
| Message-ID | <87y3yupzs2.fsf@bsb.me.uk> |
| In reply to | #100770 |
Richard Heathfield <rjh@cpax.org.uk> writes:
> On 01/01/17 12:08, Alla _ wrote:
<snip>
>> I need the average function in my program anyway,
>
> Not in Ben's challenge, you don't.
If you will permit me... (I know these are simply the result of dashing
off a simple program without testing, but the errors should be corrected
nonetheless).
> #include <stdio.h>
> #include <stdlib.h>
>
> int main(void)
> {
> double d = 0.0;
> double endptr = 0.0;
char *endptr;
> double average = 0.0;
> unsigned long int n = 0;
> char line[100] = "";
> while(fgets(line, sizeof line, stdin) != NULL)
> {
> d = strtod(line, &endptr);
> if(endptr > d)
endptr > line
> {
> average = (d + n * average) / (n + 1);
insert n += 1; here
> }
> }
> printf("%f\n", average);
> return 0;
> }
I'm curious about why you don't declare d in the loop. The "put them at
the top of the function" set is obviously larger than I thought.
And a note to Alla: I would not expect you to think of keeping a running
average like this. A running total is just as good for this purpose.
After all, that's not the focus of the exercise.
<snip>
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2017-01-01 16:46 +0000 |
| Message-ID | <o4bbmt$o3l$1@dont-email.me> |
| In reply to | #100780 |
On 01/01/17 15:26, Ben Bacarisse wrote: > Richard Heathfield <rjh@cpax.org.uk> writes: > >> On 01/01/17 12:08, Alla _ wrote: > <snip> > >>> I need the average function in my program anyway, >> >> Not in Ben's challenge, you don't. > > If you will permit me... (I know these are simply the result of dashing > off a simple program without testing, but the errors should be corrected > nonetheless). Please do, they are, they should be, and yes I am (annoyed with myself for making those errors). > I'm curious about why you don't declare d in the loop. The "put them at > the top of the function" set is obviously larger than I thought. I didn't put that much thought into it. I knew I had to put the average definition outside the loop, so I simply defined everything else while I was there. Well, nearly everything else. :-( -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-01-01 17:08 +0000 |
| Message-ID | <87eg0mpv2d.fsf@bsb.me.uk> |
| In reply to | #100786 |
Richard Heathfield <rjh@cpax.org.uk> writes: > On 01/01/17 15:26, Ben Bacarisse wrote: <snip> >> I'm curious about why you don't declare d in the loop. The "put them at >> the top of the function" set is obviously larger than I thought. > > I didn't put that much thought into it. I knew I had to put the > average definition outside the loop, so I simply defined everything > else while I was there. Ah, of course. One consequence of writing examples for a class is that you get obsessed about details because there are dozens of pairs of eye all wanting to catch you being wrong or inconstant. Much like Usenet though I used to care more about it in class due to the disruption caused by endless corrections. (Other helpful tips for new teachers: when writing code "live" never name a function "func" nor a variable "count". Just too risky!) -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2017-01-01 08:13 -0800 |
| Message-ID | <ded9dfe2-abb2-4dde-bfaa-67ec38847f57@googlegroups.com> |
| In reply to | #100770 |
On Sunday, January 1, 2017 at 3:39:07 PM UTC+3, Richard Heathfield wrote:
> On 01/01/17 12:08, Alla _ wrote:
> > On Saturday, December 31, 2016 at 11:10:43 PM UTC+3, Ben Bacarisse wrote:
> >> Alla _ <modelling.data@gmail.com> writes:
> >>
> >>> On Friday, December 30, 2016 at 4:35:33 PM UTC+3, Ben Bacarisse wrote:
> >>>> Alla _ <modelling.data@gmail.com> writes:
> >>>>
> >>> <snip>
> >>>> I would set a student these exercises:
> >>>>
> >>>> 1. Write a program that reads lines into a fix-size buffer (100
> >>>> characters will do) and prints the average of any numbers found at the
> >>>> start of a line (except for white-space). It should ignore lines that
> >>>> don't start with a number. So, given
> >>>>
> >>>> 1
> >>>> -2.0
> >>>> xyz
> >>>> 7bz
> >>>>
> >>>> it should print 2.0 ((1 - 2 + 7)/3).
> >>> <snip>
> > <snip>
> >>> Issues not solved yet:
> >>> 1) I have not yet found the way to print ((1 - 2 + 7)/3)
> >>
> >> Sorry, that was by way of explanation. It should just print 2.0.
> >
> > Still it would be interesting to found out how to print out this type
> > of output given the unknown number of digits and the possible
> > variability of their signs. Is it possible?
>
> Yes, of course it's possible, but it's completely outside the remit of
> the spec. It's because you keep flying off at tangents that you never
> learn anything.
>
> > I need the average function in my program anyway,
>
> Not in Ben's challenge, you don't.
>
> #include <stdio.h>
> #include <stdlib.h>
>
> int main(void)
> {
> double d = 0.0;
> double endptr = 0.0;
> double average = 0.0;
> unsigned long int n = 0;
> char line[100] = "";
> while(fgets(line, sizeof line, stdin) != NULL)
> {
> d = strtod(line, &endptr);
> if(endptr > d)
> {
> average = (d + n * average) / (n + 1);
> }
> }
> printf("%f\n", average);
> return 0;
> }
Oh...
On the other hand you have missed one aspect: the line that
starts with while spaces followed by the number should be accepted;
will strtod traverse beginning white spaces before it hits a number?
And your code doesn't process the file, but gets the data from the
stdin.
>
> Your solution had hundreds of lines. The above has 21 lines, and a tiny
> handful of statements. |This is the kind of simplicity for which you
> should be striving.
I know. I try. Upset. Overcomplicate things as usual.
Also I thought that I always have to split everything into
functions.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2017-01-01 16:47 +0000 |
| Message-ID | <o4bbop$o3l$2@dont-email.me> |
| In reply to | #100784 |
On 01/01/17 16:13, Alla _ wrote:
> On Sunday, January 1, 2017 at 3:39:07 PM UTC+3, Richard Heathfield wrote:
>> On 01/01/17 12:08, Alla _ wrote:
>>> On Saturday, December 31, 2016 at 11:10:43 PM UTC+3, Ben Bacarisse wrote:
>>>> Alla _ <modelling.data@gmail.com> writes:
>>>>
>>>>> On Friday, December 30, 2016 at 4:35:33 PM UTC+3, Ben Bacarisse wrote:
>>>>>> Alla _ <modelling.data@gmail.com> writes:
>>>>>>
>>>>> <snip>
>>>>>> I would set a student these exercises:
>>>>>>
>>>>>> 1. Write a program that reads lines into a fix-size buffer (100
>>>>>> characters will do) and prints the average of any numbers found at the
>>>>>> start of a line (except for white-space). It should ignore lines that
>>>>>> don't start with a number. So, given
>>>>>>
>>>>>> 1
>>>>>> -2.0
>>>>>> xyz
>>>>>> 7bz
>>>>>>
>>>>>> it should print 2.0 ((1 - 2 + 7)/3).
>>>>> <snip>
>>> <snip>
>>>>> Issues not solved yet:
>>>>> 1) I have not yet found the way to print ((1 - 2 + 7)/3)
>>>>
>>>> Sorry, that was by way of explanation. It should just print 2.0.
>>>
>>> Still it would be interesting to found out how to print out this type
>>> of output given the unknown number of digits and the possible
>>> variability of their signs. Is it possible?
>>
>> Yes, of course it's possible, but it's completely outside the remit of
>> the spec. It's because you keep flying off at tangents that you never
>> learn anything.
>>
>>> I need the average function in my program anyway,
>>
>> Not in Ben's challenge, you don't.
>>
>> #include <stdio.h>
>> #include <stdlib.h>
>>
>> int main(void)
>> {
>> double d = 0.0;
>> double endptr = 0.0;
>> double average = 0.0;
>> unsigned long int n = 0;
>> char line[100] = "";
>> while(fgets(line, sizeof line, stdin) != NULL)
>> {
>> d = strtod(line, &endptr);
>> if(endptr > d)
>> {
>> average = (d + n * average) / (n + 1);
>> }
>> }
>> printf("%f\n", average);
>> return 0;
>> }
>
> Oh...
>
> On the other hand you have missed one aspect: the line that
> starts with while spaces followed by the number should be accepted;
> will strtod traverse beginning white spaces before it hits a number?
Yes, of course.
> And your code doesn't process the file, but gets the data from the
> stdin.
./foo < infile
--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-01-01 16:53 +0000 |
| Message-ID | <87k2aepvqy.fsf@bsb.me.uk> |
| In reply to | #100784 |
Alla _ <modelling.data@gmail.com> writes:
> On Sunday, January 1, 2017 at 3:39:07 PM UTC+3, Richard Heathfield wrote:
<snip>
>> > I need the average function in my program anyway,
>>
>> Not in Ben's challenge, you don't.
>>
>> #include <stdio.h>
>> #include <stdlib.h>
>>
>> int main(void)
>> {
>> double d = 0.0;
>> double endptr = 0.0;
>> double average = 0.0;
>> unsigned long int n = 0;
>> char line[100] = "";
>> while(fgets(line, sizeof line, stdin) != NULL)
>> {
>> d = strtod(line, &endptr);
>> if(endptr > d)
>> {
>> average = (d + n * average) / (n + 1);
>> }
>> }
>> printf("%f\n", average);
>> return 0;
>> }
>
> Oh...
>
> On the other hand you have missed one aspect: the line that
> starts with while spaces followed by the number should be accepted;
> will strtod traverse beginning white spaces before it hits a number?
What reference are you using to find out what functions C has and what
they do? Without some reference manual you are will be very seriously
hampered. Unfortunately the web is full of terrible reference material,
but your local system's manual pages are probably OK.
> And your code doesn't process the file, but gets the data from the
> stdin.
I did not specify from a file. My preference is for program that can do
both. I often write
FILE *input = argc > 1 ? fopen(argv[1], "r") : stdin;
but in fact I don't care since on my system I can make your program do
what I prefer to simple testing by specifying the magic file
"/dev/stdin" on the command lines and I can make Richard's version read
a file by using redirection (./the-program <some-file-name).
>> Your solution had hundreds of lines. The above has 21 lines, and a tiny
>> handful of statements. |This is the kind of simplicity for which you
>> should be striving.
> I know. I try. Upset. Overcomplicate things as usual.
Don't be put off. It's inevitable that you will have been thinking
along the lines you were already travelling on. In a C course, I would
probably set this exercise before introducing arrays, so storing the
data would not even be an option.
Had I wanted a minimal solution (and I had not yet decided what I wanted
you to aim for) I would have suggested a series of simplifications once
you'd got everything done: "now just use stdin", "now try to do it
without an array", and so on. Simply pulling a rabbit like this out of
a hat can be really disheartening for a student.
> Also I thought that I always have to split everything into
> functions.
Not for the sake of it, but I would not be surprised if a student who's
been drilled on functional decomposition writes a function that gets the
average of some numbers from a stream. But in this case, I would not
mark Richard down for not decomposing the program :-)
Your structure of taking the processing out of main is a good one.
Often the main function gets cluttered with processing command-line
arguments, reading in configuration data and so one, so taking all the
actual work out into a "process this stream" function is a good one.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2017-01-01 09:18 -0800 |
| Message-ID | <db48274d-2b0b-42ff-bfb2-42861d9c33e9@googlegroups.com> |
| In reply to | #100788 |
On Sunday, January 1, 2017 at 7:53:34 PM UTC+3, Ben Bacarisse wrote: > Alla _ <modelling.data@gmail.com> writes: > > <snip> > > > > On the other hand you have missed one aspect: the line that > > starts with while spaces followed by the number should be accepted; > > will strtod traverse beginning white spaces before it hits a number? > > What reference are you using to find out what functions C has and what > they do? Without some reference manual you are will be very seriously > hampered. Unfortunately the web is full of terrible reference material, > but your local system's manual pages are probably OK. I use manual pages, but they are usually too cryptic, so I do use a lot of information from the web, scan it, skim through, pick up things that seem reasonable... come here, and.... get a flak ) <snip>
[toc] | [prev] | [next] | [standalone]
| From | Manfred <noname@invalid.add> |
|---|---|
| Date | 2017-01-01 19:20 +0100 |
| Message-ID | <o4bh9h$v9o$1@gioia.aioe.org> |
| In reply to | #100792 |
On 1/1/2017 6:18 PM, Alla _ wrote: > > I use manual pages, but they are usually too cryptic, so I do use > a lot of information from the web, scan it, skim through, pick up > things that seem reasonable... come here, and.... get a flak ) > <snip> > manpages can be a bit cryptic (esp. for beginners), but more properly they are written with two goals in mind: - be accurate and complete (because users want to find every detail in them) - be concise (because users don't want to spend too much time in reading what they already know) The combination of the two results in very condensed text, but their value (esp. for of the first part) is extremely useful for anyone, so they are worth the effort. One limit is that, while they are great if you know what you are looking for, they are not aimed at giving overviews.
[toc] | [prev] | [next] | [standalone]
| From | Barry Schwarz <schwarzb@dqel.com> |
|---|---|
| Date | 2017-01-01 15:18 -0800 |
| Message-ID | <eb3j6ctk8cr78in34urtrcf0qk90qb2bq5@4ax.com> |
| In reply to | #100784 |
On Sun, 1 Jan 2017 08:13:16 -0800 (PST), Alla _ <modelling.data@gmail.com> wrote: >will strtod traverse beginning white spaces before it hits a number? If you haven't done so already, download one of the free drafts of the C standard. n1570 is the draft of the C11 standard and has very readable descriptions of the library functions. It is astounding to me after that all this time you do not make the effort to look this stuff up before asking here. -- Remove del for email
[toc] | [prev] | [next] | [standalone]
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2017-01-02 03:41 -0800 |
| Message-ID | <ad2252de-0d9b-42ee-b7b1-0a25d4399c5d@googlegroups.com> |
| In reply to | #100830 |
On Monday, January 2, 2017 at 2:18:48 AM UTC+3, Barry Schwarz wrote: > On Sun, 1 Jan 2017 08:13:16 -0800 (PST), Alla _ > <modelling.data@gmail.com> wrote: > > >will strtod traverse beginning white spaces before it hits a number? > > If you haven't done so already, download one of the free drafts of the > C standard. n1570 is the draft of the C11 standard and has very > readable descriptions of the library functions. > > It is astounding to me after that all this time you do not make the > effort to look this stuff up before asking here. I usually do; this was one of those very rare times when I didn't see that, and didn't dig deeper. My mistake.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-01-01 15:07 +0000 |
| Message-ID | <874m1irf8l.fsf@bsb.me.uk> |
| In reply to | #100765 |
Alla _ <modelling.data@gmail.com> writes:
> On Saturday, December 31, 2016 at 11:10:43 PM UTC+3, Ben Bacarisse wrote:
>> Alla _ <modelling.data@gmail.com> writes:
>>
>> > On Friday, December 30, 2016 at 4:35:33 PM UTC+3, Ben Bacarisse wrote:
>> >> Alla _ <modelling.data@gmail.com> writes:
>> >>
>> > <snip>
>> >> I would set a student these exercises:
>> >>
>> >> 1. Write a program that reads lines into a fix-size buffer (100
>> >> characters will do) and prints the average of any numbers found at the
>> >> start of a line (except for white-space). It should ignore lines that
>> >> don't start with a number. So, given
>> >>
>> >> 1
>> >> -2.0
>> >> xyz
>> >> 7bz
>> >>
>> >> it should print 2.0 ((1 - 2 + 7)/3).
>> > <snip>
> <snip>
>> > Issues not solved yet:
>> > 1) I have not yet found the way to print ((1 - 2 + 7)/3)
>>
>> Sorry, that was by way of explanation. It should just print 2.0.
>
> Still it would be interesting to found out how to print out this type
> of output given the unknown number of digits and the possible
> variability of their signs. Is it possible?
Yes. Exactly how would depend on what you mean by "the unknown number
of digits". If you want the output to reflect exactly the input then
you'd have to do something more complex like store the numbers as
strings as well as doubles.
>> > 2) I have not found the way to test my average function for success;
>> > one of the options I used was if(the values of average != 0), but this
>> > is incorrect because average can be 0.
>>
>> The average function must indicate success or failure in some way if you
>> are to do this. I wouldn't bother because this is intended to be an
>> exercise in reading numbers -- I'd just make sure I don't call the
>> average function unless at least one number was seen.
>
> I need the average function in my program anyway, if you recall the spec
> I have showed. Also I believe that I might have to deal a few times
> with these types of functions, which might not have a straightforward
> solution for success/failure test.
> Therefore, please, advice me on what approaches can be used here.
I'm not sure what you mean. I suggest postponing that until the
situation arises so there is a concrete example to discuss.
>> > #include <stdio.h>
>> > #include <stdlib.h>
>> > #include <ctype.h>
>> > #include <string.h>
>> > #include <stdbool.h>
>> > #include <errno.h>
>>
>> You don't use errno (except for setting it) so you don't need this
>> file. Include it if and when you do decide you need to use errno.
> Don't I need this header if I set errno to 0?
Yes, but why are you setting it to 0? Your program would behave exactly
the same if you deleted that setting and the #include.
> A few posts ago I have written that the errno, stderr, etc are still
> topics, which I don't understand, and have not yet learned about.
> I have made some corrections to the code based on helpful advice
> Barry has suggested, and therefore have read some material on
> these topics, but those are not yet sufficient.
If you don't understand what was said about errno then you need to ask
in the thread where it was relevant. I suggest you don't use errno
here. This is all part of the plan to focus on how to read what you
want rather than worry about what can go wrong.
stderr is simple a stream whose purpose if for error message or other
output that is not in some rather vague sense the real output from the
program. If all your debug messages go to stderr:
fprintf(stderr, "Line %d is not valid.\", l_num);
I (and others) can separate the real output form the error messages.
That often makes testing simpler. And since the default set up is that
output to stderr goes to the console the program output looks the same
to someone who does not care to separate the two streams.
>> > #define BUFFER_SIZE 100
> <snip>
>> > if ( fp )
>> > {
>> > int numbers[BUFFER_SIZE] = {0};
>>
>> That size is wrong. There is no connection between the maximum length
>> of the line and the number of lines you will process.
>>
>> In fact, I had not intended that you store the numbers at all, but if
>> you do you should use a size with its own helpful name, even if its
>> value happens to be the same as BUFFER_SIZE and you must check that you
>> don't try to save more then will fit.
>
> I have corrected the size. But: yes, I can't figure out how to work with the
> input without first reading it into the buffer, and then taking only valid
> characters out of that buffer. I have tried it not only for this exercise,
> but I don't see the solution yet. Still waiting to get to my "aha" moment.
> I assume it will make the code more clear.
To calculate the average, all you need is the sum and the count.
My plan was to focus on the input side of things to keep the program
very simple, but you clearly started this by editing an older program
that was already more complicated tha was strictly needed.
But don't worry. You will need to store the numbers in your final
program so provided that part does no get in that way of focusing on the
input side of things, keep storing the numbers.
<snip>
>> > bool get_line (FILE *input_file, int *numbers, size_t *index_n)
>> > {
>> > char buffer[BUFFER_SIZE] = "";
>> > char *ptr = NULL;
>> > char *not_converted = NULL;
>> > int number;
>> > size_t index_ch;
>>
>> Earlier, you declared some objects close to where they are needed but
>> here you declare everything here in one go. I don't mind which you do,
>> but it helps the reader if you stick to one or the other.
>>
> I see. I have moved some declarations close to place of usage. Is this what
> you mean?
Yes. Exactly how close is another matter.
I like to give names very small scope so I like the fact the modern C
(C99 and later) allows me to put declarations after statements. In old
C, you had to put declarations at the start of a compound statement
(i.e. just after a {).
You need to decide if you want to use the C99 style in which case you
can often leave the declaration to just before the first use. If you
want to use the older style I'd suggest you put the declarations at the
start of the smallest enclosing block that uses the name.
Some people do advocate for putting all the declarations at the top of a
function. What matters most is to be consistent. That way when I see a
name being used I know here to look. Will it be declared very near, at
the top of some near enclosing block or at the top of the function?
The new version still uses a bit of all of these.
> (I will post the whole code below, here just corrected parts).
> Edit after reading the whole post: I have deleted all testing, see at the end
> of the post; but here I still have them to make sure I have correctly
> understood you.
> /** Process the data only if the buffer has valid
> input
> **/
> if( isdigit(buffer[index_ch])
> || (buffer[index_ch] == '-'
> && isdigit(buffer[index_ch+1])))
> {
> char *ptr = &buffer[index_ch];
> char *not_converted = NULL;
> double number = (double)strtod(ptr, ¬_converted);
Yes, that's what I meant.
> if (not_converted > ptr)
> {
> numbers[(*index_n)++] = number;
> puts("Number is parsed.");
> }
> }
>
>> >
>> > //Read each character from the file, store in a buffer
>>
>> I would say that comment is wrong. It may be how you see what's
>> happening, but comments should be for other people. You can safely
>> assume that everyone reading your program knows what a while loop with
>> fgets in the condition is doing.
> I see. Does this one sound better:
> //Parse file data, store only numbers
Yes, though I still question the need for any comment at all.
>> > while( fgets(buffer, sizeof(buffer), input_file) != NULL)
<snip>
>> > if (ferror(input_file))
>>
>> It's noble that you consider file errors at all as so many people don't.
>> But they don't for a reason -- they are rare and testing the code is
>> very hard. I won't suggest you remove the code, but it's going above
>> and beyond what I'd expect from a student.
>
> Then in this case let's not treat me as a student ))) I am happy
> to learn and develop good habits, even if they might be more sophisticated at
> this point. It is important for me. Please, consider not "protecting" me
> from these type of essential features.
But they are not essential. There are lots of very fine programs that
don't test for file errors. In some sense they are all flawed, but in
some other sense they are all examples of good engineering.
As for protecting you that's not the point. The point of an exercise is
to focus on something in particular. Dealing with read errors is a
distraction. And notice that you are not dealing with write errors or
error on close. It's good to simplify. You learn more that way, not
less.
<snip>
>> > /** Find the average **/
>> > void average(int *numbers, float *average_num, size_t index)
>>
>> const int *numbers -- help the reader out.
>>
>> > {
>> > float sum = 0;
>> > for(size_t i = 0; i < index; i++)
>> > sum += numbers[i];
>> >
>> > *average_num = sum/index;
>>
>> You should test that index is not zero or (and this is perfectly valid)
>> document the fact that the index must be > 0 in a comment and make sure
>> you never call this function with index == 0.
>
> The reason I have not tested the index is because I call the average function
> only if the get_lines (new name with -s at the end :) ) is successful, and
> therefore index cannot be zero. Why is this assumption incorrect?
I don't know what to say except that it's false. get_line (and now
get_lines) can return true when no numbers have been stored.
> I have added the test now, see below in the whole program.
Great. You also need to amend the comment so someone reading about the
average function knows that you have chosen to protect the calls rather
than put the test for zero in average itself. Saying something like
"this function must always be called with index > 0" is more useful than
any other comment in your code so far.
<snip>
>> (3) Don't print anything but the average on stdout. All errors and
>> debugging messages should go to stderr.
> As I have noted above it is still a conundrum for me, I have to learn
> what stderr exactly is, what is happening underneath the hood,
> and how to see its messages, even though I know when and how
> to use some pieces of code that include stderr.
Send everything but the actual average to stderr. You do that by using
fprintf(stderr, ...) rather than printf and fputs rather than puts.
Sadly puts and fputs are not exactly the same. puts adds a newline an
fputs does not so you must change puts("error!") to fputs("error!\n",
stderr).
Do that and then ask followup questions if you are confused. It's hard
to respond to a sense that you are just unsure about stderr.
<snip>
>> (4) If you store the numbers, make sure you can't overrun the array.
> done, but still would like to learn how not to store the input in additional
> array
Just store the sum as you go.
>> (5) Simplify the scanning by letting strtod do it all.
> done
Not quite. You still process spaces while strtod does that for you.
> Here is the corrected version:
> #include <stdio.h>
> #include <stdlib.h>
> #include <ctype.h>
> #include <string.h>
> #include <stdbool.h>
> #include <errno.h>
>
> #define BUFFER_SIZE 100
> #define NUMBERS 100
> #define TEXT "../files/ex_1.csv"
>
> bool get_lines (FILE *input_file, double *numbers, size_t *index_n);
> double average(const double *numbers, size_t index);
>
> int main(int argc, char *argv[])
> {
> //Check for correct number of arguments
> if(argc > 2)
> {
> fputs("Sorry, the program processes only one file.\n", stderr);
> return EXIT_FAILURE;
> }
> //Determine a file to use
> const char *data_file = (argc == 2)? argv[1] : TEXT;
> errno = 0;
>
> FILE *fp = fopen(data_file, "r");
>
> if ( fp )
> {
> double numbers[NUMBERS] = {0};
> size_t index_n = 0;
> double average_num;
>
> if( !get_lines(fp, numbers, &index_n) )
> {
> puts("Reading file failed");
get_lines has already reported the error. Do you need another message?
> fclose(fp);
> return EXIT_FAILURE;
> }
>
> if(index_n > 0)
> {
> average_num = average(numbers, index_n);
You could declare average_num here. But you could also just write
printf("The average is %.2f\n", average(numbers, index_n));
(Technically I wanted just the average.)
> printf("The average is %.2f\n", average_num);
> fclose(fp);
> return EXIT_SUCCESS;
> }
> }
> //Couldn't open the file
> printf("%s - %s\n", data_file, errno ? strerror(errno) : "Open failure!");
> return EXIT_FAILURE;
> }
>
> /** Function to read and process the data
> from the file line by line
> **/
> bool get_lines (FILE *input_file, double *numbers, size_t *index_n)
> {
> char buffer[BUFFER_SIZE] = "";
> size_t index_ch;
> size_t line = 0;
>
> //Parse file data, store only numbers
> while( fgets(buffer, sizeof(buffer), input_file) != NULL)
> {
> line++;
> index_ch = 0;
>
> //Skip spaces at the begining of the line
> while(isspace(buffer[index_ch]))
> index_ch++;
>
> char *ptr = &buffer[index_ch];
You don't need all this space testing.
> char *not_converted = NULL;
> double number = (double)strtod(ptr, ¬_converted);
The cast is not needed. Note that this is an example of a C99
declaration that follows some statements.
> if (not_converted > ptr && *index_n < NUMBERS)
> numbers[(*index_n)++] = number;
OK, but you report a file error (which is rare) and yet you don't report
failing to be able to process all the numbers the user wants you to
process. That's a much more likely error. I'd make it be a reason to
return failure from get_lines.
Nearly there, I'd say.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2017-01-01 09:05 -0800 |
| Message-ID | <c77c7560-02bd-47f0-9b74-cafadc5b57f2@googlegroups.com> |
| In reply to | #100777 |
On Sunday, January 1, 2017 at 6:07:14 PM UTC+3, Ben Bacarisse wrote:
> Alla _ <modelling.data@gmail.com> writes:
>
<snip>
> > I need the average function in my program anyway, if you recall the spec
> > I have showed. Also I believe that I might have to deal a few times
> > with these types of functions, which might not have a straightforward
> > solution for success/failure test.
> > Therefore, please, advice me on what approaches can be used here.
>
> I'm not sure what you mean. I suggest postponing that until the
> situation arises so there is a concrete example to discuss.
>
All right. It will come up in my program.
> >> > #include <stdio.h>
> >> > #include <stdlib.h>
> >> > #include <ctype.h>
> >> > #include <string.h>
> >> > #include <stdbool.h>
> >> > #include <errno.h>
> >>
> >> You don't use errno (except for setting it) so you don't need this
> >> file. Include it if and when you do decide you need to use errno.
> > Don't I need this header if I set errno to 0?
>
> Yes, but why are you setting it to 0? Your program would behave exactly
> the same if you deleted that setting and the #include.
I set errno to 0 before calling fopen because doesn't guarantee to
set errno. I have read about it here:
https://www.securecoding.cert.org/confluence/pages/viewpage.action?pageId=6619179
The article is called:
Set errno to zero before calling a library function known to set errno,
and check errno only after the function returns a value indicating failure
<snip>
>
<snip>
>
> My plan was to focus on the input side of things to keep the program
> very simple, but you clearly started this by editing an older program
> that was already more complicated tha was strictly needed.
>
> But don't worry. You will need to store the numbers in your final
> program so provided that part does no get in that way of focusing on the
> input side of things, keep storing the numbers.
>
> <snip>
> >> > bool get_line (FILE *input_file, int *numbers, size_t *index_n)
> >> > {
> >> > char buffer[BUFFER_SIZE] = "";
> >> > char *ptr = NULL;
> >> > char *not_converted = NULL;
> >> > int number;
> >> > size_t index_ch;
> >>
> >> Earlier, you declared some objects close to where they are needed but
> >> here you declare everything here in one go. I don't mind which you do,
> >> but it helps the reader if you stick to one or the other.
> >>
> > I see. I have moved some declarations close to place of usage. Is this what
> > you mean?
>
> Yes. Exactly how close is another matter.
>
> I like to give names very small scope so I like the fact the modern C
> (C99 and later) allows me to put declarations after statements. In old
> C, you had to put declarations at the start of a compound statement
> (i.e. just after a {).
>
> You need to decide if you want to use the C99 style in which case you
> can often leave the declaration to just before the first use. If you
> want to use the older style I'd suggest you put the declarations at the
> start of the smallest enclosing block that uses the name.
>
> Some people do advocate for putting all the declarations at the top of a
> function. What matters most is to be consistent. That way when I see a
> name being used I know here to look. Will it be declared very near, at
> the top of some near enclosing block or at the top of the function?
>
> The new version still uses a bit of all of these.
>
I see.
<snip>
<snip>
>
> But they are not essential. There are lots of very fine programs that
> don't test for file errors. In some sense they are all flawed, but in
> some other sense they are all examples of good engineering.
>
> As for protecting you that's not the point. The point of an exercise is
> to focus on something in particular. Dealing with read errors is a
> distraction. And notice that you are not dealing with write errors or
> error on close. It's good to simplify. You learn more that way, not
> less.
Yes, I understand. Thank you!
>
<snip>
> > I have added the test now, see below in the whole program.
>
> Great. You also need to amend the comment so someone reading about the
> average function knows that you have chosen to protect the calls rather
> than put the test for zero in average itself. Saying something like
> "this function must always be called with index > 0" is more useful than
> any other comment in your code so far.
done
>
<snip>
>
> Send everything but the actual average to stderr. You do that by using
> fprintf(stderr, ...) rather than printf and fputs rather than puts.
> Sadly puts and fputs are not exactly the same. puts adds a newline an
> fputs does not so you must change puts("error!") to fputs("error!\n",
> stderr).
>
> Do that and then ask followup questions if you are confused. It's hard
> to respond to a sense that you are just unsure about stderr.
>
Please, take a look at a version I post below; have I used stderr correctly?
Is it all right that I am posting the whole program again?
> <snip>
> >> (4) If you store the numbers, make sure you can't overrun the array.
> > done, but still would like to learn how not to store the input in additional
> > array
>
> Just store the sum as you go.
>
I see. For now I keep the array - you said it is not a problem.
> >> (5) Simplify the scanning by letting strtod do it all.
> > done
>
> Not quite. You still process spaces while strtod does that for you.
I have missed this in the manual, and didn't know that strtod deals
with beginning spaces.
<snip>
> > if(index_n > 0)
> > {
> > average_num = average(numbers, index_n);
>
> You could declare average_num here. But you could also just write
>
> printf("The average is %.2f\n", average(numbers, index_n));
Yes, I know this feature )) Sometimes I believe that using a separate
variable and assigning a value to it is more readable, isn't it?
>
> (Technically I wanted just the average.)
Do you mean that I shouldn't print "The average is..."? Just in
case you mean this, I have deleted those words, though I assume
this is a very insignificant part.
>
<snip>
> > char *not_converted = NULL;
> > double number = (double)strtod(ptr, ¬_converted);
>
> The cast is not needed. Note that this is an example of a C99
> declaration that follows some statements.
>
> > if (not_converted > ptr && *index_n < NUMBERS)
> > numbers[(*index_n)++] = number;
>
> OK, but you report a file error (which is rare) and yet you don't report
> failing to be able to process all the numbers the user wants you to
> process. That's a much more likely error. I'd make it be a reason to
> return failure from get_lines.
I didn't understand this. Do you mean that I should return failure if
one of the lines doesn't have a correct format of the input, i.e. there
are no numerical characters at the beginning of the line? If I return
failure after such line, then the program will stop and will not record
any other numbers from other lines. I didn't understand that the
program should stop if it stumbles upon an incorrect line; I thought
it should just skip it and continue reading the file.
>
> Nearly there, I'd say.
Here is the program, but:
- errno is still there (not that I persist, we can skip this matter for now)
- I don't yet return failure from get_lines if any of the lines doesn't start
with a number; if you have reached this point, you have already seen
my explanation above )
#include <stdio.h>
#include <stdlib.h>
#include <ctype.h>
#include <string.h>
#include <stdbool.h>
#include <errno.h>
#define BUFFER_SIZE 100
#define NUMBERS 100
#define TEXT "../files/ex_1.csv"
bool get_lines (FILE *input_file, double *numbers, size_t *index_n);
double average(const double *numbers, size_t index);
int main(int argc, char *argv[])
{
//Check for correct number of arguments
if(argc > 2)
{
fputs("Sorry, the program processes only one file.\n", stderr);
return EXIT_FAILURE;
}
//Determine a file to use
const char *data_file = (argc == 2)? argv[1] : TEXT;
errno = 0;
FILE *fp = fopen(data_file, "r");
if ( fp )
{
double numbers[NUMBERS] = {0};
size_t index_n = 0;
double average_num;
if( !get_lines(fp, numbers, &index_n) )
{
fclose(fp);
return EXIT_FAILURE;
}
//Call function average only when index_n > 0
if(index_n > 0)
{
average_num = average(numbers, index_n);
printf("%.2f\n", average_num);
fclose(fp);
return EXIT_SUCCESS;
}
}
//Couldn't open the file
fprintf(stderr, "%s - %s\n", data_file, errno ? strerror(errno) : "Open failure!");
return EXIT_FAILURE;
}
/** Function to read and process the data
from the file line by line
**/
bool get_lines (FILE *input_file, double *numbers, size_t *index_n)
{
char buffer[BUFFER_SIZE] = "";
size_t index_ch;
size_t line = 0;
//Parse file data, store only numbers
while( fgets(buffer, sizeof(buffer), input_file) != NULL)
{
line++;
index_ch = 0;
char *ptr = &buffer[index_ch];
char *not_converted = NULL;
double number = strtod(ptr, ¬_converted);
if (not_converted > ptr && *index_n < NUMBERS)
numbers[(*index_n)++] = number;
}
if (ferror(input_file))
{
puts("The function detected an error reading a file.");
if(*index_n != 0)
fprintf(stderr, "Last input processed was at line '%zu': %s\n", line, buffer);
return false;
}
return true;
}
/** Find the average **/
double average(const double *numbers, size_t index)
{
double sum = 0;
for(size_t i = 0; i < index; i++)
sum += numbers[i];
return sum/index;
}
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-01-01 19:16 +0000 |
| Message-ID | <8737h2pp4x.fsf@bsb.me.uk> |
| In reply to | #100789 |
Alla _ <modelling.data@gmail.com> writes:
> On Sunday, January 1, 2017 at 6:07:14 PM UTC+3, Ben Bacarisse wrote:
>> Alla _ <modelling.data@gmail.com> writes:
>>
> <snip>
>> > I need the average function in my program anyway, if you recall the spec
>> > I have showed. Also I believe that I might have to deal a few times
>> > with these types of functions, which might not have a straightforward
>> > solution for success/failure test.
>> > Therefore, please, advice me on what approaches can be used here.
>>
>> I'm not sure what you mean. I suggest postponing that until the
>> situation arises so there is a concrete example to discuss.
>>
> All right. It will come up in my program.
>> >> > #include <stdio.h>
>> >> > #include <stdlib.h>
>> >> > #include <ctype.h>
>> >> > #include <string.h>
>> >> > #include <stdbool.h>
>> >> > #include <errno.h>
>> >>
>> >> You don't use errno (except for setting it) so you don't need this
>> >> file. Include it if and when you do decide you need to use errno.
>> > Don't I need this header if I set errno to 0?
>>
>> Yes, but why are you setting it to 0? Your program would behave exactly
>> the same if you deleted that setting and the #include.
> I set errno to 0 before calling fopen because doesn't guarantee to
> set errno. I have read about it here:
> https://www.securecoding.cert.org/confluence/pages/viewpage.action?pageId=6619179
> The article is called:
> Set errno to zero before calling a library function known to set errno,
> and check errno only after the function returns a value indicating
> failure
I made a mistake. Sorry. I did not see that you actually used the
value of errno.
The handling of errno is very messy. As far as standard C goes, fopen
is not known to set errno so the article does not apply. However, on
almost all systems, fopen does set errno so you are doing it right for
those systems.
The problem here is the amount of noise that has nothing to do with what
the exercise was intended to illustrate. Remember this was one of four
exercises that were meant to be quick to write -- a few minutes each --
in order to build up the idea of parsing what you need. I hope you can
keep the focus on that.
<snip>
>> Send everything but the actual average to stderr. You do that by using
>> fprintf(stderr, ...) rather than printf and fputs rather than puts.
>> Sadly puts and fputs are not exactly the same. puts adds a newline an
>> fputs does not so you must change puts("error!") to fputs("error!\n",
>> stderr).
>>
>> Do that and then ask followup questions if you are confused. It's hard
>> to respond to a sense that you are just unsure about stderr.
>>
> Please, take a look at a version I post below; have I used stderr
> correctly?
Yes, except for one remaining use of puts.
> Is it all right that I am posting the whole program again?
Yes, I think that helps. Code fragments getting modified become
confusing very fast.
<snip>
>> > if(index_n > 0)
>> > {
>> > average_num = average(numbers, index_n);
>>
>> You could declare average_num here. But you could also just write
>>
>> printf("The average is %.2f\n", average(numbers, index_n));
>
> Yes, I know this feature )) Sometimes I believe that using a separate
> variable and assigning a value to it is more readable, isn't it?
I've never found it to be, but then I am weird, it seems. I just find
it distracting.
>>
>> (Technically I wanted just the average.)
> Do you mean that I shouldn't print "The average is..."? Just in
> case you mean this, I have deleted those words, though I assume
> this is a very insignificant part.
Your program might be used to drive other programs. Lets say you want
to plot a file of data but with a horizontal line at the average. If
the plot program take an argument "--line-at y" to draw a line on the
graph at y, I can use your program like this:
plot --line-at $(average data-file) data-file
where I could not do that (at least not so easily) if it adds extra text.
This fact seems to divide the world into those that think the minimal
output is obviously better and people who go blue int the face with fury
about the unhelpful output of some utility programs.
<snip>
>> > if (not_converted > ptr && *index_n < NUMBERS)
>> > numbers[(*index_n)++] = number;
>>
>> OK, but you report a file error (which is rare) and yet you don't report
>> failing to be able to process all the numbers the user wants you to
>> process. That's a much more likely error. I'd make it be a reason to
>> return failure from get_lines.
>
> I didn't understand this. Do you mean that I should return failure if
> one of the lines doesn't have a correct format of the input, i.e. there
> are no numerical characters at the beginning of the line?
No. What do you think your program should do when presented with a file
of 200 lines all with valid numbers on them?
<snip>
>> Nearly there, I'd say.
> Here is the program, but:
<snip>
> #include <stdio.h>
> #include <stdlib.h>
> #include <ctype.h>
> #include <string.h>
> #include <stdbool.h>
> #include <errno.h>
>
> #define BUFFER_SIZE 100
> #define NUMBERS 100
> #define TEXT "../files/ex_1.csv"
>
> bool get_lines (FILE *input_file, double *numbers, size_t *index_n);
> double average(const double *numbers, size_t index);
>
> int main(int argc, char *argv[])
> {
> //Check for correct number of arguments
> if(argc > 2)
> {
> fputs("Sorry, the program processes only one file.\n", stderr);
> return EXIT_FAILURE;
> }
> //Determine a file to use
> const char *data_file = (argc == 2)? argv[1] : TEXT;
> errno = 0;
> FILE *fp = fopen(data_file, "r");
> if ( fp )
> {
> double numbers[NUMBERS] = {0};
> size_t index_n = 0;
> double average_num;
>
> if( !get_lines(fp, numbers, &index_n) )
> {
> fclose(fp);
> return EXIT_FAILURE;
> }
> //Call function average only when index_n > 0
> if(index_n > 0)
> {
> average_num = average(numbers, index_n);
> printf("%.2f\n", average_num);
> fclose(fp);
> return EXIT_SUCCESS;
> }
> }
> //Couldn't open the file
> fprintf(stderr, "%s - %s\n", data_file, errno ? strerror(errno) : "Open failure!");
> return EXIT_FAILURE;
> }
> /** Function to read and process the data
> from the file line by line
> **/
> bool get_lines (FILE *input_file, double *numbers, size_t *index_n)
> {
> char buffer[BUFFER_SIZE] = "";
> size_t index_ch;
> size_t line = 0;
>
> //Parse file data, store only numbers
> while( fgets(buffer, sizeof(buffer), input_file) != NULL)
> {
> line++;
> index_ch = 0;
> char *ptr = &buffer[index_ch];
What's the point of ptr? ptr == buffer.
> char *not_converted = NULL;
> double number = strtod(ptr, ¬_converted);
>
> if (not_converted > ptr && *index_n < NUMBERS)
> numbers[(*index_n)++] = number;
> }
>
> if (ferror(input_file))
> {
> puts("The function detected an error reading a file.");
puts writes to stdout not stderr.
> if(*index_n != 0)
> fprintf(stderr, "Last input processed was at line '%zu': %s\n", line, buffer);
> return false;
> }
> return true;
> }
>
> /** Find the average **/
You are still not commenting on the fact that this function needs to be
called with index > 0. I know it's not a complicated function, but that
fact is more important than "Find the average".
> double average(const double *numbers, size_t index)
> {
> double sum = 0;
> for(size_t i = 0; i < index; i++)
> sum += numbers[i];
>
> return sum/index;
> }
Very close now.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2017-01-02 03:39 -0800 |
| Message-ID | <e888f66d-c5af-4305-a338-6586d949377e@googlegroups.com> |
| In reply to | #100801 |
On Sunday, January 1, 2017 at 10:16:21 PM UTC+3, Ben Bacarisse wrote:
> Alla _ <modelling.data@gmail.com> writes:
>
> > On Sunday, January 1, 2017 at 6:07:14 PM UTC+3, Ben Bacarisse wrote:
> >> Alla _ <modelling.data@gmail.com> writes:
> >>
> > <snip>
> >> > I need the average function in my program anyway, if you recall the spec
> >> > I have showed. Also I believe that I might have to deal a few times
> >> > with these types of functions, which might not have a straightforward
> >> > solution for success/failure test.
> >> > Therefore, please, advice me on what approaches can be used here.
> >>
> >> I'm not sure what you mean. I suggest postponing that until the
> >> situation arises so there is a concrete example to discuss.
> >>
> > All right. It will come up in my program.
> >> >> > #include <stdio.h>
> >> >> > #include <stdlib.h>
> >> >> > #include <ctype.h>
> >> >> > #include <string.h>
> >> >> > #include <stdbool.h>
> >> >> > #include <errno.h>
> >> >>
> >> >> You don't use errno (except for setting it) so you don't need this
> >> >> file. Include it if and when you do decide you need to use errno.
> >> > Don't I need this header if I set errno to 0?
> >>
> >> Yes, but why are you setting it to 0? Your program would behave exactly
> >> the same if you deleted that setting and the #include.
> > I set errno to 0 before calling fopen because doesn't guarantee to
> > set errno. I have read about it here:
> > https://www.securecoding.cert.org/confluence/pages/viewpage.action?pageId=6619179
> > The article is called:
> > Set errno to zero before calling a library function known to set errno,
> > and check errno only after the function returns a value indicating
> > failure
>
> I made a mistake. Sorry. I did not see that you actually used the
> value of errno.
>
> The handling of errno is very messy. As far as standard C goes, fopen
> is not known to set errno so the article does not apply.
This article states exactly this, and explains that it is recommended
to set errno to 0 before calling fopen. Let's skip all this for now.
>However, on
> almost all systems, fopen does set errno so you are doing it right for
> those systems.
>
> The problem here is the amount of noise that has nothing to do with what
> the exercise was intended to illustrate. Remember this was one of four
> exercises that were meant to be quick to write -- a few minutes each --
> in order to build up the idea of parsing what you need. I hope you can
> keep the focus on that.
Yes, of course.
>
> <snip>
> >> Send everything but the actual average to stderr. You do that by using
> >> fprintf(stderr, ...) rather than printf and fputs rather than puts.
> >> Sadly puts and fputs are not exactly the same. puts adds a newline an
> >> fputs does not so you must change puts("error!") to fputs("error!\n",
> >> stderr).
> >>
> >> Do that and then ask followup questions if you are confused. It's hard
> >> to respond to a sense that you are just unsure about stderr.
> >>
> > Please, take a look at a version I post below; have I used stderr
> > correctly?
>
> Yes, except for one remaining use of puts.
I have missed it, I did hope I have deleted all those puts ) Sorry.
>
> > Is it all right that I am posting the whole program again?
>
> Yes, I think that helps. Code fragments getting modified become
> confusing very fast.
>
<snip>
> >>
> >> (Technically I wanted just the average.)
> > Do you mean that I shouldn't print "The average is..."? Just in
> > case you mean this, I have deleted those words, though I assume
> > this is a very insignificant part.
>
> Your program might be used to drive other programs. Lets say you want
> to plot a file of data but with a horizontal line at the average. If
> the plot program take an argument "--line-at y" to draw a line on the
> graph at y, I can use your program like this:
>
> plot --line-at $(average data-file) data-file
>
> where I could not do that (at least not so easily) if it adds extra text.
>
I see. And it is very distracting, because it is interesting and I have no
idea how this works ) As we have decided, I am not asking any questions
on this terminal command, for now. )
> This fact seems to divide the world into those that think the minimal
> output is obviously better and people who go blue int the face with fury
> about the unhelpful output of some utility programs.
>
> <snip>
> >> > if (not_converted > ptr && *index_n < NUMBERS)
> >> > numbers[(*index_n)++] = number;
> >>
> >> OK, but you report a file error (which is rare) and yet you don't report
> >> failing to be able to process all the numbers the user wants you to
> >> process. That's a much more likely error. I'd make it be a reason to
> >> return failure from get_lines.
> >
> > I didn't understand this. Do you mean that I should return failure if
> > one of the lines doesn't have a correct format of the input, i.e. there
> > are no numerical characters at the beginning of the line?
>
> No. What do you think your program should do when presented with a file
> of 200 lines all with valid numbers on them?
>
When the program reaches 99 line, it should stop due to the limited space
in the array that can store only 100 elements, hence 0 - 99.
I have added an error message after the if; see below.
<snip>
> >
> > //Parse file data, store only numbers
> > while( fgets(buffer, sizeof(buffer), input_file) != NULL)
> > {
> > line++;
> > index_ch = 0;
> > char *ptr = &buffer[index_ch];
>
> What's the point of ptr? ptr == buffer.
1) I have missed that I still set ptr pointing to the address of a certain
element in the buffer, which I used in a previous program to set ptr
to a certain location in the buffer. It is obviously not needed here.
2) I use an extra pointer variable because, as I have read and heard
many times, it is alway better to work with a duplicate. Is it wrong?
I have deleted ptr.
>
> > char *not_converted = NULL;
> > double number = strtod(ptr, ¬_converted);
> >
> > if (not_converted > ptr && *index_n < NUMBERS)
> > numbers[(*index_n)++] = number;
> > }
> >
> > if (ferror(input_file))
> > {
> > puts("The function detected an error reading a file.");
>
> puts writes to stdout not stderr.
>
> > if(*index_n != 0)
> > fprintf(stderr, "Last input processed was at line '%zu': %s\n", line, buffer);
> > return false;
> > }
> > return true;
> > }
> >
> > /** Find the average **/
>
> You are still not commenting on the fact that this function needs to be
> called with index > 0. I know it's not a complicated function, but that
> fact is more important than "Find the average".
I do - in the main, when I call the average function. Now I am adding the same
comment here, as well.
>
> > double average(const double *numbers, size_t index)
> > {
> > double sum = 0;
> > for(size_t i = 0; i < index; i++)
> > sum += numbers[i];
> >
> > return sum/index;
> > }
>
> Very close now.
>
:)
(I am leaving the errno thing in the program for now; let's get back
to it much later).
#include <stdio.h>
#include <stdlib.h>
#include <ctype.h>
#include <string.h>
#include <stdbool.h>
#include <errno.h>
#define BUFFER_SIZE 100
#define NUMBERS 100
#define TEXT "../files/ex_1.csv"
bool get_lines (FILE *input_file, double *numbers, size_t *index_n);
double average(const double *numbers, size_t index);
int main(int argc, char *argv[])
{
//Check for correct number of arguments
if(argc > 2)
{
fputs("Sorry, the program processes only one file.\n", stderr);
return EXIT_FAILURE;
}
//Determine a file to use
const char *data_file = (argc == 2)? argv[1] : TEXT;
errno = 0;
FILE *fp = fopen(data_file, "r");
if ( fp )
{
double numbers[NUMBERS] = {0};
size_t index_n = 0;
double average_num;
if( !get_lines(fp, numbers, &index_n) )
{
fclose(fp);
return EXIT_FAILURE;
}
//Call function average only when index_n > 0
if(index_n > 0)
{
average_num = average(numbers, index_n);
printf("%.2f\n", average_num);
fclose(fp);
return EXIT_SUCCESS;
}
}
//Couldn't open the file
fprintf(stderr, "%s - %s\n", data_file, errno ? strerror(errno) : "Open failure!");
return EXIT_FAILURE;
}
/** Function to read and process the data
from the file line by line
**/
bool get_lines (FILE *input_file, double *numbers, size_t *index_n)
{
char buffer[BUFFER_SIZE] = "";
size_t index_ch;
size_t line = 0;
//Parse file data, store only numbers
while( fgets(buffer, sizeof(buffer), input_file) != NULL)
{
line++;
index_ch = 0;
char *not_converted = NULL;
double number = strtod(buffer, ¬_converted);
if (not_converted > buffer)
{
if (*index_n < NUMBERS)
numbers[(*index_n)++] = number;
else
fprintf(stderr, "Number of data exceeds capacity; stop at line '%zu'\n", line);
}
}
if (ferror(input_file))
{
if(*index_n != 0)
fprintf(stderr, "Error: last input processed was at line '%zu': %s\n", line, buffer);
fprintf(stderr, "The function detected an error in reading a file; no data has been processed");
return false;
}
return true;
}
/** Function to find the average; called
only if the number of elements is > 0
**/
double average(const double *numbers, size_t index)
{
double sum = 0;
for(size_t i = 0; i < index; i++)
sum += numbers[i];
return sum/index;
}
Done? ) May I move on to the second one?
[toc] | [prev] | [next] | [standalone]
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2017-01-02 04:02 -0800 |
| Message-ID | <4b5aee6f-f5a0-478e-a061-9bc0aa6b94e7@googlegroups.com> |
| In reply to | #100866 |
On Monday, January 2, 2017 at 2:39:52 PM UTC+3, Alla _ wrote: > On Sunday, January 1, 2017 at 10:16:21 PM UTC+3, Ben Bacarisse wrote: After deleting ptr, I have forgotten to delete also index_ch. Done now. I don't know if you find this message before looking at the program and finding my mistake. Sorry if only after.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-01-02 13:48 +0000 |
| Message-ID | <87lgutlgi7.fsf@bsb.me.uk> |
| In reply to | #100868 |
Alla _ <modelling.data@gmail.com> writes: > On Monday, January 2, 2017 at 2:39:52 PM UTC+3, Alla _ wrote: >> On Sunday, January 1, 2017 at 10:16:21 PM UTC+3, Ben Bacarisse wrote: > After deleting ptr, I have forgotten to delete also index_ch. Done now. I don't > know if you find this message before looking at the program and finding > my mistake. Sorry if only after. No I often real and reply in sequence. It's no bother but you'll see I've commented on it. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-01-02 13:47 +0000 |
| Message-ID | <87r34llgjk.fsf@bsb.me.uk> |
| In reply to | #100866 |
Alla _ <modelling.data@gmail.com> writes:
> On Sunday, January 1, 2017 at 10:16:21 PM UTC+3, Ben Bacarisse wrote:
>> Alla _ <modelling.data@gmail.com> writes:
>>
>> > On Sunday, January 1, 2017 at 6:07:14 PM UTC+3, Ben Bacarisse wrote:
>> >> Alla _ <modelling.data@gmail.com> writes:
>> >>
>> > <snip>
>> >> > I need the average function in my program anyway, if you recall the spec
>> >> > I have showed. Also I believe that I might have to deal a few times
>> >> > with these types of functions, which might not have a straightforward
>> >> > solution for success/failure test.
>> >> > Therefore, please, advice me on what approaches can be used here.
>> >>
>> >> I'm not sure what you mean. I suggest postponing that until the
>> >> situation arises so there is a concrete example to discuss.
>> >>
>> > All right. It will come up in my program.
>> >> >> > #include <stdio.h>
>> >> >> > #include <stdlib.h>
>> >> >> > #include <ctype.h>
>> >> >> > #include <string.h>
>> >> >> > #include <stdbool.h>
>> >> >> > #include <errno.h>
>> >> >>
>> >> >> You don't use errno (except for setting it) so you don't need this
>> >> >> file. Include it if and when you do decide you need to use errno.
>> >> > Don't I need this header if I set errno to 0?
>> >>
>> >> Yes, but why are you setting it to 0? Your program would behave exactly
>> >> the same if you deleted that setting and the #include.
>> > I set errno to 0 before calling fopen because doesn't guarantee to
>> > set errno. I have read about it here:
>> > https://www.securecoding.cert.org/confluence/pages/viewpage.action?pageId=6619179
<snip>
>> The handling of errno is very messy. As far as standard C goes, fopen
>> is not known to set errno so the article does not apply.
> This article states exactly this, and explains that it is recommended
> to set errno to 0 before calling fopen.
If you are writing to the POSIX standard rather than just the C
standard. Nothing wrong with that.
> Let's skip all this for now.
It's fine. You are writing a C program for POSIX-conforming systems.
<snip>
>> > I didn't understand this. Do you mean that I should return failure if
>> > one of the lines doesn't have a correct format of the input, i.e. there
>> > are no numerical characters at the beginning of the line?
>>
>> No. What do you think your program should do when presented with a file
>> of 200 lines all with valid numbers on them?
>>
> When the program reaches 99 line, it should stop due to the limited space
> in the array that can store only 100 elements, hence 0 - 99.
> I have added an error message after the if; see below.
OK. I would probably have chosen to report an error and not produce an
average on the grounds that an incorrect average might be used
accidentally even though there would have been an error message. That's
because I'm thinking of this as a utility program so it might well be
run without anyone looking at the screen.
Please don't change this now. This is not about error handling. You
must do *something* but I don't care what.
> <snip>
>> >
>> > //Parse file data, store only numbers
>> > while( fgets(buffer, sizeof(buffer), input_file) != NULL)
>> > {
>> > line++;
>> > index_ch = 0;
Delete along with the declaration. It's not used now.
>> > char *ptr = &buffer[index_ch];
>>
>> What's the point of ptr? ptr == buffer.
> 1) I have missed that I still set ptr pointing to the address of a certain
> element in the buffer, which I used in a previous program to set ptr
> to a certain location in the buffer. It is obviously not needed here.
> 2) I use an extra pointer variable because, as I have read and heard
> many times, it is alway better to work with a duplicate. Is it wrong?
Yes, every universal rule is wrong. But seriously, the rule probably
had some context that's got lost. Here, there is nothing to be gained
by giving buffer a different name and testing against that name instead
of just writing if (not_converted > buffer ...).
<snip>
> if (not_converted > buffer)
> {
> if (*index_n < NUMBERS)
> numbers[(*index_n)++] = number;
> else
> fprintf(stderr, "Number of data exceeds capacity; stop at line '%zu'\n", line);
> }
I like to try to give that sort of message only once because it's more
annoying than helpful to see it repeated for every number after the
first:
if (not_converted > buffer)
{
if (*index_n < NUMBERS)
numbers[*index_n] = number;
else if (*index == NUMBERS)
fprintf(stderr, "Number of data items exceeds capacity at line '%zu'\n",
line);
*index_n += 1;
}
Looking at this code makes me wonder what happened to using Richard's
"bracket everything" style. I'd assume you have decided you like it,
but the inner if has statements without {}s.
<snip>
> /** Function to find the average; called
> only if the number of elements is > 0
> **/
I know this will seem like a tiny quibble but the point is to state the
restrictions on the function, not to say how it is used in this program.
Saying that is called only if the number of elements is > 0 might make a
lazy code reviewer not check; but if it says "must only be called with
index > 0" they might actually check to see that it's true.
> Done? ) May I move on to the second one?
Yes. Any small changes here don't affect moving on. But I am going to
impose a restriction: no new arrays.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2017-01-02 07:21 -0800 |
| Message-ID | <996caeba-f5de-4d2f-baed-1dd57308f151@googlegroups.com> |
| In reply to | #100872 |
On Monday, January 2, 2017 at 4:47:50 PM UTC+3, Ben Bacarisse wrote:
> Alla _ <modelling.data@gmail.com> writes:
>
<snip>
> > Let's skip all this for now.
>
> It's fine. You are writing a C program for POSIX-conforming systems.
>
Doing my best to ignore this statement and not indulge into a further
discussion, but I would love to understand and learn what you mean
here; I will read about it, but for now, please, ignore my curiosity
kindled, yet again, by your comment )
> <snip>
> >> > I didn't understand this. Do you mean that I should return failure if
> >> > one of the lines doesn't have a correct format of the input, i.e. there
> >> > are no numerical characters at the beginning of the line?
> >>
> >> No. What do you think your program should do when presented with a file
> >> of 200 lines all with valid numbers on them?
> >>
> > When the program reaches 99 line, it should stop due to the limited space
> > in the array that can store only 100 elements, hence 0 - 99.
> > I have added an error message after the if; see below.
>
> OK. I would probably have chosen to report an error and not produce an
> average on the grounds that an incorrect average might be used
> accidentally even though there would have been an error message. That's
> because I'm thinking of this as a utility program so it might well be
> run without anyone looking at the screen.
>
> Please don't change this now. This is not about error handling. You
> must do *something* but I don't care what.
Oops, already did, before reaching this sentence ) You know that if
I don't understand something, or, heaven forbid doing it here, disagree
with something :D, I "report" immediately, not changing anything
in the code; but if I understand what's suggested, I do it immediately.
>
<snip>
> > if (not_converted > buffer)
> > {
> > if (*index_n < NUMBERS)
> > numbers[(*index_n)++] = number;
> > else
> > fprintf(stderr, "Number of data exceeds capacity; stop at line '%zu'\n", line);
> > }
>
> I like to try to give that sort of message only once because it's more
> annoying than helpful to see it repeated for every number after the
> first:
>
> if (not_converted > buffer)
> {
> if (*index_n < NUMBERS)
> numbers[*index_n] = number;
> else if (*index == NUMBERS)
> fprintf(stderr, "Number of data items exceeds capacity at line '%zu'\n",
> line);
> *index_n += 1;
> }
I didn't understand this. This is how I read this part:
only if one number was converted, i.e. not_converted > buffer,
and then, only if the number of elements, recorded into
the array thus far, if any, is less than array's bounds,
put the number into the array, and increment the number
of elements.
But, if the number of elements exceeds array bounds,
print the error message, and do nothing; do not increment
the number of elements, because none have been recorded.
If we increment the *index_n in any case when not_converted > buffer,
then it will have an incorrect value.
Also, I have followed your recommendation above, and return false
if the array bounds are exceeded.
if (not_converted > buffer)
{
if (*index_n < NUMBERS)
numbers[(*index_n)++] = number;
else
{
fprintf(stderr, "Number of data exceeds capacity; stop at line '%zu'\n", line);
return false;
}
}
> Looking at this code makes me wonder what happened to using Richard's
> "bracket everything" style. I'd assume you have decided you like it,
> but the inner if has statements without {}s.
Oh, interesting ) From the very first day when I learned about the way all loops
and statements work, I tend to avoid braces when there is only one thing below
the loop and/or if statement - it looks more elegant and clear.
>
> <snip>
> > /** Function to find the average; called
> > only if the number of elements is > 0
> > **/
>
> I know this will seem like a tiny quibble but the point is to state the
> restrictions on the function, not to say how it is used in this program.
> Saying that is called only if the number of elements is > 0 might make a
> lazy code reviewer not check; but if it says "must only be called with
> index > 0" they might actually check to see that it's true.
Aha, I see now what you mean ) Done.
>
> > Done? ) May I move on to the second one?
>
> Yes. Any small changes here don't affect moving on. But I am going to
> impose a restriction: no new arrays.
Of course ) And I don't need new arrays in the second exercise.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-01-02 18:38 +0000 |
| Message-ID | <87a8b9l326.fsf@bsb.me.uk> |
| In reply to | #100877 |
Alla _ <modelling.data@gmail.com> writes:
> On Monday, January 2, 2017 at 4:47:50 PM UTC+3, Ben Bacarisse wrote:
<snip>
>> I like to try to give that sort of message only once because it's more
>> annoying than helpful to see it repeated for every number after the
>> first:
>>
>> if (not_converted > buffer)
>> {
>> if (*index_n < NUMBERS)
>> numbers[*index_n] = number;
>> else if (*index == NUMBERS)
>> fprintf(stderr, "Number of data items exceeds capacity at line '%zu'\n",
>> line);
>> *index_n += 1;
>> }
> I didn't understand this. This is how I read this part:
> only if one number was converted, i.e. not_converted > buffer,
> and then, only if the number of elements, recorded into
> the array thus far, if any, is less than array's bounds,
> put the number into the array, and increment the number
> of elements.
> But, if the number of elements exceeds array bounds,
> print the error message, and do nothing; do not increment
> the number of elements, because none have been recorded.
> If we increment the *index_n in any case when not_converted > buffer,
> then it will have an incorrect value.
Yes, but you can correct that before returning by making sure it is no
more than NUMBERS. But is of not consequence now since you are taking
another approach:
> Also, I have followed your recommendation above, and return false
> if the array bounds are exceeded.
> if (not_converted > buffer)
> {
> if (*index_n < NUMBERS)
> numbers[(*index_n)++] = number;
> else
> {
> fprintf(stderr, "Number of data exceeds capacity; stop at line '%zu'\n", line);
> return false;
> }
> }
Yes, that works when you want to abandon the parse when there is not
enough room, but I'd have to re-visit the whole function to see if it
isn't better put put this test in the while loop. There is a general
rule here: as code grows and changes, always look at the big picture to
see if things have changed in such a way as to make a reorganisation
desirable.
>> Looking at this code makes me wonder what happened to using Richard's
>> "bracket everything" style. I'd assume you have decided you like it,
>> but the inner if has statements without {}s.
> Oh, interesting ) From the very first day when I learned about the way all loops
> and statements work, I tend to avoid braces when there is only one thing below
> the loop and/or if statement - it looks more elegant and clear.
I missed that. I though your were following his (and that of many
others) preference to put {}s round even single statements. I've looked
of the code and you are indeed consistent in this so I should not have
brought it up.
<snip>
--
Ben.
[toc] | [prev] | [next] | [standalone]
Page 7 of 13 — ← Prev page 1 … 5 6 [7] 8 9 … 13 Next page →
Back to top | Article view | comp.lang.c
csiph-web