Question of JAVA programmer to C# programmers

[Xandau]

hello all,
i wotk with java every day but last time i have interested in C#.
everything goes great except one thing...

in java everything is a reference (except plain types) so i thought
that in C# will be the same - i was wrong....
or if in C# is the same as in java please tell me ;-)

I have an ArrayList names ls :
// Point is a class System.Draw....
// Please excuse me an errors in code, but i write it from my head ;-)

ArrayList ls = new ArrayList[2];
ls[0] = new Point(0,0);
ls[1] = new Point(10,10);

Point p = (Point) ls[0];
p.X = 20;
p.Y = 20;

// print p.ToString()
// ((Point) ls[0]).ToString()


// please notice that (p!= (Point) ls[0]) = TRUE
why p is a copy of object Point stored as first element of ArrayList
(ls[0])???

Do i something wrong???

I was browsing MSDN but i haven't found an explanation of situation
presented above.

 

[Dmitriy Lapshin [C# / .NET MVP]]

Hello,

There's nothing wrong. Point is a so-called value type (which is stored in
memory by value, not by reference). But ArrayList is only capable of storing
anything derived from System.Object which is a reference type. Therefore,
the runtime somehow needs to convert the value type to a reference one. Such
a conversion is called boxing, and the opposite conversion is called
unboxing.

So what you experience is a little CLR trick used to have an ability to use
value types where a reference type is required.

Search MSDN on 'boxing "value type"' for more details.

 

[Wim Hollebrandse]

Xandau,

By default, C# classes implement reference equality, which is what you mean.
For specific classes however, it makes more sense to override this behavior
and implement value equality on that class, based on particular properties,
as is the case with the Point class.

Hope that helps.

Regards,
Wim Hollebrandse

 

[Jon Skeet [C# MVP]]

i wotk with java every day but last time i have interested in C#.
everything goes great except one thing...

in java everything is a reference (except plain types) so i thought
that in C# will be the same - i was wrong....
or if in C# is the same as in java please tell me ;-)

Not everything in Java is a reference either - there are value types
(int, char, bool etc) it's just you can't define your own value types.

I have an ArrayList names ls :
// Point is a class System.Draw....

No, Point is a *struct* in System.Drawing. It's a value type, not a
reference type.

 

[Wim Hollebrandse]

OK - serves me right for not checking what type Point was. Struct - as Jon
already pointed out.

Apart from that - had Point been a class, my reply would've made more sense.

Apologies for any confusion.

Cheers,
Wim

Xandau,

By default, C# classes implement reference equality, which is what you mean.
For specific classes however, it makes more sense to override this behavior
and implement value equality on that class, based on particular properties,
as is the case with the Point class.

Hope that helps.

Regards,
Wim Hollebrandse
--
http://www.wimdows.net
http://www.wimdows.com

hello all,
i wotk with java every day but last time i have interested in C#.
everything goes great except one thing...

in java everything is a reference (except plain types) so i thought
that in C# will be the same - i was wrong....
or if in C# is the same as in java please tell me ;-)

I have an ArrayList names ls :
// Point is a class System.Draw....
// Please excuse me an errors in code, but i write it from my head ;-)

ArrayList ls = new ArrayList[2];
ls[0] = new Point(0,0);
ls[1] = new Point(10,10);

Point p = (Point) ls[0];
p.X = 20;
p.Y = 20;

// print p.ToString()
// ((Point) ls[0]).ToString()


// please notice that (p!= (Point) ls[0]) = TRUE
why p is a copy of object Point stored as first element of ArrayList
(ls[0])???

Do i something wrong???

I was browsing MSDN but i haven't found an explanation of situation
presented above.

 

[Xandau]

Not everything in Java is a reference either - there are value types

(int, char, bool etc) it's just you can't define your own value types.

int, char... are a plain types
but i agree for example String is an object which is value type...
but it is known for everyone who use java more than month.

however thanks for answer - it was really fast ;-)

Xandau

 

[Guest]

because System.Drawing.Point is declared as a struct which is value type. understand that .NET is not Java, there are going to be differences. and understanding java is not understanding .NET, though some knowledge is definitely transferable between these two

----- Xandau wrote: ----

hello all
i wotk with java every day but last time i have interested in C#
everything goes great except one thing..

in java everything is a reference (except plain types) so i though
that in C# will be the same - i was wrong...
or if in C# is the same as in java please tell me ;-

I have an ArrayList names ls
// Point is a class System.Draw...
// Please excuse me an errors in code, but i write it from my head ;-

ArrayList ls = new ArrayList[2]
ls[0] = new Point(0,0)
ls[1] = new Point(10,10)

Point p = (Point) ls[0]
p.X = 20
p.Y = 20

// print p.ToString(
// ((Point) ls[0]).ToString(


// please notice that (p!= (Point) ls[0]) = TRU
why p is a copy of object Point stored as first element of ArrayLis
(ls[0])??

Do i something wrong??

I was browsing MSDN but i haven't found an explanation of situatio
presented above

 

[Xandau]

So what you experience is a little CLR trick used to have an ability to
use

value types where a reference type is required.

Search MSDN on 'boxing "value type"' for more details.

--
Sincerely,
Dmitriy Lapshin [C# / .NET MVP]
Bring the power of unit testing to the VS .NET IDE today!
http://www.x-unity.net/teststudio.aspx

is this possible to do this using references?
is this possible to convert value type to reference type?

Xandau

 

[Xandau]

i have no MSDN here ( i am going to go home cause now i am in job)
but is this possible to cast ls[0] in that way that i will have a reference
to
the struct Point?

any ampersands etc (like in C: Point& p = ls[0])?

Xandau

 

[Ann Marinas]

Hi, Xandau!

Just made a correction on how you declare your arraylist:
Change this: ArrayList ls = new ArrayList[2];
To this: ArrayList ls = new ArrayList();

You do not need to specify the length of your ArrayList in C# because an
ArrayList is increased dynamically . But it is possible to specify using the
Capacity property.

Make sure that when you are using the ArrayList class, you need to add the
System.Collections as a reference.

When you are adding your elements to the arraylist do this:
ls.Add(new Point(0,0));
ls.Add(new Point(10,10));

And then you can access it the same way as with Java:
Point p = (Point) ls[0];
p.X = 20;
p.Y = 20;

Hope this helps!


--Ann

 

[Jon Skeet [C# MVP]]

int, char... are a plain types

They are value types. I don't remember any definition of "plain types"
in any specification...

but i agree for example String is an object which is value type...

No it's not. It's a reference type, which happens to be immutable and
therefore has value-*like* semantics.

but it is known for everyone who use java more than month.

Um, you might want to reconsider that

 

[Jon Skeet [C# MVP]]

They are value types. I don't remember any definition of "plain types"
in any specification...

Perhaps you meant "primitive types" however? I don't believe the Java
specification talks about "value types" either - but all primitive
types in Java have the same semantics (aside from boxing etc) as value
types in .NET.

 

[Bjorn Abelli]

Perhaps you meant "primitive types" however? I don't believe
the Java specification talks about "value types" either - but
all primitive types in Java have the same semantics (aside
from boxing etc) as value types in .NET.

Hmm, I think there's a need to clarify some differences in concepts here...

"Primitive types" or "primary types" used to be defined as predefined types
with "fixed" length (as int, char, etc in C or Java), as opposed to
"structure types" (as structs in C) or "object types" (as classes and
structs in .NET).

This has semantically nothing to do with if they are value or reference
types.

"Value types" and "reference types" are connected to the type of the
variables, where the value of a variable in the former case is the actual
value, while the value of a reference type is a *reference* to the value.

In Java only variables for the primitive types can be of value types, while
the rest must be reference types.

In .NET I would rather say that there are *no* primitive types, as int,
char, etc, really are structs, but in .NET all variables for structs are of
value types, while the rest are reference types.

// Bjorn A

 

[Jon Skeet [C# MVP]]

Perhaps you meant "primitive types" however? I don't believe
the Java specification talks about "value types" either - but
all primitive types in Java have the same semantics (aside
from boxing etc) as value types in .NET.

Hmm, I think there's a need to clarify some differences in concepts here...

"Primitive types" or "primary types" used to be defined as predefined types
with "fixed" length (as int, char, etc in C or Java), as opposed to
"structure types" (as structs in C) or "object types" (as classes and
structs in .NET).

I would actually say that primitive types are types which the platform
has special knowledge of. From FOLDOC:

<quote>
A function, operator, or type which is built into a programming
language (or operating system), either for speed of execution or
because it would be impossible to write it in the language. Primitives
typically include the arithmetic and logical operations (plus, minus,
and, or, etc.) and are implemented by a small number of machine
language instructions.
</quote>

Of course, that raises the interesting question of "string" in .NET.
Knowledge of the string class is built into the CLR and IL - but I
wouldn't class it as a primitive.

This has semantically nothing to do with if they are value or reference
types.

True. I don't think it goes against anything I've said, but I agree
it's become a bit muddled.

"Value types" and "reference types" are connected to the type of the
variables, where the value of a variable in the former case is the actual
value, while the value of a reference type is a *reference* to the value.
Yes.

In Java only variables for the primitive types can be of value types, while
the rest must be reference types.
Yes.

In .NET I would rather say that there are *no* primitive types, as int,
char, etc, really are structs, but in .NET all variables for structs are of
value types, while the rest are reference types.

You'd disagree with the Type documentation then.

From Type.IsPrimitive:

<quote>
The primitive types are Boolean, Byte, SByte, Int16, UInt16, Int32,
UInt32, Int64, UInt64, Char, Double, and Single.
</quote>

I'd also take out the word "variables" from your statement - it's not
the variables that are value types, but the types themselves.

 

[Bjorn Abelli]

Bjorn Abelli wrote:

I would actually say that primitive types are types
which the platform has special knowledge of.

Which is what I meant with "predefined types".

[snip]

Of course, that raises the interesting question of
"string" in .NET. Knowledge of the string class is
built into the CLR and IL - but I
wouldn't class it as a primitive.

The same goes for the built in "object".

Which is why the "primitive types" in the definition I referred to only goes
for types with "fixed" length.

You'd disagree with the Type documentation then.

To some degree I do...

I'd also take out the word "variables" from your
statement - it's not the variables that are value
types, but the types themselves.

Well, not really...

It is whether the value of the variable is the actual value, or a reference
to the value, that decides if it's a "value type" or a "reference type". Not
necessarily the type itself.

That it coincides in .NET with structs vs classes as well as in Java with
primitive types vs classes is something else, made for convenience.

If we lift the concepts above the actual languages and platforms it could be
something else. For example, if you define a class or a struct in C++, they
are by themselves neither value nor reference types.

// Bjorn A

 

[Jon Skeet [C# MVP]]

It is whether the value of the variable is the actual value, or a reference
to the value, that decides if it's a "value type" or a "reference type". Not
necessarily the type itself.

I disagree. If you're talking about boxing etc, then there are actually
two types for each value type: there's the value type itself and the
reference type. An object has a type regardless of whether it's in a
variable somewhere or not.

That it coincides in .NET with structs vs classes as well as in Java with
primitive types vs classes is something else, made for convenience.

If we lift the concepts above the actual languages and platforms it could be
something else. For example, if you define a class or a struct in C++, they
are by themselves neither value nor reference types.

If it's a .NET type then it is deinitely one or the other though. I
believe this is one of those topics where it doesn't make sense to talk
details without reference to the particular platform involved.

 

[Bjorn Abelli]

Bjorn Abelli wrote:

I disagree. If you're talking about boxing etc, then
there are actually two types for each value type: there's
the value type itself and the reference type.
An object has a type regardless of whether it's in a
variable somewhere or not.

Yes, I agree to the latter, but *conceptually* it's better to not refer to
this as being a "value" or "reference" type.

I actually didn't think of boxing per se, but that rather confirms my
definitions, as the type of the instance is one thing, the type of the
variable is another, where the type of the variable can be a "value" or
"reference" type, regardless of which type the actual instance is.

If it's a .NET type then it is definitely one or the other
though. I believe this is one of those topics where it
doesn't make sense to talk details without reference
to the particular platform involved.

I think you're only partially right here...

My point was taken with consideration for the OP where he actually wanted to
know the *difference* between two platforms.

When we *compare* the behavior between different languages/platforms I think
it's necessary to lift the concepts to their common definitions *above* the
platforms first, to make it possible to *then* go down to the differences in
how they are implemented and used in each platform.

// Bjorn A

 

[Jon Skeet [C# MVP]]

Yes, I agree to the latter, but *conceptually* it's better to not refer to
this as being a "value" or "reference" type.

I still disagree, I'm afraid - tying types to variables leaves awkward
conceptual holes for things like intermediate expressions, eg
o.GetType().ToString() where there may be no variables involved for the
middle part (which is definitely still of type Type, as far as the
expression is concerned).

I actually didn't think of boxing per se, but that rather confirms my
definitions, as the type of the instance is one thing, the type of the
variable is another, where the type of the variable can be a "value" or
"reference" type, regardless of which type the actual instance is.

Certainly variables *do* have a type, but your original post implied
(to me, anyway) that you *had* to be considering a variable in order to
talk about type. A variable's value can have a different type to the
variable, of course:

object o = "string";

The type of o is object; the type of its value is (reference to)
string.

I think you're only partially right here...

My point was taken with consideration for the OP where he actually wanted to
know the *difference* between two platforms.

When we *compare* the behavior between different languages/platforms I think
it's necessary to lift the concepts to their common definitions *above* the
platforms first, to make it possible to *then* go down to the differences in
how they are implemented and used in each platform.

Certainly there are things we can make common definitions for. For
instance, it makes sense to define value type and reference type in a
way which is consistent between Java and C#. The fact that in C++ a
type isn't necessarily either doesn't make that concept useless -
unless you're trying to talk about C++!

 

[Bjorn Abelli]

Bjorn Abelli wrote:

I still disagree, I'm afraid - tying types to variables
leaves awkward conceptual holes for things like intermediate
expressions, eg o.GetType().ToString() where there may be
no variables involved for the middle part (which is
definitely still of type Type, as far as the expression
is concerned).

Well, you have a point there, but it rather points out the need to differ
between the types of the actual instances, and whether the types of
variables or intermediate expressions are value or reference types.

Certainly variables *do* have a type, but your original post implied
(to me, anyway) that you *had* to be considering a variable in order to
talk about type.

My fault! I thought it would be easier to clarify the concepts by using the
difference of types of the actual instances vs the types of variables, but
of course intermediate expressions also falls into the latter category.

But I think I have made my point by now.

// Bjorn A

 

[Jon Skeet [C# MVP]]

Well, you have a point there, but it rather points out the need to differ
between the types of the actual instances, and whether the types of
variables or intermediate expressions are value or reference types.
Agreed.


My fault! I thought it would be easier to clarify the concepts by using the
difference of types of the actual instances vs the types of variables, but
of course intermediate expressions also falls into the latter category.

But I think I have made my point by now.

Yes, I think we're there now. It's not been in vain, btw - I'll try to
remember to include the difference between "declared type" (or possibly
"compile-time type") and "actual type" when I finally get round to
writing a simple explanation of the difference between value types and
reference types... (It's been on my list for a while...)