yes and no. all types can be treated as if they derive from object (system.object), but in order to treat an instance of a value type (e.g. int, float) as object-derived, the instance must be converted to a reference type using a process called 'boxing'. in theory a developer can forget about this and let the run-time worry about when the conversion is necessary, but in reality this implicit conversion can have side-effects that may trip up the unwary.
yes. for example:
class capplication
{
public static void main()
{
int x = 25;
string s = "fred";
displayme( x );
displayme( s );
}
static void displayme( object o )
{
system.console.writeline( "you are {0}", o );
}
}
this would display:
you are 25
you are fred
c# divides types into two categories - value types and reference types. most of the intrinsic types (e.g. int, char) are value types. structs are also value types. reference types include classes, arrays and strings. the basic idea is straightforward - an instance of a value type represents the actual data, whereas an instance of a reference type represents a pointer or reference to the data.
the most confusing aspect of this for c++ developers is that c# has predetermined which types are represented as values, and which are represented as references. a c++ developer expects to take responsibility for this decision.
for example, in c++ we can do this:
int x1 = 3; // x1 is a value on the stack
int *x2 = new int(3) // x2 is a pointer to a value on the heap
but in c# there is no control:
int x1 = 3; // x1 is a value on the stack
int x2 = new int();
x2 = 3; // x2 is also a value on the stack!
it isn't, really. when an int is being used as an int, it is a value. however, when it is being used as an object, it is a reference to an integer value (on the managed heap). in other words, when you treat an int as an object, the runtime automatically converts the int value to an object reference. this process is called boxing. the conversion involves copying the int to the heap, and creating an object instance which refers to it. unboxing is the reverse process - the object is converted back to a value.
int x = 3; // new int value 3 on the stack
object objx = x; // new int on heap, set to value 3 - still have x=3 on stack
int y = (int)objx; // new value 3 on stack, still got x=3 on stack and objx=3 on heap
not quite. the basic idea is the same, but one significant difference is that c# references can be null . so you cannot rely on a c# reference pointing to a valid object. in that respect a c# reference is more like a c++ pointer than a c++ reference. if you try to use a null reference, a nullreferenceexception is thrown.
for example, look at the following method:
void displaystringlength( string s )
{
console.writeline( "string is length {0}", s.length );
}
the problem with this method is that it will throw a nullreferenceexception if called like this:
string s = null;
displaystringlength( s );
of course for some situations you may deem a nullreferenceexception to be a perfectly acceptable outcome, but in this case it might be better to re-write the method like this:
void displaystringlength( string s )
{
if( s == null )
console.writeline( "string is null" );
else
console.writeline( "string is length {0}", s.length );
}
新闻热点
疑难解答