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?)

[oracleguy]

The first part about classes is correct.

In C# I believe you still need to use the new keyword on structures before you can use them. Structures are reference types (and objects) in C#. Though a critical difference between structures in C++ and C# is that in C# the default access level is private (whereas in C++ it is public). They kind of envisioned you'd but properties on each one so there would be getters and setters but if you are doing that, you are practically creating a class. So the line is a little blurry there. In C++ structures can have constructors, I *think* C# will let you do this as well.

Arrays in C# are considered objects as well since they have properties and methods. An object doesn't have to support inheritance to be considered an object. (See the C# keyword sealed)

[BobLewiston]

>The first part about classes is correct.

Thanks, that's a help.

>In C# I believe you still need to use the new keyword on structures before you can use them.

Well, the following compiles and runs:
using System;
namespace CSharpSchool
{
class Program
{
static void Main()
{
Citizen citizen;
citizen.name = "Buster";
citizen.age = 34;
Console.WriteLine("{0}, {1}", citizen.name, citizen.age);
}
struct Citizen
{
public string name;
public int age;
}
}
}
>They kind of envisioned you'd but properties on each one so there would be getters and setters...

Is the word "but" supposed to be "use", or are there a couple words missing here? Please restate.

>In C++ structures can have constructors, I *think* C# will let you do this as well.

Yes, C# allows user-defined constructors, as long as they have arguments.

>Arrays in C# are considered objects as well since they have properties and methods.

I didn't know they could have properties and methods. I'll check it out.

>An object doesn't have to support inheritance to be considered an object. (See the C# keyword sealed)

Acknowledged. Thank you.

[ralph l mayo]

Firstly, have I correctly analyzed the functions and uses of each of the various syntaxes related to instantiating objects?
[snip]

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?)

This is maybe more appropriate to think about as an entry in the compiler's symbol table than as an address. When it comes across a declaration without a definition like this the only responsibility of the compiler is to make a note of it in the symbol table at the appropriate scope so that the next time you say 'ObjectName' in scope it can find what you're referring to.

It makes sense that the compiler might assign it an address right away since it knows the size of ClassName and can hence find an appropriate place for it, but it may also defer this until instantiation to more closely match the behavior of C++, in which case the equivalent ClassName* ObjectName; Does not have an address, and is rather a container waiting for the address, which comes later from operator new.

Not that it really matters when it gets an address from a practical point of view, but if we're picking nits...

I don't see any issues with the rest of your understanding.

Secondly, what is the precise relationship of arrays and structures to classes and objects?
The concept of a struct varies a lot from language to language. In C# the only really meaningful distinction afaik is that they are value types, so they can be more efficient for small-data structures where the overhead of de-referencing reference types would be higher than simply moving the referenced value around. Structures are objects.

Arrays in C# are simply objects that contain other objects. As you say, everything inherits from System.Object, and a method prototyped as void doStuff(object obj) can accept anything whatsoever (apart form unsafe pointers I guess), including an array of objects, object[].

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).
I think this is true if I understand your meaning, that you can't extend System.Array to create your own array type, because System.Array gets special treatment internally. You can however get a functionally similar scenario working by implementing array's interfaces: ICollection, IList, IEnumerable, and ICloneable.

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.)
I'm curious why you don't think every data type really is an object. Did you know you can use 4.Equals(4)? or "fo".Insert(2, "o")

So is the System.Array class inherited directly from the System.Object class?
Yes, but you won't see it (or anything else) declared as explicitly inheriting from Object b/c it's an implicit requirement of existence as a .NET type.

(For that matter, is there any way I can actually read the namespace files?)
I don't know, but the information you need is on msdn.com. You can use the operator 'is' to check inheritance at runtime.

[BobLewiston]

>I'm curious why you don't think every data type really is an object. Did you know you can use 4.Equals(4)? or "fo".Insert(2, "o")

Acknowledged. I now recall reading about how data types in C# map to comparable data types in .Net, even for implicit types.

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

>I don't know, but the information you need is on msdn.com. You can use the operator 'is' to check inheritance at runtime.

Good point. Thanks.

Does anybody know if there even are readable versions of the namespace files? Maybe only the .DLLs are available.