C# in Depth

52 CHAPTER 2 Core foundations: building on C# 1the 32-bit or 64-bit CLR) rather than copying all the data. Imagine if ArrayList weresomehow a “pure” value type, and passing an ArrayList expression to a methodinvolved copying all its data!MYTH #2: “REFERENCE TYPES LIVE ON THE HEAP, VALUE TYPES LIVE ON THE STACK”This one is often caused just by laziness on the part of the person repeating it. Thefirst part is correct—an instance of a reference type is always created on the heap. It’sthe second part that is problematic. As we’ve already noted, a variable’s value liveswherever it’s declared—so if you have a class with an instance variable of type int, thatvariable’s value for any given object will always be where the rest of the data for theobject is—on the heap. Only local variables (variables declared within methods) andmethod parameters live on the stack.NOTE Are these concepts relevant now? It’s arguable that if you’re writing managedcode, you should let the runtime worry about how memory is bestused. Indeed, the language specification makes no guarantees aboutwhat lives where; a future runtime may be able to create some objects onthe stack if it knows it could get away with it, or the C# compiler couldgenerate code that hardly uses the stack at all.The next myth is usually just a terminology issue.MYTH #3: “OBJECTS ARE PASSED BY REFERENCE IN C# BY DEFAULT”This is probably the most widely propagated myth. Again, the people who make thisclaim often (though not always) know what the actual C# behavior is, but they don’tknow what “pass by reference” really means. Unfortunately, this leads to people whodo know what it means getting confused. The formal definition of “pass by reference”is relatively complicated, involving l-values and similar computer science terminology,but the important thing is that if you pass a variable by reference, the method you’recalling can change the value of the caller’s variable by changing its parameter value. Nowremember that the value of a reference type variable is the reference, not the objectitself. You can change the contents of the object that a parameter refers to without theparameter itself being passed by reference. For instance, the following methodchanges the contents of the StringBuilder object in question, but the caller’s expressionwill still refer to the same object as before:void AppendHello (StringBuilder builder){builder.Append("hello");}When this method is called, the parameter value (a reference to a StringBuilder) ispassed by value. If I were to change the value of the builder variable within themethod—for example with the statement builder = null;—that change wouldn’t beseen by the caller, contrary to the myth.It’s interesting to note that not only is the “by reference” bit of the myth inaccurate,but so is the “objects are passed” bit. Objects themselves are never passed, eitherby reference or by value. When a reference type is involved, either the variable isLicensed to Rhona Hadida