The necessity of struct

  • Thread starter Thread starter phoenix
  • Start date Start date
P

phoenix

Structs are allocated on the stack while classes are allocated on the heap.
(De)allocations on the stack of objects is faster. However the objects
should be rather small (eg Person {firstname, lastname}) since stacksize is
limited.
Structs are value types while classes are reference types.
Structs have no destructors.

Yves
 
Hi,

What's the reasoning of having struct in .Net? Since they hardly differ with
classes? Are there any advantages using struct instead of classes?

Thanks
 
wesley said:
What's the reasoning of having struct in .Net? Since they hardly differ with
classes? Are there any advantages using struct instead of classes?
Click to expand...

I disagree with your idea that they "hardly differ" from classes - they
are value types instead of reference types, which makes a huge
difference in semantics.

As to why they're present at all - interop pretty much requires them,
for a start. (This is one reason Java can get away with just classes
and Java-defined primitives - it doesn't have the same kind of interop
capabilities as .NET.)
 
What's the reasoning of having struct in .Net? Since they hardly differ
with
I disagree with your idea that they "hardly differ" from classes - they
are value types instead of reference types, which makes a huge
difference in semantics.

As to why they're present at all - interop pretty much requires them,
for a start. (This is one reason Java can get away with just classes
and Java-defined primitives - it doesn't have the same kind of interop
capabilities as .NET.)
Click to expand...

You can use Java to call native dll functions. I'm not quiet sure how the
internal works, but I've written Java apps that do office automation using
Jawin. Is the Interop the main reason for struct? Or are there other
significant reasons?

Thanks,

wes
 
wesley said:
You can use Java to call native dll functions.
Click to expand...

Yes, via JNI. However, that's significantly harder than .NET where you
can just directly call DLL functions - you don't need to write wrapper
libraries in C/C++.
I'm not quiet sure how the
internal works, but I've written Java apps that do office automation using
Jawin.
Click to expand...

Yup - you have to use another product in order to make the interop
easier.
Is the Interop the main reason for struct? Or are there other
significant reasons?
Click to expand...

Well, my own feeling is that interop is the main reason for structs,
but I couldn't say for sure that that was what the designers had in
mind.
 
Jon Skeet said:
Yes, via JNI. However, that's significantly harder than .NET where you
can just directly call DLL functions - you don't need to write wrapper
libraries in C/C++.


Yup - you have to use another product in order to make the interop
easier.


Well, my own feeling is that interop is the main reason for structs,
but I couldn't say for sure that that was what the designers had in
mind.
Click to expand...

Interop is a good reason, perhaps a primary reason, but I think that there
is enough value to justify structures even if interop was non-existant. Its
less common for some, I suppose, but it permits considerable flexibility
which you wouldnt have access to without structures, most notably C#
pointers(which you can treat like C\C++ pointers over a byte array, read in
the array and map the structure over it; this should get a big boost with
the fixed keyword in C# 2.0) and real value semantics for types that need it
rather than immutability and cloning, especially since there is no way to
create copy-on-write semantics other than by using structs or explicit clone
passing(last thing I want is a byclone calling convention).
Value semantics and stack\class inline allocation are rather valuable
things, IMHO. You could go the route that C++ seems to be going for whidbey
and find a way to allocate reference types on the stack, but I think that
would be adding needless complexity to the language(not sure how it works
all in all, I just don't think it fits the C# model. I'm also not sure how
they are passed to non C++ methods) without adding much of the value.
 
As to why they're present at all - interop pretty much requires them,
Interop is a good reason, perhaps a primary reason, but I think that there
is enough value to justify structures even if interop was non-existant. Its
less common for some, I suppose, but it permits considerable flexibility
which you wouldnt have access to without structures, most notably C#
pointers(which you can treat like C\C++ pointers over a byte array, read in
the array and map the structure over it; this should get a big boost with
the fixed keyword in C# 2.0) and real value semantics for types that need it
rather than immutability and cloning, especially since there is no way to
create copy-on-write semantics other than by using structs or explicit clone
passing(last thing I want is a byclone calling convention).
Value semantics and stack\class inline allocation are rather valuable
things, IMHO. You could go the route that C++ seems to be going for whidbey
and find a way to allocate reference types on the stack, but I think that
would be adding needless complexity to the language(not sure how it works
all in all, I just don't think it fits the C# model. I'm also not sure how
they are passed to non C++ methods) without adding much of the value.
Click to expand...

Strange that the syntax for using struct and classes are exactly the same.
At a glance people could have mistaken a struct for a class, until either
people read the documentation or the compiler informs you that you can't set
a struct to null. Perhaps if the syntax is different clearly identify which
one is which that will probably be better, IMO.

wes
 
wesley said:
Strange that the syntax for using struct and classes are exactly the same.
Click to expand...

Not really - it's called consistency.
At a glance people could have mistaken a struct for a class, until either
people read the documentation or the compiler informs you that you can't set
a struct to null. Perhaps if the syntax is different clearly identify which
one is which that will probably be better, IMO.
Click to expand...

If you use any type without reading its documentation, you're bound to
run into trouble. The information is available at a glance in the docs,
even in the MSDN index (it will say Foo structure instead of Foo class)
if it's a framework structure. In the overview, a struct will always
derive from ValueType, whereas a reference type never will.

I can't remember ever mistaking a reference type for a value type or
vice versa.
 
Back
Top