instantiation; and arrays & structures really objects?

[BobLewiston]

Pardon me for flogging a dead horse here, but I'm trying to understand as clearly as possible some issues pertaining to the instantiation of objects.

Firstly, have I correctly analyzed the functions and uses of each of the various syntaxes related to instantiating objects? Please don't flame me, saying "why don't I read the documentation". I've read it thoroughly. The point is I want to understand the material in finer detail than for which I can find documentation.

To declare an object [create an object variable to hold a reference ("handle") of an object of the required class type]:

ClassName ObjectName;

(Am I not correct that a handle is simply an address?)

To instantiate an object (allocate space for it in the heap):

new ClassName ();

When an object is instantiated, it is usually within the same statement "assigned" to an object variable (see immediately below). This "assignment" means the reference of the object is placed into the object variable to make the variable "point to" the object. However, this reference may instead be returned to a calling method without assigning it to an object variable.

To instantiate an object and assign it to an object variable within a single statement:

ObjectName = new ClassName ();

To declare an object (variable), instantiate an object and assign the object to the object variable within a single statement:

ClassName ObjectName = new ClassName ();

To assign the reference of an object held by one object variable to another object variable (to make both object variables point to the same object):

ObjectName2 = ObjectName;

Secondly, what is the precise relationship of arrays and structures to classes and objects?

Objects are instantiations of classes, and as such are reference-type variables, space for which is allocated in the heap, not on the stack.

struct is said to be a "lightweight" form of class, and structures, like objects, must be instantiated. But structures can be instantiated without use of the keyword "new" (unlike classes), which means that no constructor is executed when structures are instantiated in this way.

Also, structures are of value-type, and so space for them must be allocated on the stack, not in the heap. Plus, like all value types, structures lack inheritance functionality.

So are structures objects or not?

I have read that arrays ARE objects. They also can be instantiated without use of the keyword "new", but only if they are also initialized (and sized) within the same statement:

DataType [] ArrayName = { < element list > };

In this case, it must be that, as with structures, no constructor is executed.

In addition, although the individual elements of an array may be of a user-defined data type, an array itself is never an instantiation of a user-defined data type (I think). Furthermore, like structures, arrays lack inheritance functionality.

So are arrays really objects? They seem so different from other objects.

And just as a matter of curiosity:

Arrays are inherited from the System.Array class. But ALL data types in C#, even value types including implicit types, are implicitly inherited from the System.Object class. (Of course, that doesn't mean all variables, regardless of data type, are objects.)

So is the System.Array class inherited directly from the System.Object class? (For that matter, is there any way I can actually read the namespace files?)

 

[jaeusm]

You're on the right path, but first, lets clarify some of the terms you're using.

To declare an object (variable), instantiate an object and assign the object to the object variable within a single statement:

ClassName ObjectName = new ClassName ();

Emphasis mine. This may have been a typo on your part, but just to make sure you understand the meaning of the terms, you cannot instantiate an object. An object is, by definition, an instance of a class. Thus, you instantiate a class (in the .NET world, we use the term 'type' rather than 'class'), which results in the creation of an object.

But structures can be instantiated without use of the keyword "new" (unlike classes), which means that no constructor is executed when structures are instantiated in this way.

That is true, but structs can also be instantiated using a non-default constructor -- in other words, a constructor that does require parameters.

Plus, like all value types, structures lack inheritance functionality.

Yes and no. From the developer's perspective, you cannot create a structure that derives from some other struct. However, a struct can implement interfaces. Also, structs themselves derive from System.ValueType.

So are structures objects or not?

Yes. Everything in .NET derives from System.Object, including System.ValueType.

They also can be instantiated without use of the keyword "new", but only if they are also initialized (and sized) within the same statement.
...
In this case, it must be that, as with structures, no constructor is executed.

Technically, the compiler is creating an instance of the array under the hood. It's an example of what is called "syntactic sugar" -- basically a shortcut afforded to the programmer by the compiler. In actuality, a constructor is being called, only the compiler is handling that for you.

So are arrays really objects? They seem so different from other objects.

Yes. All arrays are derived from the abstract System.Array class. Arrays will always be allocated on the managed heap.

Arrays are inherited from the System.Array class. But ALL data types in C#, even value types including implicit types, are implicitly inherited from the System.Object class. (Of course, that doesn't mean all variables, regardless of data type, are objects.)

The word 'object' does not necessarily mean 'reference type' in C#. Anything that derives from System.Object is an 'object', which is everything. Instead, the distinction is between 'reference type objects' and 'value type objects'. As you correctly pointed out before, reference type objects are created on the managed heap, while value type objects are created on the stack.

So is the System.Array class inherited directly from the System.Object class?

Yes.

(For that matter, is there any way I can actually read the namespace files?)

Yes, just check out MSDN or use Reflector to reflect over the .NET dll's.

 

[BobLewiston]

Thanks, jaeusm.

 

[BobLewiston]

attention, jaeusm:

In your opinion, does the following seem to indicate that some data types are NOT objects? It's from
Boxing and Unboxing (C#) :

Boxing and Unboxing (C# Programming Guide)

Boxing and unboxing enable value types to be treated as objects. Boxing a value type packages it inside an instance of the Object reference type. This allows the value type to be stored on the garbage collected heap. Unboxing extracts the value type from the object. In this example, the integer variable i is boxed and assigned to object o.

int i = 123;
object o = (object)i;  // boxing

The object o can then be unboxed and assigned to integer variable i:

o = 123;
i = (int)o;  // unboxing

 

[jaeusm]

Yes, but it really depends on how you define 'object'. In the object-oriented paradigm, an object is an instance of a class. Strictly speaking in the case of C#, that would mean that only reference types on the managed heap are objects. It's consistent with theoretical OO terminology. However, a more pragmatic view is that anything that derives from System.Object is an object. In practice I don't really think the semantics of 'object' is much of an issue because we typically only talk about reference types and value types. It's just something for you to be aware of.

 

[NightSurge]

Eh, I hate how C and Java are so similar..... although, since I know Java, if I ever need to learn C, it shouldn't be much of a transition! Nice advice jaeusm!