errata.txt

API经典入门

Dear Readers of Teach Yourself MFC in 21 Days,

We write to you now with a heavy heart.  Yes, there are errors in the MFC book.
What's worse is that the corrections enumerated here won't cover all the errors.
In Publishing, the term "error free" is just as meaningless as it is in 
software; there is no such thing.  This note embodies the errors found in the 
first printing of the book.  If you find any errors not included here or if
you have any questions, comments, or suggestions that will make future revisions
of this book better please send them to either of our E-mail addresses below.

Despite the following errors, we hope you find our book helpful.  Thank you for
your support.

- Bob Shaw
  CompuServe: 74003,1146

- Dan Osier
  CompuServe: 72724,710

Introduction:
	ERROR: Page xxi in the middle of the first paragraph -- "(see Appendix F 
	for ... Hungarian notation)".  
	CORRECTION: Appendix B deals with Hungarian notation.

Chapter 1:

Chapter 2:
	ERROR: Page 39 in the implementation of DrawBoard() -- missing line of 
	code.
	CORRECTION: Add the following line immediatly after "int i;"
		int nSize = BOARD_SIZE;
	or you may replace every instance of nSize with BOARD_SIZE.


Chapter 3:

Chapter 4:

Chapter 5:

Chapter 6:

Chapter 7:
	ERROR: Page 185 & 186 from the last paragraph on p185 through the first
	paragraph on p186.  The material concerning explicit memory clean-up of
	member variables.
	CORRECTION: Big oops on this one -- remove the entire section.  As many
	of you know, you must be able to trust memory clean up to the
	appropriate destructors.  As one reader	pointed out, explicitly
	destroying member variables is duplicating the effort of the destructor.
	You wouldn't explicity double check the addition function everytime it
	performs an addition.  So you shouldn't worry about this sort of memory
	reclamation.  However, there are other very legitemate circumstances
	where an override of the destructor is needed.  For instance reclaiming
	manually allocated memory.  But don't assume the task of reclaiming 
	memory that will be automatically reclaimed when the variable goes out 
	of scope.
	
	There is another lesson to be learned by my mistake here.  The reason I
	had to backpedal so hard was because I originally treated the symtom of
	a problem instead of looking for its true cause.  Let's peel back some
	time and travel to the time when I was writing chapter 7.  I was tracing
	down a memory leak.  The only culprit I could find was the destuctor
	mentioned above.  I immediately jumped to the conclusion that some bit 
	of memory wasn't being freed so I freed them myself.  Problem solved!?!
	True, I did eliminate the memory leak.  But I did so by violating the
	OOP paradigm.  In this case the only harm done was a duplication of 
	effort and a decrease of understandability.  However, this kind of 
	hackish approach to error correction is at odds with the disipline
	embodied in the MFC and Software Engineering.  My apologies.

Chapter 8:

Chapter 9:

Chapter 10:

Chapter 11:

Chapter 12:

Chapter 13:

Chapter 14:

Chapter 15:

Chapter 16:

Chapter 17:

Chapter 18:

Chapter 19:

Chapter 20:

Chapter 21:
	ERROR: Page 563 & 564 in the header for Table 21.2 -- "Windows 3.11/Word
	for Windows 3.11"
	CORRECTION: "Windows 3.11/Windows for Workgroups 3.11"

Appendix C:
	ERROR: There was a configuration control mix-up between the two authors
	on this appendix.  Consequently a draft version of this document accidently
	went to print.
	CORRECTION: This appendix is so replete with errors, a new appendix is 
	included in this file--APPENDXC.TXT or APPENDXC.DOC (Word for Windows).