Tim Robinson's solution prints less than one word per line!
If the input is, say, HELLO followed by eight spaces followed by WORLD, you'll get a ten-line output with only two words, which is 0.2 words per line. --Rjh (talk) 08:53, 29 April 2015 (UTC)
I concur with the previous commenter about Timrobinson's solution. It grossly fails the spec by trying to be clever (misguided "efficiency"?) and not tracking "in" or "out" of "word" (or "space") state and thus fails on any moderately real-world input such as it's own source!
And, I will add that although implemented differently, the (current) last (and currently next after Timrobinson's) "Another solution" has the same bug.
Including such examples (without at least, as a teaching point, highlighting their grievous failure!) on a site such as this does a great disservice.
I wrote the "other solution", and I only tested it for inputs from command line. That way the program only has to process one line at a time. It works for that, but if its not good enough than remove it. --Tomi
Now I've tested my solution multiple times on a text file and I get back the exact same output as "Richard Heathfield's" solution. So I don't understand whats wrong with my solution. Can you explain it? --Tomi
"can you explain it" -- sure!
Run your compiled solution with its source code as redirected input ("1-12.exe <1-12.c" or whatever). You will see blank lines in the output which fails the "one word per line" spec and is the basis of Rjh's complaint about the "Timrobinson" submission. In the same test case, Heathfield's solution produces different (correct) output from yours. Your solution is not quite as broken as the "Timrobinson" submission as yours produces about nine fewer blank lines of output when given your solution's source as input, so my earlier comment that your solution has the "same bug" as the "Timrobinson" submission is not quite correct. --Nick (talk) 07:10, 3 July 2015 (UTC)
Yeah you were right, I changed my solution, so now it should be okay. I tested this on linux, but I think neither solutions presented here would produce good outputs on windows for example with txt files. I think it is because in a txt file whenever one hits enter you get two characters a carriage return and a new line character, and because of the carriage return character the program thinks thats a "word" on that line so we can get empty lines without visible words. --Tomi 10:17, 2015-07-03 CET
In some limited testing your corrected solution now produces identical results to Heathfield's and Chrismath's solutions. Regarding LF vs CRLF linebreaks, "text mode" file-handling deals with all that just fine. Yes, there can be interoperability issues with such files shared across platforms without taking the necessary precautions, but a file opened in "text mode" on Windows deals with CRLF pairs "matching" "\n" while doing file I/O using standard library functions, so the code should be correct for normal "text files" native to the platform in use. --Nick (talk) 12:52, 3 July 2015 (UTC)
Regarding Martijn Vruggink's solution, what about continuous non-identical delimiter between words, such as this: echo -e "The quick \n\t brown fox jumps over..." ? --AlexeyBolshov (talk) 06:51, 27 January 2018 (UTC)
