Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #126692 > unrolled thread
| Started by | G B <gb@gb.com> |
|---|---|
| First post | 2018-02-14 11:47 -0400 |
| Last post | 2018-02-25 20:12 +0000 |
| Articles | 20 on this page of 168 — 30 participants |
Back to article view | Back to comp.lang.c
Text Files G B <gb@gb.com> - 2018-02-14 11:47 -0400
Re: Text Files Ed Prochak <edprochak@gmail.com> - 2018-02-14 08:45 -0800
Re: Text Files Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-02-14 08:47 -0800
Re: Text Files already5chosen@yahoo.com - 2018-02-15 01:17 -0800
Re: Text Files gordonb.ea2mq@burditt.org (Gordon Burditt) - 2018-02-14 11:10 -0600
Re: Text Files "James R. Kuyper" <jameskuyper@verizon.net> - 2018-02-14 12:28 -0500
Re: Text Files jt@toerring.de (Jens Thoms Toerring) - 2018-02-14 21:07 +0000
Re: Text Files Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2018-02-14 15:31 -0700
Re: Text Files Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-02-15 06:59 +0000
Re: Text Files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-15 10:20 +0000
Re: Text Files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-14 22:51 +0000
Re: Text Files David Brown <david.brown@hesbynett.no> - 2018-02-15 11:04 +0100
Re: Text Files Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-02-15 06:16 -0800
Re: Text Files "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2018-02-15 22:22 +0800
Re: Text Files David Brown <david.brown@hesbynett.no> - 2018-02-15 15:58 +0100
Re: Text Files bartc <bc@freeuk.com> - 2018-02-15 16:31 +0000
Re: Text Files David Brown <david.brown@hesbynett.no> - 2018-02-15 21:31 +0100
Re: Text Files bartc <bc@freeuk.com> - 2018-02-15 21:21 +0000
Re: Text Files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-15 22:17 +0000
Re: Text Files bartc <bc@freeuk.com> - 2018-02-15 23:36 +0000
Re: Text Files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-15 23:48 +0000
Re: Text Files David Brown <david.brown@hesbynett.no> - 2018-02-16 10:09 +0100
Re: Text Files bartc <bc@freeuk.com> - 2018-02-16 12:57 +0000
Re: Text Files David Brown <david.brown@hesbynett.no> - 2018-02-16 15:50 +0100
Re: Text Files bartc <bc@freeuk.com> - 2018-02-16 15:50 +0000
Re: Text Files David Brown <david.brown@hesbynett.no> - 2018-02-16 17:07 +0100
Re: Text Files bartc <bc@freeuk.com> - 2018-02-16 20:44 +0000
Re: Text Files Ian Collins <ian-news@hotmail.com> - 2018-02-17 11:22 +1300
Re: Text Files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-16 17:48 +0000
Re: Text Files GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-02-16 17:06 +0100
Re: Text Files Ian Collins <ian-news@hotmail.com> - 2018-02-17 11:10 +1300
Re: Text Files supercat@casperkitty.com - 2018-02-16 14:48 -0800
Re: Text Files Keith Thompson <kst-u@mib.org> - 2018-02-16 15:14 -0800
Re: Text Files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-16 23:25 +0000
Re: Text Files supercat@casperkitty.com - 2018-02-16 15:50 -0800
Re: Text Files already5chosen@yahoo.com - 2018-02-16 07:19 -0800
Re: Text Files David Brown <david.brown@hesbynett.no> - 2018-02-16 17:13 +0100
Re: Text Files Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-02-19 17:55 +0000
Re: Text Files David Brown <david.brown@hesbynett.no> - 2018-02-19 19:14 +0100
Re: Text Files Keith Thompson <kst-u@mib.org> - 2018-02-19 11:48 -0800
Re: Text Files Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-02-16 08:14 -0800
Re: Text Files Robert Wessel <robertwessel2@yahoo.com> - 2018-02-17 18:32 -0600
Re: Text Files jacobnavia <jacob@jacob.remcomp.fr> - 2018-02-15 22:57 +0100
Re: Text Files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-15 22:58 +0000
Re: Text Files bartc <bc@freeuk.com> - 2018-02-16 00:19 +0000
Re: Text Files bartc <bc@freeuk.com> - 2018-02-16 02:26 +0000
Re: Text Files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-16 02:57 +0000
Re: Text Files asetofsymbols@gmail.com - 2018-02-16 00:21 -0800
Re: Text Files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-16 11:30 +0000
Re: Text Files David Brown <david.brown@hesbynett.no> - 2018-02-16 10:36 +0100
Re: Text Files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-16 11:36 +0000
Re: Text Files David Brown <david.brown@hesbynett.no> - 2018-02-16 13:10 +0100
Re: Text Files bartc <bc@freeuk.com> - 2018-02-16 12:25 +0000
Re: Text Files Ike Naar <ike@iceland.freeshell.org> - 2018-03-06 19:33 +0000
Re: Text Files bartc <bc@freeuk.com> - 2018-03-06 20:55 +0000
Re: Text Files Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-02-16 04:42 -0800
Re: Text Files David Brown <david.brown@hesbynett.no> - 2018-02-16 16:58 +0100
Re: Text Files bartc <bc@freeuk.com> - 2018-02-16 20:02 +0000
Re: Text Files David Brown <david.brown@hesbynett.no> - 2018-02-16 21:43 +0100
Re: Text Files Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-02-17 04:01 -0800
Re: Text Files bartc <bc@freeuk.com> - 2018-02-17 13:10 +0000
Re: Text Files Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-02-17 05:27 -0800
Re: Text Files bartc <bc@freeuk.com> - 2018-02-17 14:20 +0000
Re: Text Files Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2018-02-16 09:04 -0700
Re: Text Files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-16 14:31 +0000
Re: Text Files Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-02-16 06:42 -0800
Re: Text Files bartc <bc@freeuk.com> - 2018-02-16 14:58 +0000
Re: Text Files Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-02-16 07:23 -0800
Re: Text Files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-16 15:24 +0000
Re: Text Files Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-02-16 04:13 -0800
Re: Text Files Siri Cruise <chine.bleu@yahoo.com> - 2018-02-16 04:29 -0800
Re: Text Files Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-02-20 16:41 +0000
Re: Text Files Siri Cruise <chine.bleu@yahoo.com> - 2018-02-20 09:39 -0800
Re: Text Files Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-02-20 19:16 +0000
Re: Text Files bartc <bc@freeuk.com> - 2018-02-15 12:46 +0000
Re: Text Files GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-02-15 14:52 +0100
Re: Text Files Anton Shepelev <anton.txt@g{oogle}mail.com> - 2018-02-15 17:07 +0300
Re: Text Files bartc <bc@freeuk.com> - 2018-02-15 14:23 +0000
Re: Text Files Anton Shepelev <anton.txt@g{oogle}mail.com> - 2018-02-15 18:52 +0300
Re: Text Files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-15 14:39 +0000
Re: Text Files bartc <bc@freeuk.com> - 2018-02-15 15:43 +0000
Re: Text Files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-15 20:32 +0000
Re: Text Files bartc <bc@freeuk.com> - 2018-02-15 22:06 +0000
Re: Text Files GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-02-15 23:12 +0100
Re: Text Files Keith Thompson <kst-u@mib.org> - 2018-02-15 15:12 -0800
Re: Text Files bartc <bc@freeuk.com> - 2018-02-15 23:43 +0000
Re: Text Files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-15 23:54 +0000
Re: Text Files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-15 23:35 +0000
Re: Text Files Tim Rentsch <txr@alumni.caltech.edu> - 2018-02-16 17:07 -0800
Re: Text Files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-17 02:38 +0000
Re: Text Files Ian Collins <ian-news@hotmail.com> - 2018-02-17 17:26 +1300
Re: Text Files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-17 11:22 +0000
Re: Text Files bartc <bc@freeuk.com> - 2018-02-17 12:07 +0000
Re: Text Files Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-02-17 04:17 -0800
Re: Text Files Anton Shepelev <anton.txt@gmail.com> - 2018-02-17 16:25 +0300
Re: Text Files Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-02-17 07:35 -0800
Re: Text Files GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-02-17 15:24 +0100
Re: Text Files Ian Collins <ian-news@hotmail.com> - 2018-02-18 11:10 +1300
Re: Text Files Tim Rentsch <txr@alumni.caltech.edu> - 2018-02-19 12:05 -0800
Re: Text Files already5chosen@yahoo.com - 2018-02-19 15:32 -0800
Re: Text Files Tim Rentsch <txr@alumni.caltech.edu> - 2018-02-21 10:34 -0800
Re: Text Files already5chosen@yahoo.com - 2018-02-21 15:35 -0800
Re: Text Files bartc <bc@freeuk.com> - 2018-02-22 00:11 +0000
Re: Text Files Robert Wessel <robertwessel2@yahoo.com> - 2018-02-21 18:26 -0600
Re: Text Files Tim Rentsch <txr@alumni.caltech.edu> - 2018-02-21 21:39 -0800
Re: Text Files Robert Wessel <robertwessel2@yahoo.com> - 2018-02-23 03:08 -0600
Re: Text Files supercat@casperkitty.com - 2018-02-23 16:16 -0800
Re: Text Files Keith Thompson <kst-u@mib.org> - 2018-02-23 16:46 -0800
Re: Text Files Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-02-24 02:49 -0800
Re: Text Files asetofsymbols@gmail.com - 2018-02-24 05:16 -0800
Re: Text Files "F. Russell" <fr@random.info> - 2018-02-24 14:35 +0000
Re: Text Files Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2018-02-24 08:48 -0700
Re: Text Files supercat@casperkitty.com - 2018-02-25 15:09 -0800
Re: Text Files Keith Thompson <kst-u@mib.org> - 2018-02-25 15:54 -0800
Re: Text Files supercat@casperkitty.com - 2018-02-26 11:04 -0800
Re: Text Files Keith Thompson <kst-u@mib.org> - 2018-02-26 11:52 -0800
Re: Text Files supercat@casperkitty.com - 2018-02-26 14:12 -0800
Re: Text Files Keith Thompson <kst-u@mib.org> - 2018-02-26 14:40 -0800
Re: Text Files already5chosen@yahoo.com - 2018-02-22 04:58 -0800
Re: Text Files Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-02-22 05:33 -0800
Re: Text Files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-22 13:59 +0000
Re: Text Files Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-02-22 07:24 -0800
Re: Text Files supercat@casperkitty.com - 2018-02-20 12:14 -0800
Re: Text Files David Brown <david.brown@hesbynett.no> - 2018-02-15 21:37 +0100
Re: Text Files bartc <bc@freeuk.com> - 2018-02-15 21:34 +0000
Re: Text Files Keith Thompson <kst-u@mib.org> - 2018-02-15 14:15 -0800
Re: Text Files David Brown <david.brown@hesbynett.no> - 2018-02-16 10:47 +0100
Re: Text Files "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2018-02-15 22:20 +0800
Re: Text Files "F. Russell" <fr@random.info> - 2018-02-15 15:24 +0000
Re: Text Files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-15 16:05 +0000
Re: Text Files "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2018-02-16 00:22 +0800
Re: Text Files Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2018-02-15 13:35 -0700
Re: Text Files Anton Shepelev <anton.txt@gmail.com> - 2018-02-25 00:13 +0300
Re: Text Files bartc <bc@freeuk.com> - 2018-02-24 21:24 +0000
Re: Text Files Anton Shepelev <anton.txt@gmail.com> - 2018-02-25 14:55 +0300
Re: Text Files bartc <bc@freeuk.com> - 2018-02-25 13:00 +0000
Re: Text Files Real Troll <Real.Troll@Trolls.com> - 2018-02-24 17:35 -0400
Re: Text Files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-24 21:36 +0000
Re: Text Files Real Troll <Real.Troll@Trolls.com> - 2018-02-24 17:45 -0400
Re: Text Files Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-02-24 22:51 +0000
Re: Text Files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-24 23:56 +0000
Re: Text Files bartc <bc@freeuk.com> - 2018-02-25 00:14 +0000
Re: Text Files bartc <bc@freeuk.com> - 2018-02-25 00:22 +0000
Re: Text Files Anton Shepelev <anton.txt@gmail.com> - 2018-02-25 15:16 +0300
Re: Text Files Keith Thompson <kst-u@mib.org> - 2018-02-25 15:20 -0800
Re: Text Files Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2018-02-25 20:27 -0700
Re: Text Files gazelle@shell.xmission.com (Kenny McCormack) - 2018-02-26 06:19 +0000
Re: Text Files Anton Shepelev <anton.txt@g{oogle}mail.com> - 2018-02-26 15:35 +0300
Re: Text Files Reinhardt Behm <rbehm@hushmail.com> - 2018-02-26 20:53 +0800
Grammar Patrol (Was: Text Files) gazelle@shell.xmission.com (Kenny McCormack) - 2018-02-26 17:54 +0000
Re: Text Files Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-02-26 15:27 +0000
Re: Text Files Anton Shepelev <anton.txt@g{oogle}mail.com> - 2018-02-26 18:50 +0300
Re: Text Files Keith Thompson <kst-u@mib.org> - 2018-02-26 09:26 -0800
Re: Text Files scott@slp53.sl.home (Scott Lurndal) - 2018-02-26 19:46 +0000
Re: Text Files David Brown <david.brown@hesbynett.no> - 2018-02-27 09:04 +0100
Re: Text Files already5chosen@yahoo.com - 2018-02-27 00:56 -0800
Re: Text Files Ian Collins <ian-news@hotmail.com> - 2018-02-27 22:07 +1300
Re: Text Files David Brown <david.brown@hesbynett.no> - 2018-02-27 14:37 +0100
Re: Text Files already5chosen@yahoo.com - 2018-02-27 07:38 -0800
Re: Text Files supercat@casperkitty.com - 2018-02-27 09:18 -0800
Re: Text Files David Brown <david.brown@hesbynett.no> - 2018-02-27 10:15 +0100
Re: Text Files Keith Thompson <kst-u@mib.org> - 2018-02-27 08:53 -0800
Re: Text Files Tim Rentsch <txr@alumni.caltech.edu> - 2018-02-26 23:14 -0800
Re: Text Files Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2018-02-26 08:32 -0700
Re: Text Files Keith Thompson <kst-u@mib.org> - 2018-02-26 09:17 -0800
Re: Text Files Tim Rentsch <txr@alumni.caltech.edu> - 2018-02-26 22:55 -0800
Re: Text Files Anton Shepelev <anton.txt@gmail.com> - 2018-02-25 15:02 +0300
Re: Text Files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-25 20:12 +0000
Page 1 of 9 [1] 2 3 4 5 6 7 8 9 Next page →
| From | G B <gb@gb.com> |
|---|---|
| Date | 2018-02-14 11:47 -0400 |
| Subject | Text Files |
| Message-ID | <5a8459d1$0$707$14726298@news.sunsite.dk> |
If you have a text file of numbers, what is the best way to read numbers
line by line and do some tests on numbers for that line before moving to
the next line? for example the text file might be:
07 23 36 52 53 57
02 04 09 15 25 51
02 03 11 14 18 21
22 22 23 28 33 54
16 19 26 48 58 58
04 28 42 48 56 57
05 13 18 21 45 46
05 22 23 29 31 58
01 03 07 14 16 55
06 09 40 43 46 48
I want to read numbers: a, b, c, d, e, f and do some tests on it and
then go to the next line and do the same.
In some languages, it was possible to do something like this:
While Not EOF (Infile) Do
Begin
ReadLn (InFile, a, b, c, d, e, f);
// Write test code here
End;
I want something similar in C or C++.
Thanks.
[toc] | [next] | [standalone]
| From | Ed Prochak <edprochak@gmail.com> |
|---|---|
| Date | 2018-02-14 08:45 -0800 |
| Message-ID | <90c78541-6490-4de8-93c2-0a3ba86945d0@googlegroups.com> |
| In reply to | #126692 |
On Wednesday, February 14, 2018 at 10:46:41 AM UTC-5, G B wrote: > If you have a text file of numbers, what is the best way to read numbers > line by line and do some tests on numbers for that line before moving to > the next line? for example the text file might be: > > 07 23 36 52 53 57 > 02 04 09 15 25 51 > 02 03 11 14 18 21 > 22 22 23 28 33 54 > 16 19 26 48 58 58 > 04 28 42 48 56 57 > 05 13 18 21 45 46 > 05 22 23 29 31 58 > 01 03 07 14 16 55 > 06 09 40 43 46 48 > > I want to read numbers: a, b, c, d, e, f and do some tests on it and > then go to the next line and do the same. > > In some languages, it was possible to do something like this: > > While Not EOF (Infile) Do > Begin > ReadLn (InFile, a, b, c, d, e, f); > // Write test code here > End; > > I want something similar in C or C++. > > Thanks. have you tried looking at the language features? You have to do more of the programming work yourself for this operation in C. There are functions and features to help (e.g., atoi(), strtok(), getchar()) In contrast, scripting languages similar to the example you gave, still need some formatting information (even if the field separator has a default value). And those languages use typeless variables, so you really do not have numbers yet, not until you use the variable as a number. Then those languages usually do a best guess conversion based on the context. Ed
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2018-02-14 08:47 -0800 |
| Message-ID | <e207e440-3105-43c0-bc6f-11f1c5b596f3@googlegroups.com> |
| In reply to | #126692 |
On Wednesday, February 14, 2018 at 3:46:41 PM UTC, G B wrote: > If you have a text file of numbers, what is the best way to read numbers > line by line and do some tests on numbers for that line before moving to > the next line? for example the text file might be: > > 07 23 36 52 53 57 > 02 04 09 15 25 51 > 02 03 11 14 18 21 > 22 22 23 28 33 54 > 16 19 26 48 58 58 > 04 28 42 48 56 57 > 05 13 18 21 45 46 > 05 22 23 29 31 58 > 01 03 07 14 16 55 > 06 09 40 43 46 48 > > I want to read numbers: a, b, c, d, e, f and do some tests on it and > then go to the next line and do the same. > > In some languages, it was possible to do something like this: > > While Not EOF (Infile) Do > Begin > ReadLn (InFile, a, b, c, d, e, f); > // Write test code here > End; > > I want something similar in C or C++. > Use fgets() to read in a line, then sscanf() to read the numbers if the number of values per line is known at compile time. Be sure to check the return value - this will give good enough error handling for most purposes. If the number of values per line is not known at compile time, yyu can build a little parser on top of isspace and strtol. This can also give you better error handling, for example if lines must contain two digit values separated by single spaces.
[toc] | [prev] | [next] | [standalone]
| From | already5chosen@yahoo.com |
|---|---|
| Date | 2018-02-15 01:17 -0800 |
| Message-ID | <78806341-f235-4321-9d55-194ef7016e56@googlegroups.com> |
| In reply to | #126694 |
On Wednesday, February 14, 2018 at 6:47:26 PM UTC+2, Malcolm McLean wrote: > On Wednesday, February 14, 2018 at 3:46:41 PM UTC, G B wrote: > > If you have a text file of numbers, what is the best way to read numbers > > line by line and do some tests on numbers for that line before moving to > > the next line? for example the text file might be: > > > > 07 23 36 52 53 57 > > 02 04 09 15 25 51 > > 02 03 11 14 18 21 > > 22 22 23 28 33 54 > > 16 19 26 48 58 58 > > 04 28 42 48 56 57 > > 05 13 18 21 45 46 > > 05 22 23 29 31 58 > > 01 03 07 14 16 55 > > 06 09 40 43 46 48 > > > > I want to read numbers: a, b, c, d, e, f and do some tests on it and > > then go to the next line and do the same. > > > > In some languages, it was possible to do something like this: > > > > While Not EOF (Infile) Do > > Begin > > ReadLn (InFile, a, b, c, d, e, f); > > // Write test code here > > End; > > > > I want something similar in C or C++. > > > Use fgets() to read in a line, then sscanf() to read the numbers if > the number of values per line is known at compile time. Be sure to > check the return value - this will give good enough error handling > for most purposes. > If the number of values per line is not known at compile time, > yyu can build a little parser on top of isspace and strtol. This > can also give you better error handling, for example if lines must > contain two digit values separated by single spaces. fgets() as a first step is a good suggestion. sscanf() - I don't like it. IMHO, fgets() followed by strtol() loop get more control and reduce chances of bugs. In my own practice, sscanf is semi-depricated (contrast with scanf()/fscanf() that are completely forbidden). All that matter only if you want to produce relatively detailed diagnostic message in case, when format of the input file does not match the expectations. If you just want print "Wrong format, you moron!!! Go away!!!!!", then other methods are also sufficient. Now, in extremely rare situation when the speed of conversion is critical and the format is very well understood and unlikely to change, it could be worse to do your own char-by-char conversion instead of strtol(). In even more extreme case of "every cycle matters" you may want to use fread() or read() instead of fgets() and to detect line boundaries by yourself. The last approach has additional advantage that you don't have to guess the maximal length of input line. But the implementation is certainly less simple than other variants and requires more attention to details.
[toc] | [prev] | [next] | [standalone]
| From | gordonb.ea2mq@burditt.org (Gordon Burditt) |
|---|---|
| Date | 2018-02-14 11:10 -0600 |
| Message-ID | <FKKdnUCJaNPj8BnHnZ2dnUU7-RvNnZ2d@posted.internetamerica> |
| In reply to | #126692 |
> If you have a text file of numbers, what is the best way to read numbers
> line by line and do some tests on numbers for that line before moving to
> the next line? for example the text file might be:
>
> 07 23 36 52 53 57
> 02 04 09 15 25 51
> 02 03 11 14 18 21
> 22 22 23 28 33 54
> 16 19 26 48 58 58
> 04 28 42 48 56 57
> 05 13 18 21 45 46
> 05 22 23 29 31 58
> 01 03 07 14 16 55
> 06 09 40 43 46 48
Lottery numbers, sorted to be in increasing order? Maybe not, you've
got duplicate numbers in there. Most lotteries won't have duplicates.
> I want to read numbers: a, b, c, d, e, f and do some tests on it and
> then go to the next line and do the same.
If you can come up with a reasonable maximum input line length,
something like this would work:
#define I_HOPE_THIS_IS_BIG_ENOUGH 1024
/* Since the example test data has a maximum of 35 characters per line */
/* including the \n and \0, 1024 should be plenty */
char buffer[I_HOPE_THIS_IS_BIG_ENOUGH];
int a,b,c,d,e,f;
while(fgets(buffer, sizeof(buffer), stdin) != EOF) {
if (sscanf(buffer, "%d%d%d%d%d%d", &a, &b, &c, &d, &e, &f) != 6) {
... error, some numbers missing ...;
} else {
... You got all the numbers, do something with them ...;
}
}
Some people are not going to like this because it doesn't handle
the case of an overly-long line properly, nor does it handle numbers
larger in magnitude than what the type you select will hold.
(Checking the number after conversion won't catch the problem.)
However, it will NOT overflow buffers and it does detect missing
numbers (but not extra numbers) on a line. If there is an overly
long line which gets split, then one or both pieces will have at
least one missing number, unless there were extras on the long line.
If you're willing to accept restrictions on the data input (including
line length and the range of values that can be input), and that
you'll get garbage if you violate the rules, then this will work.
If you want every error caught, it's harder.
If you really want to check each number for overflow and illegal
characters, you can parse the line yourself once you have it in
buffer, or you could use strtol() and the pointer it provides
to what's after the number..
Unlike scanf() or fscanf(), it won't handle a missing number by
using one from the next line, thereby getting out of sync for the
rest of the file (which from the description of the problem, I
expect that would be more making things worse than solving
a problem).
> In some languages, it was possible to do something like this:
>
> While Not EOF (Infile) Do
> Begin
> ReadLn (InFile, a, b, c, d, e, f);
> // Write test code here
> End;
[toc] | [prev] | [next] | [standalone]
| From | "James R. Kuyper" <jameskuyper@verizon.net> |
|---|---|
| Date | 2018-02-14 12:28 -0500 |
| Message-ID | <b61a7abc-5fbb-1425-b0d0-bcf4b418bb55@verizon.net> |
| In reply to | #126692 |
On 02/14/2018 10:47 AM, G B wrote:
> If you have a text file of numbers, what is the best way to read numbers
> line by line and do some tests on numbers for that line before moving to
> the next line? for example the text file might be:
>
> 07 23 36 52 53 57
> 02 04 09 15 25 51
> 02 03 11 14 18 21
> 22 22 23 28 33 54
> 16 19 26 48 58 58
> 04 28 42 48 56 57
> 05 13 18 21 45 46
> 05 22 23 29 31 58
> 01 03 07 14 16 55
> 06 09 40 43 46 48
>
> I want to read numbers: a, b, c, d, e, f and do some tests on it and
> then go to the next line and do the same.
>
> In some languages, it was possible to do something like this:
>
> While Not EOF (Infile) Do
> Begin
> ReadLn (InFile, a, b, c, d, e, f);
> // Write test code here
> End;
>
> I want something similar in C or C++.
If you want C++ answers, you should have cross-posted to comp.lang.c++;
there might not have been anyone here willing and able to give you a
good C++ answer. I'm willing, but the answer I give you below might not
be as good as the one that a more experienced C++ programmer might have
given you.
In C, you can use fgets() to read the line into a buffer, and then use
sscanf() to parse out the individual numbers. If you try to use scanf()
directly, it doesn't distinguish between new lines and other white space
characters, which can produce some very confusing error symptoms if any
line of your input data is incorrectly formatted.
Note: sscanf() has undefined behavior if any input number has a value
too big to be represented in the corresponding type. If you want better
error handling, using the appropriate member of the strto*() family will
provide it, at the cost of being somewhat more complicated to use.
I know a lot about C++, but have relatively little experience with it,
so there may be a better way to do this, but this is what I came up with:
while(cin)
{
std::string line;
std::getline(std::cin, line);
std::stringstream lss(line);
lss >> a >> b >> c >> d >> e >> f;
...
Those extractors have their behavior defined in terms of the C functions
from the strto*() family, so you're doing essentially the same thing as
the C code I implicitly described, but with simpler syntax (and no
explicit upper limit on the line length). However, to get the full
advantage of the improved error handling provided by the strto*()
family, the C++ version would have to check for lss.fail() after
extracting each number.
[toc] | [prev] | [next] | [standalone]
| From | jt@toerring.de (Jens Thoms Toerring) |
|---|---|
| Date | 2018-02-14 21:07 +0000 |
| Message-ID | <fejmpdFe3s5U1@mid.uni-berlin.de> |
| In reply to | #126692 |
G B <gb@gb.com> wrote:
> If you have a text file of numbers, what is the best way to read numbers
> line by line and do some tests on numbers for that line before moving to
> the next line? for example the text file might be:
> 07 23 36 52 53 57
> 02 04 09 15 25 51
> 02 03 11 14 18 21
> 22 22 23 28 33 54
> 16 19 26 48 58 58
> 04 28 42 48 56 57
> 05 13 18 21 45 46
> 05 22 23 29 31 58
> 01 03 07 14 16 55
> 06 09 40 43 46 48
> I want to read numbers: a, b, c, d, e, f and do some tests on it and
> then go to the next line and do the same.
Simplest thing to do in this case (if you can be sure that
each line contains 6 nmbers and you don't have empty lines)
would be something like
FILE *fp = fopen("my_numbers.txt", "r");
int a, b, c, d, e, f;
while (fscanf(fp, "%d%d%d%d%d%d", &a, &b, &c, &d, &e, &f) == 6) {
/* do tests here */
}
fclose(fp);
If you've got to be more cautions about the sanity of the
file's content things get more interesting. And if it's the
"best" way is quite another question, since it would depend
on whay you define as "best";-)
Regards, Jens
--
\ Jens Thoms Toerring ___ jt@toerring.de
\__________________________ http://toerring.de
[toc] | [prev] | [next] | [standalone]
| From | Joe Pfeiffer <pfeiffer@cs.nmsu.edu> |
|---|---|
| Date | 2018-02-14 15:31 -0700 |
| Message-ID | <1befln6w57.fsf@pfeifferfamily.net> |
| In reply to | #126692 |
ram@zedat.fu-berlin.de (Stefan Ram) writes: > G B <gb@gb.com> writes: >>the next line? for example the text file might be: >>07 23 36 52 53 57 > > An example does not suffice to write a parser. > One needs a /grammar/ for the input. <snip> For sufficiently simple grammars, an English description and an example is a fine specification, especially when he's looking for ideas on how to write it and not writing a spec for somebody else. Assuming the example is accurate, the fgets()/sscanf() sorts of answers people are suggesting are just fine. There's no reason to make it more complicated than necessary.
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2018-02-15 06:59 +0000 |
| Message-ID | <slrnp8abub.eu5.grahn+nntp@frailea.sa.invalid> |
| In reply to | #126707 |
On Wed, 2018-02-14, Joe Pfeiffer wrote: > ram@zedat.fu-berlin.de (Stefan Ram) writes: > >> G B <gb@gb.com> writes: >>>the next line? for example the text file might be: >>>07 23 36 52 53 57 >> >> An example does not suffice to write a parser. >> One needs a /grammar/ for the input. > > <snip> > > For sufficiently simple grammars, an English description and an example > is a fine specification, especially when he's looking for ideas on how > to write it and not writing a spec for somebody else. I agree. I'd supplement the example with something like: "Six whitespace-separated unsigned decimal numbers per line; extra whitespace at the beginning and end of line is also fine." And possibly something about the range of the numbers. > Assuming the example is accurate, the fgets()/sscanf() sorts of answers > people are suggesting are just fine. There's no reason to make it more > complicated than necessary. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2018-02-15 10:20 +0000 |
| Message-ID | <87606ya719.fsf@bsb.me.uk> |
| In reply to | #126711 |
Jorgen Grahn <grahn+nntp@snipabacken.se> writes: > On Wed, 2018-02-14, Joe Pfeiffer wrote: >> ram@zedat.fu-berlin.de (Stefan Ram) writes: >> >>> G B <gb@gb.com> writes: >>>>the next line? for example the text file might be: >>>>07 23 36 52 53 57 >>> >>> An example does not suffice to write a parser. >>> One needs a /grammar/ for the input. >> >> <snip> >> >> For sufficiently simple grammars, an English description and an example >> is a fine specification, especially when he's looking for ideas on how >> to write it and not writing a spec for somebody else. > > I agree. I'd supplement the example with something like: > > "Six whitespace-separated unsigned decimal numbers per line; extra > whitespace at the beginning and end of line is also fine." > > And possibly something about the range of the numbers. The example gave lots of numbers so we can be almost 100% sure that they are all supposed to be integers (in fact all positive integers) but it would probably be better to explicitly rule out floating point numbers. It's surprisingly easy to unintentionally make specifications either too restrictive or too permissive, but I agree that a grammar is overkill in this case. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2018-02-14 22:51 +0000 |
| Message-ID | <87mv0b9ocq.fsf@bsb.me.uk> |
| In reply to | #126692 |
G B <gb@gb.com> writes: > If you have a text file of numbers, what is the best way to read > numbers line by line and do some tests on numbers for that line before > moving to the next line? You've had some C answers but I'd raise another question -- why C? There are many languages designed for rapid data analysis and though you have learn one (or more), I've found the effort to be well worth it in the long run. If this is just a programming exercise, then fine, but if it's "for real" it's very unlikely that C is going to be the tool for this job. for serious numerical work, Fortran is probably still the top dog -- you can read and print the data you show in a single input or output operation in Fortran, but for more general work, AWK, Perl, R and Python (especially numpy) are all widely used. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-02-15 11:04 +0100 |
| Message-ID | <p63lup$l42$2@dont-email.me> |
| In reply to | #126708 |
On 14/02/18 23:51, Ben Bacarisse wrote: > G B <gb@gb.com> writes: > >> If you have a text file of numbers, what is the best way to read >> numbers line by line and do some tests on numbers for that line before >> moving to the next line? > > You've had some C answers but I'd raise another question -- why C? You beat me to it. C is a fine language for some tasks, but certainly not for everything. > There are many languages designed for rapid data analysis and though you > have learn one (or more), I've found the effort to be well worth it in > the long run. > > If this is just a programming exercise, then fine, but if it's "for > real" it's very unlikely that C is going to be the tool for this job. > > for serious numerical work, Fortran is probably still the top dog -- you > can read and print the data you show in a single input or output > operation in Fortran, but for more general work, AWK, Perl, R and Python > (especially numpy) are all widely used. > > <snip> >
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2018-02-15 06:16 -0800 |
| Message-ID | <61abd898-60fc-4290-823a-a7ddd264700e@googlegroups.com> |
| In reply to | #126715 |
On Thursday, February 15, 2018 at 10:04:15 AM UTC, David Brown wrote: > On 14/02/18 23:51, Ben Bacarisse wrote: > > G B <gb@gb.com> writes: > > > >> If you have a text file of numbers, what is the best way to read > >> numbers line by line and do some tests on numbers for that line before > >> moving to the next line? > > > > You've had some C answers but I'd raise another question -- why C? > > You beat me to it. C is a fine language for some tasks, but certainly > not for everything. > It's often easier to write something in a high level scripting language rather than C. However typically programs are less useful in that form - a file written in a conservative subset of ANSI C89 is usable practically anywhere that native code can be run. A script is not so easy to run on a different platform, or to integrate into a larger system.
[toc] | [prev] | [next] | [standalone]
| From | "Mr. Man-wai Chang" <toylet.toylet@gmail.com> |
|---|---|
| Date | 2018-02-15 22:22 +0800 |
| Message-ID | <p6452h$g7$2@toylet.eternal-september.org> |
| In reply to | #126724 |
On 15/2/2018 22:16, Malcolm McLean wrote: > It's often easier to write something in a high level scripting language > rather than C. However typically programs are less useful in that form - > a file written in a conservative subset of ANSI C89 is usable > practically anywhere that native code can be run. A script is not > so easy to run on a different platform, or to integrate into a larger > system. You could use C-based text/database manipulation libraries, e.g., Codebase, Harbour Project, xHarbour .... ! ;) -- @~@ Remain silent! Drink, Blink, Stretch! Live long and prosper!! / v \ Simplicity is Beauty! /( _ )\ May the Force and farces be with you! ^ ^ (x86_64 Ubuntu 9.10) Linux 2.6.39.3 不借貸! 不詐騙! 不援交! 不打交! 不打劫! 不自殺! 請考慮綜援 (CSSA): http://www.swd.gov.hk/tc/index/site_pubsvc/page_socsecu/sub_addressesa
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-02-15 15:58 +0100 |
| Message-ID | <p64768$gpj$1@dont-email.me> |
| In reply to | #126724 |
On 15/02/18 15:16, Malcolm McLean wrote:
> On Thursday, February 15, 2018 at 10:04:15 AM UTC, David Brown wrote:
>> On 14/02/18 23:51, Ben Bacarisse wrote:
>>> G B <gb@gb.com> writes:
>>>
>>>> If you have a text file of numbers, what is the best way to read
>>>> numbers line by line and do some tests on numbers for that line before
>>>> moving to the next line?
>>>
>>> You've had some C answers but I'd raise another question -- why C?
>>
>> You beat me to it. C is a fine language for some tasks, but certainly
>> not for everything.
>>
> It's often easier to write something in a high level scripting language
> rather than C. However typically programs are less useful in that form -
> a file written in a conservative subset of ANSI C89 is usable
> practically anywhere that native code can be run. A script is not
> so easy to run on a different platform, or to integrate into a larger
> system.
>
Suppose, for example, these numbers are in a file "test.txt" and you
want to find the sum of the numbers on each line. In Python, this can
be done as:
for ln in file("test.txt").readlines() :
nums = [int(x) for x in ln.split()]
print(sums(nums))
That is all you need. No faffing about with fgets, or which strtol
function to use. No worrying about sizes, overflows, or how big your
buffers should be. No concerns about line endings, or if the file uses
tabs or spaces. No worries about whether MS in their infinite wisdom
have decided to deprecate the C standard library functions you want to
use, so that you have to figure out different compiler switches to use.
It is not going to work in a little embedded system - but you don't do
this kind of task on a little embedded system. It is not going to work
on a PC from 1999, before Python 2 came out - but this is 2018, not 1999.
This kind of script /is/ easy to run on almost every platform. The
exception to ease-of-use is, as always, Windows - but it is still /far/
easier to run a Python script on Windows than to deal with a C compiler.
Python has not replaced C as the sensible choice of language for
manipulating text files like this - it replaced Perl, awk and TCL which
had already replaced C decades ago.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-02-15 16:31 +0000 |
| Message-ID | <TBihC.260036$w26.87474@fx47.am4> |
| In reply to | #126729 |
On 15/02/2018 14:58, David Brown wrote:
> On 15/02/18 15:16, Malcolm McLean wrote:
>> It's often easier to write something in a high level scripting language
>> rather than C. However typically programs are less useful in that form -
>> a file written in a conservative subset of ANSI C89 is usable
>> practically anywhere that native code can be run. A script is not
>> so easy to run on a different platform, or to integrate into a larger
>> system.
>>
>
> Suppose, for example, these numbers are in a file "test.txt" and you
> want to find the sum of the numbers on each line. In Python, this can
> be done as:
>
> for ln in file("test.txt").readlines() :
> nums = [int(x) for x in ln.split()]
print(sums(nums))
>
> That is all you need.
You need file iterators. List comprehensions. Explicit string processing
and string to int conversions.
So advanced features combined with crude string hacking. A poor example
of Python I think. Note that your example didn't work, I had to use this:
file=open("input")
for ln in file.readlines() :
nums = [int(x) for x in ln.split()]
print(sum(nums))
file.close()
Here it is in my script language, but reading 6 numbers per line:
file:=openfile("input")
while not eof(file) do
readln @file,a,b,c,d,e,f
println a+b+c+d+e+f
od
closefile(file)
Simple constructs that everyone understands. And it allows comma
separators in the input, and floating point numbers, that your version
doesn't.
[A version of the loop body which reads variable numbers per line:
readln @file
sum:=0
while (x:=sread())<>"" do
sum+:=x
od
println sum
]
> It is not going to work in a little embedded system - but you don't do
> this kind of task on a little embedded system. It is not going to work
> on a PC from 1999, before Python 2 came out - but this is 2018, not 1999.
Why not? My script (perhaps a cruder version) would have worked in the
1980s. And BASIC would have dealt with this in 1970s (possibly even the
60s).
> This kind of script /is/ easy to run on almost every platform. The
> exception to ease-of-use is, as always, Windows - but it is still /far/
> easier to run a Python script on Windows than to deal with a C compiler.
Rubbish.
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-02-15 21:31 +0100 |
| Message-ID | <p64qnr$b5q$1@dont-email.me> |
| In reply to | #126738 |
On 15/02/18 17:31, bartc wrote:
> On 15/02/2018 14:58, David Brown wrote:
>> On 15/02/18 15:16, Malcolm McLean wrote:
>
>>> It's often easier to write something in a high level scripting language
>>> rather than C. However typically programs are less useful in that form -
>>> a file written in a conservative subset of ANSI C89 is usable
>>> practically anywhere that native code can be run. A script is not
>>> so easy to run on a different platform, or to integrate into a larger
>>> system.
>>>
>>
>> Suppose, for example, these numbers are in a file "test.txt" and you
>> want to find the sum of the numbers on each line. In Python, this can
>> be done as:
>>
>> for ln in file("test.txt").readlines() :
>> nums = [int(x) for x in ln.split()]
> print(sums(nums))
>>
>> That is all you need.
>
> You need file iterators. List comprehensions. Explicit string processing
> and string to int conversions.
>
Python has all these - that is why it is a convenient language for doing
this kind of processing, compared to C.
> So advanced features combined with crude string hacking. A poor example
> of Python I think. Note that your example didn't work, I had to use this:
>
> file=open("input")
> for ln in file.readlines() :
> nums = [int(x) for x in ln.split()]
> print(sum(nums))
> file.close()
Ah, I tested with Python 2 and for some reason (which I don't know, and
which would be off-topic here anyway) you can no longer get a file
object using something like file("test.txt"). But the following minor
change, including a typo fix, works in Python 2 and 3:
for ln in open("test.txt").readlines() :
nums = [int(x) for x in ln.split()]
print(sum(nums))
>
> Here it is in my script language, but reading 6 numbers per line:
>
> file:=openfile("input")
> while not eof(file) do
> readln @file,a,b,c,d,e,f
> println a+b+c+d+e+f
> od
> closefile(file)
>
> Simple constructs that everyone understands.
It is certainly not simpler or clearer than the Python code, IMHO. You
are biased from familiarity with your own language. And of course the
Python could be written in a variety of other ways - I just wrote it in
the way that is natural for me.
> And it allows comma
> separators in the input, and floating point numbers, that your version
> doesn't.
Having some sort of type indication is essential - that's how you can
tell that you are treating these as numbers and not strings. Support
for floating point instead of integers in the Python is a matter of
changing "int" to "float".
>
> [A version of the loop body which reads variable numbers per line:
> readln @file
> sum:=0
> while (x:=sread())<>"" do
> sum+:=x
> od
> println sum
> ]
>
>> It is not going to work in a little embedded system - but you don't do
>> this kind of task on a little embedded system. It is not going to work
>> on a PC from 1999, before Python 2 came out - but this is 2018, not 1999.
>
> Why not? My script (perhaps a cruder version) would have worked in the
> 1980s. And BASIC would have dealt with this in 1970s (possibly even the
> 60s).
Because, as I said, Python 2 came out in 1999. The script may work
unchanged in earlier Python - I haven't tried it. But Python became
ubiquitous, except on Windows, at around that time. Your scripting
language exists nowhere but your own machine. This makes the Python
script immediately useful for this kind of task, while your script is
utterly useless even if it is clearer to you.
>
>> This kind of script /is/ easy to run on almost every platform. The
>> exception to ease-of-use is, as always, Windows - but it is still /far/
>> easier to run a Python script on Windows than to deal with a C compiler.
>
> Rubbish.
>
Installing Python is a single download. Installing a decent C compiler
on Windows seems to be beyond your capabilities - but now you think it
is easier than Python?
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-02-15 21:21 +0000 |
| Message-ID | <zRmhC.24616$Dt.19656@fx18.am4> |
| In reply to | #126749 |
On 15/02/2018 20:31, David Brown wrote:
> On 15/02/18 17:31, bartc wrote:
>> Here it is in my script language, but reading 6 numbers per line:
>>
>> file:=openfile("input")
>> while not eof(file) do
>> readln @file,a,b,c,d,e,f
>> println a+b+c+d+e+f
>> od
>> closefile(file)
>>
>> Simple constructs that everyone understands.
>
> It is certainly not simpler or clearer than the Python code, IMHO.
Really? I believe the Python code just to read three numbers from the
console would be something like:
a, b, c = map(float, input().split())
(with the problems i that every number is a float, and it only allows
white-space separators.
You say that is simpler and clearer than writing:
readln a, b, c
OK. I seem to to remember you said some horrendous C x-macro was better
than the beautifully tabulated version in my language, so you do seem to
have some odd opinions.
You
> are biased from familiarity with your own language.
And my own language was developed from familiarity with others.
Reading a bunch of numbers from a line is classically done by some
command like:
read a, b, c
as done in the OP's pseudo-code, and I'm sure I've done it that way in
Basic, Algol, Fortran and Pascal (too longer ago to remember, but my
language started about then too and I tended to copy what I'd used).
Python, however, specifically can't do as simple as that (except perhaps
with some hairy extensions, but I'm not sure it can as clean as that).
You /have/ to apply string processing to get the numbers out of a line
of input as I showed in my example.
> Having some sort of type indication is essential - that's how you can
> tell that you are treating these as numbers and not strings. Support
> for floating point instead of integers in the Python is a matter of
> changing "int" to "float".
Then you will always get a float, not either int or float. (That may or
may not be what is wanted, but you have to be aware of it.)
> ubiquitous, except on Windows, at around that time. Your scripting
> language exists nowhere but your own machine.
I've posted versions of it from time to time. But availability isn't the
issue. It shows alternative, usually much simpler ways that things can
work. Same with my alternative to C.
>>> This kind of script /is/ easy to run on almost every platform. The
>>> exception to ease-of-use is, as always, Windows - but it is still /far/
>>> easier to run a Python script on Windows than to deal with a C compiler.
>>
>> Rubbish.
>>
>
> Installing Python is a single download. Installing a decent C compiler
> on Windows seems to be beyond your capabilities - but now you think it
> is easier than Python?
You made an unwarranted comment about Windows. If something is hard to
install, it's usually the fault of the thing being installed.
/My/ C compiler is no problem at all. The base compiler is a single
executable; what can go wrong? The following compiles the C program I
posted today:
c:\c>mcc d
MCC/TCL Compiler 2018.1.18
Compiling d.c to d.a64
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2018-02-15 22:17 +0000 |
| Message-ID | <87sha17v8y.fsf@bsb.me.uk> |
| In reply to | #126756 |
bartc <bc@freeuk.com> writes:
> On 15/02/2018 20:31, David Brown wrote:
>> On 15/02/18 17:31, bartc wrote:
>
>>> Here it is in my script language, but reading 6 numbers per line:
>>>
>>> file:=openfile("input")
>>> while not eof(file) do
>>> readln @file,a,b,c,d,e,f
>>> println a+b+c+d+e+f
>>> od
>>> closefile(file)
>>>
>>> Simple constructs that everyone understands.
>>
>> It is certainly not simpler or clearer than the Python code, IMHO.
>
> Really? I believe the Python code just to read three numbers from the
> console would be something like:
>
> a, b, c = map(float, input().split())
>
> (with the problems i that every number is a float, and it only allows
> white-space separators.
>
> You say that is simpler and clearer than writing:
>
> readln a, b, c
>
> OK.
This is not a fair exchange of views. All languages have winners and
losers in the trade-off between providing general mechanisms and
specific ones, but no one but you has access to the documentation for
your language so it's impossible to tell what, if anything, the cost is
of having that simple input line.
For example, one apparent cost is that one can't distinguish between
integer and floating point input because you've posted essentially the
same line for both cases. That may be an advantage, of course, but it
can also be a disadvantage.
And then I don't know how can I specify what separators are permitted,
or how I can tell if there was more or less data than needed. I can't
even tell how to detect an input failure.
It's not that I want to know the answers -- the point is that this is
rapidly going turn into a fruitless exchange without full documentation
for all the languages involved.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-02-15 23:36 +0000 |
| Message-ID | <nPohC.79552$f9.78674@fx02.am4> |
| In reply to | #126762 |
On 15/02/2018 22:17, Ben Bacarisse wrote:
> bartc <bc@freeuk.com> writes:
>> You say that is simpler and clearer than writing:
>>
>> readln a, b, c
>>
>> OK.
>
> This is not a fair exchange of views. All languages have winners and
> losers in the trade-off between providing general mechanisms and
> specific ones, but no one but you has access to the documentation for
> your language so it's impossible to tell what, if anything, the cost is
> of having that simple input line.
There is no cost because you can do it the hard way too (I'm sure I can
do it how Python does it). But the benefit is easier coding and extra
productivity.
> For example, one apparent cost is that one can't distinguish between
> integer and floating point input because you've posted essentially the
> same line for both cases.
I used to support this statement for my compiled language. Then the type
would be depend on the type of the variable. In the dynamic one, the
type is automatic, or you can stipulate the type, or read items as
strings or names, and convert to numbers.
(I've briefly resurrected an old compiler - with static types like C -
which turns this:
int a, b, c
readln a, b, c
into this:
call _qreadln
call _qreadi4
mov [ebp-4],eax ;<a>
call _qreadi4
mov [ebp-8],eax ;<b>
call _qreadi4
mov [ebp-12],eax ;<c>
Really, there's no magic about it. Those functions just return 0 at EOL.
For anything a bit more elaborate there were ways to look ahead.)
That may be an advantage, of course, but it
> can also be a disadvantage.
>
> And then I don't know how can I specify what separators are permitted,
> or how I can tell if there was more or less data than needed. I can't
> even tell how to detect an input failure.
The OP wanted to know how to do something like:
read (a, b, c)
(from a file, but from console is similar).
And some languages do allow that. However, many don't seem to any more,
including Python, despite what David Brown says.
You like to bring up excuses why it can't possibly work. The idea is for
a quick, informal way of reading things without much error-checking,
because the input is trusted, or because an error is inconsequential.
If it wasn't workable, then I wouldn't have the feature. But it is, I
have, and I use it. What's the problem?
> It's not that I want to know the answers -- the point is that this is
> rapidly going turn into a fruitless exchange without full documentation
> for all the languages involved.
You don't need any docs except to know such simple input possible in
many languages without fuss, and is not possible in C and Python without
some fuss. In C, perhaps rather more of it.
In my (scripting) language I typically use such input for reading
configuration files or project files, often ones that have been written
by the same program.
A typical line might have a keyword, followed by known number of
parameters depending on keyword. How sophisticated does a read-line
routine need to be?
readln kwd:"n" # read lower-cased name as first
# item of next input line
case kwd
when "screensize" then
read cols, rows # read what should be two numbers
...
--
bartc
[toc] | [prev] | [next] | [standalone]
Page 1 of 9 [1] 2 3 4 5 6 7 8 9 Next page →
Back to top | Article view | comp.lang.c
csiph-web