Problem 77: Greedy Gift Givers

[santosh]

I've got a weak, but nonetheless interesting argument against writing
code 'professionally' in reference to checking inputs: The amount of
time you spend coding that will slowly accumulate over the 4 hour
period when the competition is on and you'd be wasting way too much
time checking against bad inputs. If you ever try one of these comps
try doing it 'professionally' and see how little or how much time it
takes to check bad inputs.

The organisers of the competition should specify whether they expect
full error checking or code that concentrates on solving the stated
problem. There is nothing wrong in writing code without error checking
provided it is understood that it merely for illustrative purposes. For
example Kernighan and Ritchie omit almost all error checking in the
code they present in K&R, and they carefully mention this in more than
one place in the book.

 

[Ben Bacarisse]

I've got a weak, but nonetheless interesting argument against writing
code 'professionally' in reference to checking inputs: The amount of
time you spend coding that will slowly accumulate over the 4 hour
period when the competition is on and you'd be wasting way too much
time checking against bad inputs. If you ever try one of these comps
try doing it 'professionally' and see how little or how much time it
takes to check bad inputs.

It depends of you do one or more. After the first example you posted,
I already had "int read_num(FILE *fp);" written so it took zero time
to check the input format for the second.

As for file opening, you have to write:

FILE *in = fopen("aflin.txt" , "r");
FILE *out = fopen("aflout.txt", "w");

so how long does it take to write:

if (in && out) {
}

after it? You don't need an error message and even if you always
develop competition code in a debugger it is quicker to see you have
got an open error (maybe you mistyped the name?) this way than by
asking to see "in" or "out".

For "quick and dirty" programs, C gives you an excellent way proceed
only if thing are OK:

if ((in = fopen("aflin.txt" , "r")) &&
(out = fopen("aflout.txt", "w")) &&
(size = read_num(in)) <= 30000 &&
(data = malloc(size * sizeof *data)) &&
...)

etc. You won't get good diagnostics, but you will save time if there
is some problem and is hardly any shorter that writing it without the
tests.