f2(new int[n], m); // bad: the wrong number of elements can be passed to f()
f2(new int[n], m); // bad: a wrong number of elements can be passed to f()
}
Passing the number of elements as an argument is better (and far more common) than just passing the pointer and relying on some (unstated) convention for knowing or discovering the number of elements. However (as shown), a simple typo can introduce a serious error. The connection between the two arguments of `f2()` is conventional, rather than explicit.
@ -1000,7 +1002,8 @@ The use of a non-local control is potentially confusing, but controls only imple
Reporting through non-local variables (e.g., `errno`) is easily ignored. For example:
fprintf(connection, "logging: %d %d %d\n", x, y, s); // don't: no test of printf's return value
// don't: no test of printf's return value
fprintf(connection, "logging: %d %d %d\n", x, y, s);
What if the connection goes down so that no logging output is produced? See I.??.
@ -1439,7 +1442,8 @@ This is a major source of errors.
int printf(const char* ...); // bad: return negative number if output fails
template <classF,class...Args>
explicit thread(F&& f, Args&&... args); // good: throw system_error if unable to start the new thread
// good: throw system_error if unable to start the new thread
explicit thread(F&& f, Args&&... args);
##### Note: What is an error?
@ -1993,7 +1997,8 @@ Functions with complex control structures are more likely to be long and more li
Consider:
double simpleFunc(double val, int flag1, int flag2)
// simpleFunc: takes a value and calculates the expected ASIC output, given the two mode flags.
// simpleFunc: takes a value and calculates the expected ASIC output,
// given the two mode flags.
{
double intermediate;
@ -2036,12 +2041,14 @@ We can refactor:
}
double simpleFunc(double val, int flag1, int flag2)
// simpleFunc: takes a value and calculates the expected ASIC output, given the two mode flags.
// simpleFunc: takes a value and calculates the expected ASIC output,