On 10/30/2012 04:48 PM, Mark Lawrence wrote:
On 30/10/2012 15:47, Andrew Robinson wrote:
I would refer you to a book written by Steve Maguire, Writing Solid
Code; Chapter 5; Candy machine interfaces.
The book that took a right hammering here
http://accu.org/index.php?module=bookreviews&func=search&rid=467 ?
Yes, although Chapter 5 is the one where the realloc() issue is discussed.
If you have a library, see if you can check the book out -- rather than
spend $$$ on it.
But, in good humor -- Consider the only criticism the poster mentioned
about chapter 5's contents.
Occasionally, he presents a code fragment with a subtle bug, such as:
p = realloc(p,n);
_I have to admit that I didn't spot the bug_, but then I never use
realloc, knowing it to have pitfalls. What is the bug? If realloc
cannot allocate the memory, it returns NULL and the assignment means
you lose your original pointer.
What are the pitfalls? Realloc may or may not copy the data to a
new, larger, area of memory and return the address of that: many
programmers forget this and end up with pointers into the old,
deallocated, area. Even those programmers who remember will likely
fall into the trap that Maguire shows.
_Back to 'clever' code though, he prefers_:
His critique is a bit like the scene in Monty Python's the Life of Br..an...
Where the aliens come, and crash, and leave -- and is totally irrelevant
to what the plot-line is in the movie. What does this comment have to
do with a critique??? McGuire didn't fail to notice the bug!
But the critic doesn't even notice the main *pointS* the author was
trying to make in that chapter.
There are, to be sure, recommendations that I don't agree with in the
book; He doesn't seem to do much Unit testing, postmortems, etc. are
all topics that I studied in a formal class on Software Engineering. It
was a wider perspective than McGuire brings to his book;
But that doesn't mean McGuire has nothing valuable to say!
A short Python Homage for readers of the linked Critique! :
I've had to follow GPL project style rules where the rule for a weird
situation would be:
while (*condition) /* nothing */ ; // and yes, this will sometimes
generate a warning...!!!!
But, I have enough brains to take McGuire's *suggestion* to an improved
Python conclusion.
#define PASS(x) {(void)NULL;}
while (*condition) PASS( Gas ); // There will be no warning!!!!
--
http://mail.python.org/mailman/listinfo/python-list
