Errata

CLR via C#

Errata for CLR via C#

The errata list is a list of errors and their corrections that were found after the product was released. If the error was corrected in a later version or reprint the date of the correction will be displayed in the column titled "Date Corrected".

The following errata were submitted by our customers and approved as valid errors by the author or editor.

Color key: Serious technical mistake Minor technical mistake Language or formatting error Typo Question Note Update

Version Location Description Submitted By Date submitted Date corrected
Printed
Page 110 - 116

GetProgressReport should be GenProgressReport (x3) On pages 110 through 116, in Figures 4-6, 4-7, 4-8, 4-9, 4-10, 4-11, 4-12 and 4-13, there is an error in the code. All references to:GetProgressReportShould read:GenProgressReport

 Microsoft Press  May 06, 2010 
Printed
Page 168

0 should be startIndex
On page 168, in the code sample at the bottom of the page, there is an error in the second Find function code.

Change:

return Find(value, 0, m_length);To:

return Find(value, startIndex, m_length);

 Microsoft Press  Jul 13, 2010 
Printed
Page 320

"Boxing occurs here" should be "Boxing doesn't occur here" On page 320, in the second line from the top, Change: "Boxing occurs here" To: "Boxing doesn't occur here" Microsoft Press is committed to providing informative and accurate books. All comments and corrections listed above are ready for inclusion in future printings of this book. If you have a later printing of this book, it may already contain most or all of the above corrections.The print number of the book is located on the copyright page in the form of a string of numbers. For example: "2 3 4 5 6 7 8 0 QWT 9 8 76 5 4". The first number in the string is the the print number. In this example, the print number is 2.

 Microsoft Press  May 06, 2010 
Printed, PDF,
Page 322
Last paragraph of "Generics and Interface Constraints" section

On page 322 Book asserts:

"Aside from using interface constraints,..., calling an interface method on a value type always causes boxing."

However, on page 319 and 320 in "SomeMethod2()", Book illustrates calling a generic interface method on a value type and asserts that no boxing occurs.

I believe the illustration on 319/320 is correct; so the statement on 322 is too sweeping.

Note from the Author or Editor:
I'll consider modifying this text in a future edition.

 Jaime Maddox  Feb 12, 2011