Hm, not sure to whom this may concern, I always get confused by these hierarchies of threads... Anyway, the concept of a C++ reference is a subtle thing and it got even subtler with c++0x, as you might know. For good reasons this concept wasn't considered is what C# and other CLR targeting languages - and now we're back at OP's problem (at least as I see it...): in case of reference types (and in a verifiable program), you always deal with handles ("pointers") to instances. These handles can have two states: (a) pointing to valid object, (b) or "null". You can take a value of a "handle" by reference, by stating this intent explicitely at both call and target sites. However, this does not change the semantics of a handle, you just get access to the location of whatever the handle represents. So in C#, if you want to protect against handle pointing to "null", you either have to be explicit about that (code contracts are a great way to do that), or you rely on NullArgumentException handling (which is guaranteed to be thrown by the specs). The ref modifier mentioned somewhere in the thread does not help much:
void Bar(MyClass pParam) {
pParam.Member(); // guaranteed NullArgument exception if null
}
void Bar(ref MyClass pParam) {
pParam.Member(); // guaranteed NullArgument exception if null
pParam = new MyClass();
}
void Foo() {
MyClass tI1;
MyClass tI2 = null;
MyClass tI3 = new MyClass();
Bar(ref tI1); // error, tI1 uninitialized
Bar(ref tI2); // ok
Bar(ref tI3); // ok
Bar(tI1); // warning or error, not sure
Bar(tI2); // NullArgumentEx...
Bar(tI3); // ok
}
