Path: csiph.com!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail From: Tim Rentsch Newsgroups: comp.lang.c Subject: Re: Programming exercise/challenge Date: Wed, 30 Dec 2020 09:17:54 -0800 Organization: A noiseless patient Spider Lines: 91 Message-ID: <86eej7usal.fsf@linuxsc.com> References: <86wnxwkyol.fsf@linuxsc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: reader02.eternal-september.org; posting-host="bad9f3398650fdf0e991b5310f5ac4d7"; logging-data="10180"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19QMebQrlNeU45m96UYNFyY1JRBtijkRhc=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:qbXuhlDb1Fu+L8sw9s9sUAZ3ewQ= sha1:0YSSADCBkhSTfOMeW6hDu4ndLQA= Xref: csiph.com comp.lang.c:157907 Tim Rentsch writes: > Prompted by some recent discussion regarding 'goto' statements and > state machines, I would like to propose a programming exercise. > (It is perhaps a bit too large to be called an exercise, but not so > difficult that it deserves the label of challenge. On the other > hand there are some constraints so maybe challenge is apropos. In > any case somewhere in between those two bounds.) > > Short problem statement: a C program to remove comments from C > source input. [...] It looks like we are wrapping up. Thank you to everyone who participated. There were 34 posted solutions, from 10 participants. Those numbers include one "solution" I posted in one sub-thread, even though it isn't really in the spirit of the problem since it folds multiple physical lines into logical lines, and also reads the entire input into a single character array before any processing. But since it was posted I included it. Counting just the most recent version from each participant, here are some aggregate statistics: 81 12.42 11.47 0.95 7.65% 1006 929 77 63.0 58.1 4.8 1598 ^ ---------------- ^ ------------ -------------- ^ | functn averages | functn total body percents | | | | | +-- avg % blank lines/function | | | +-- number of functions total number of source lines --+ For each of function averages, function total, and body percents, the three numbers shown measure lines, non-blank lines, and blank lines, respectively. The function averages are the average number of lines in function bodies (of each type) per function. The function totals are the total number of lines in function bodies (of each type), of all functions. The body percents are the number of lines (of each type) inside function bodies, given as a percentage of the total number of source lines. Here are the corresponding statistics for (the most recent version of) each participant, sorted by total number of source lines: 5 10.40 10.40 0.00 0.00% 52 52 0 64.2 64.2 0.0 81 1 88.00 88.00 0.00 0.00% 88 88 0 88.9 88.9 0.0 99 2 40.00 36.00 4.00 10.00% 80 72 8 73.4 66.1 7.3 109 2 60.00 51.00 9.00 15.00% 120 102 18 88.2 75.0 13.2 136 6 18.33 17.17 1.17 6.36% 110 103 7 78.0 73.0 5.0 141 9 11.33 9.67 1.67 14.71% 102 87 15 72.3 61.7 10.6 141 4 19.00 16.00 3.00 15.79% 76 64 12 50.0 42.1 7.9 152 6 22.67 21.67 1.00 4.41% 136 130 6 82.9 79.3 3.7 164 18 4.44 4.17 0.28 6.25% 80 75 5 35.4 33.2 2.2 226 28 5.79 5.57 0.21 3.70% 162 156 6 46.4 44.7 1.7 349 (Full disclosure: the counts may not match exactly the code that was posted. The code was uniformly formatted to allow more meaningful comparisons between the different source files.) Number of functions ranged from 1 to 28. Average function length ranged from 4.44 lines to 88 lines. Percentage of blank lines per function body ranged from 0% to almost 16%. Total number of function body lines ranged from 52 to 162. (The 52 number is from a remarkably compact program.) Function body lines as a percentage of source lines ranged from 35.4% to 88.9%. The smallest variation was on function body lines as a percentage of total source lines (average of 67.97%, std dev 18.51). The largest variation was on number of functions (average of 8.1, std dev of 8.53), and average function body lengths (columns two to four; using number of average non-blank lines as representative, average of 25.96 lines, std dev of 26.18 lines). One further comment: I did run all of these most recent versions on a standard test input, but I don't have any kind of statistics on the results. In some cases I replied to individual entries with suggestions for test cases to try, but there was no particular rhyme or reason to which ones that happened with. I should be posting what I consider a reference implementation soon, so if someone is interested that could be used as a basis for comparison. I guess that's all. Thank you all again, it has been very interesting.