(You are currently looking at the first edition version of this page. This page is also available for the second
and third editions.)

Errata for Chapter 3: Parameterized typing with generics

P 67, first paragraph: Only one empty string, not two - and Snippy oddities

The text in the first paragraph on P67 currently includes:

It's crude - we end up with two empty strings (one at each end of the text)

In fact, we only get a single empty string - it's due to the period at the end of "green eggs and ham." The regular expression sees a non-word character, so splits "ham." into "ham" and "".

As an aside, this program currently works pretty weirdly in Snippy because it uses a #line directive before every single line to make the error messages work properly. That's fine normally, but not when there's a verbatim string literal involved! The text variable ends up with this text:

Do you like green eggs and ham?
#line 22
I do not like them, Sam-I-am.
#line 23
I do not like green eggs and ham

I'll try to fix it, but it's fun anyway...

P 68, Figure 3.1: Solidifying lines

In figure 3.1, there are various lines which could be considered to be "dashed lines". Unfortunately I refer to just one set of them on page 69, so it would be better if the others weren't dashed.

The long vertical line splitting the left side from the right should be solid but very thin (or grey). The lines labeled "Instantiation" can be turned into solid lines. This leaves just the lines labeled "Specification of type arguments" as dashed lines.

P 68, Note "Jargon alert": Moving the warning symbol

The warning symbol which is currently at the end of the note on P68 would be more appropriate in the left margin, which is where all the similar icons are placed throughout the book.

P 79: Invalid type constraint listed as valid

On page 79, I include the following constraint as a legal one:

// Not valid after all!class Sample<T> where T : class, Stream, new()

This is in fact not a valid constraint, for a reason I wasn't aware of:

If you have a derivation type constraint where the type is a class (such as Stream) you can't also specify either class or struct (the reference and value type constraints respectively).

For any class other than Object, ValueType and Enum, any derived classes will be reference types anyway, so the constraint doesn't do you any good. Note that you can specify an interface for the derivation type constraint and still specify class/struct. For example:

For the next printing of the book, we will simply change the incorrect line to the valid example directly above - there isn't enough room to explain why the top version is invalid without reflowing the page - but if there's ever a comprehensive update to the book, I'll add a full explanation there.

P 82: Comparing values of [type] T

In the section "Direct Comparisons" in the second paragraph, third line, the sentence:

You can't compare two values of T with each other.

This would be clearer as:

You can't compare two values of typeT with each other.

(Change is marked in bold.)

P 98: Missing words in final paragraph of P98

On page 98, the sentence beginning:

Making individual calls to a collection doesn't make the collection thread-safe,

should instead begin:

Making individual calls to a collection thread-safe doesn't make the collection itself thread-safe,

(Changes highlighted in bold.)

P105: Location of "Invalid" marker on first code snippet

In the first code snippet, it's only the final line which is actually invalid. It would be helpful if the "Invalid" arrow pointed directly at this line.

P109: Early Java-like generics

The last sentence on page 109 ends with:

several years after other projects had compilers for their Java-like languages.

This would be clearer as:

several years after other projects had created Java-like languages including generics.

P110, first bullet: Strict versioning in .NET

The first bullet on page 110 ends with these sentences:

Versioning in .NET is much stricter in general - you have to compile using the oldest environment you want to run on. That's safer, but less flexible.

This is misleading in the light of Visual Studio 2008, which can target .NET 2.0. The following would be clearer:

Versioning in .NET is much stricter in general - for each assembly you reference, you can specify whether or not the version number has to match exactly. In addition, code built to run on the 2.0 CLR will not run on .NET 1.1.