differences between saying new object() and new Object() ?

  • Thread starter Thread starter n_o_s_p_a__m
  • Start date Start date
N

n_o_s_p_a__m

Ok, here is a dumb one:

Is there any difference between the lines

new object()

and

new Object()

Also, why are they seemingly interchangable? Why do we have both?
 
n_o_s_p_a__m said:
Ok, here is a dumb one:

Is there any difference between the lines

new object()

and

new Object()
Click to expand...

Nope, none whatosever (assuming don't have any strange using statements
making Object something else!)
Also, why are they seemingly interchangable? Why do we have both?
Click to expand...

string, object, int etc are just C# shorthand for the types
System.String, System.Object, System.Int32 etc. They just make code
easier to read.
 
n_o_s_p_a__m,
object is a C# keyword, that is an alias for System.Object.

You can use object without having to have the 'using System' at the top of
your source file.

Seeing as object is an alias for System.Object both statements are
identical.

Hope this helps
Jay
 
Hi,
It is the same. *Object* is a .NET standart type, *object* is a c# keyword.
the same is for *int* and *Int32*, *string* and *String* and so on.

Using keywords insted of type names make them build-in (primitive) types for
the language.
I believe *object* and *Object* are fully interchangable. It might be not
the case with some of the others ptimitive types like *int* let say. For
the current version of c# *int* is *Int32*. In the future 64-bit verions it
might be changed to Int64. So if you do care the size of variable you should
use Int32 if it is not so important you can use *int*.
Some authors say that is a good practice to use Int32 instead of *int*. I
believe the same doesn't go for the *object* though.

HTH
B\rgds
100
 
I think there is no difference underlying. object is just the alias for
System.Object, you can use it even there is no "using System;". This set of
"shortcuts" are supported by C#, when the compiler meet these keywords , it
will translate them into corresponding Franework types.
Simiarly, there are
string ----System.String,
int ----- System.Int32
....

Qiu
 
100 said:
Using keywords insted of type names make them build-in (primitive) types for
the language.
I believe *object* and *Object* are fully interchangable. It might be not
the case with some of the others ptimitive types like *int* let say. For
the current version of c# *int* is *Int32*. In the future 64-bit verions it
might be changed to Int64. So if you do care the size of variable you should
use Int32 if it is not so important you can use *int*.
Click to expand...

I certainly hope that isn't the case - it would be ridiculous to go
back to the bad old days of not knowing the size of a type. I very,
very much doubt whether they would ever change the meaning of int. They
could add a new keyword for a new Int128 type, for instance, but
there's no need to change the meaning of existing keywords.
Some authors say that is a good practice to use Int32 instead of *int*. I
believe the same doesn't go for the *object* though.
Click to expand...

That's not the reason normally given though. The reason is that methods
should normally be named in a language-neutral way anyway, so it can
add consistency to declare fields/parameters in a language-neutral way
as well. For instance:

float GetSingle()
double GetDouble()
int GetInt32()

is less symmetric than

Single GetSingle()
Double GetDouble()
Int32 GetInt32()

I've never heard anyone claim it for reasons of potential changes to
the C# standard.
 
Hi John,
Jon Skeet said:
I certainly hope that isn't the case - it would be ridiculous to go
back to the bad old days of not knowing the size of a type. I very,
very much doubt whether they would ever change the meaning of int. They
could add a new keyword for a new Int128 type, for instance, but
there's no need to change the meaning of existing keywords.
Click to expand...

Yes, you are right. I went briefly through the c# specification and looks
like int is fixed to Int32. Whether it is typical for the modern language or
not I don't want to discuss. I prefer to left this to be desided by the
professionals.
That's not the reason normally given though. The reason is that methods
should normally be named in a language-neutral way anyway, so it can
add consistency to declare fields/parameters in a language-neutral way
as well. For instance:

float GetSingle()
double GetDouble()
int GetInt32()

is less symmetric than

Single GetSingle()
Double GetDouble()
Int32 GetInt32()

I've never heard anyone claim it for reasons of potential changes to
the C# standard.
Click to expand...

I'd recalled wrongly the reason why those authors suggest to use system
types instead of language keywords.

One of the reson is because defferent languages map the same kayword to the
diferent types.
In .NET world where multy language development is one of the main goals this
can be very confusing.
This make sense to me.


B\rgds
100
 
Back
Top