Structures and Classes

[Ken Allen]

OK, I admit that I have been programming since before C++ was invented,
and I have developed more than my share of assembly language systems,
and even contributed to operating system and compiler systems over the
years. I have developed code in more than 30 distinct programming
languages for a wide cariety of industries. But this issue of structures
in C# is beginning to annoy me.

I should also make it clear that I am not a big supporter of the C++
convention that the only difference between a class and a structure is
whether or not the data members, private or otherwise, can be treated as
a single entity. I have made strong cases in C++ code for the structure
to be a data member of a class, not make the member functions part of
the structure.

There are times when a structure is extemely useful, however, such as
when communicating with an exising applicaiton or file that stores its
data in a specific layout that is well defined using a C++ structure.

I have been using C# for some time now, and I must admit that I find the
language a significant improvement over C++ (aside from speed at times).
I especially like how enumerations are a part of the language - I
believe the C# approach to be far better than the C/C++ approach (not
claiming this approach is unique to C#). But this issue of structures
vs. classes keeps raising its head.

I sometimes write code, in the form of services, that must communicate
with custom device drivers, often passing the control structures in
predefined record layouts. In C++ these are simple structures, and I
have been using the same in C# most of the time -- except where the
structures are not simple, and it became much easier to define a class
with MarshalIn() and MarshalOut() methods that transfer the data members
sequentially. This is especially true when some of the structures nest
other structures several levels deep.

The one thing that bothers me the most is this concept that a structure
is a 'value' type and a class is an object type. This means that there
are certain times when passing structures around in code rquires
'boxing' or other special steps, or it cannot be done cleanly.

What happens in C# when I define a class that has a structure as its
data member (perhaps its only data member)? The structure is still
allocated on the stack, as opposed to from the heap, and so there would
still appear to be some problems with passing things around.

I am coming to the conclusion that the usefullness of structures in C#
is very limited and effective only in isolated cases. It would seem that
the main C# code should always use classes with atomic data members, and
either create and use the structure only as part of I/O operations (some
overhead in the creation and population of the structure), or use custom
Marshal methods to deal with each atomic field on its own. The style of
defining a structure to be used as a single I/O or parameter object and
then adding methods to the structure definition so it also appears to be
a class is not something good or effective in C# (although some C++ code
I have encountered relies heavily on this approach).

Am I wrong here? Have I missed something?

-ken

[Nicholas Paldino [.NET/C# MVP]]

Ken,

At times I agree with you on this. It depends on the situation though.
For example, I see Point and Size as being really basic types which don't
need class semantics, and should be treated as value types. However, I
don't see many other uses (except in the case where you want to implement a
rollback mechanism of some kind, and implement IDisposable on the structure,
and use that to perform rollback operations in a using statement, and don't
want to allocate an object on the heap to do this).

There is one part of your post that is incorrect. You state:

What happens in C# when I define a class that has a structure as its
data member (perhaps its only data member)? The structure is still
allocated on the stack, as opposed to from the heap, and so there would
still appear to be some problems with passing things around.

When you have a field in a class that is a value type, that value type
is not copied on the stack. The memory for that value type is in the memory
taken up by the class instance itself, and moves where the instance moves.
It's the same as having a field of type int or bool, it's just part of the
type.

Basically, what it comes down to is you use structures in your
programming where you feel copy-on-assignment semantics are appropriate.

Hope this helps.

--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"Ken Allen" <ke******@sympatico.ca> wrote in message
news:uu*************@TK2MSFTNGP15.phx.gbl...

OK, I admit that I have been programming since before C++ was invented,
and I have developed more than my share of assembly language systems, and
even contributed to operating system and compiler systems over the years.
I have developed code in more than 30 distinct programming languages for a
wide cariety of industries. But this issue of structures in C# is
beginning to annoy me.

I should also make it clear that I am not a big supporter of the C++
convention that the only difference between a class and a structure is
whether or not the data members, private or otherwise, can be treated as a
single entity. I have made strong cases in C++ code for the structure to
be a data member of a class, not make the member functions part of the
structure.

There are times when a structure is extemely useful, however, such as when
communicating with an exising applicaiton or file that stores its data in
a specific layout that is well defined using a C++ structure.

I have been using C# for some time now, and I must admit that I find the
language a significant improvement over C++ (aside from speed at times). I
especially like how enumerations are a part of the language - I believe
the C# approach to be far better than the C/C++ approach (not claiming
this approach is unique to C#). But this issue of structures vs. classes
keeps raising its head.

I sometimes write code, in the form of services, that must communicate
with custom device drivers, often passing the control structures in
predefined record layouts. In C++ these are simple structures, and I have
been using the same in C# most of the time -- except where the structures
are not simple, and it became much easier to define a class with
MarshalIn() and MarshalOut() methods that transfer the data members
sequentially. This is especially true when some of the structures nest
other structures several levels deep.

The one thing that bothers me the most is this concept that a structure is
a 'value' type and a class is an object type. This means that there are
certain times when passing structures around in code rquires 'boxing' or
other special steps, or it cannot be done cleanly.

What happens in C# when I define a class that has a structure as its data
member (perhaps its only data member)? The structure is still allocated on
the stack, as opposed to from the heap, and so there would still appear to
be some problems with passing things around.

I am coming to the conclusion that the usefullness of structures in C# is
very limited and effective only in isolated cases. It would seem that the
main C# code should always use classes with atomic data members, and
either create and use the structure only as part of I/O operations (some
overhead in the creation and population of the structure), or use custom
Marshal methods to deal with each atomic field on its own. The style of
defining a structure to be used as a single I/O or parameter object and
then adding methods to the structure definition so it also appears to be a
class is not something good or effective in C# (although some C++ code I
have encountered relies heavily on this approach).

Am I wrong here? Have I missed something?

-ken

[Dmytro Lapshyn [MVP]]

Hello Ken,

You can find this discussion of some interest (mind the line wraps):

http://groups-beta.google.com/group/...cd85ecd5de4862

--
Sincerely,
Dmytro Lapshyn [Visual Developer - Visual C# MVP]
"Ken Allen" <ke******@sympatico.ca> wrote in message
news:uu*************@TK2MSFTNGP15.phx.gbl...

OK, I admit that I have been programming since before C++ was invented,
and I have developed more than my share of assembly language systems, and
even contributed to operating system and compiler systems over the years.
I have developed code in more than 30 distinct programming languages for a
wide cariety of industries. But this issue of structures in C# is
beginning to annoy me.

I should also make it clear that I am not a big supporter of the C++
convention that the only difference between a class and a structure is
whether or not the data members, private or otherwise, can be treated as a
single entity. I have made strong cases in C++ code for the structure to
be a data member of a class, not make the member functions part of the
structure.

There are times when a structure is extemely useful, however, such as when
communicating with an exising applicaiton or file that stores its data in
a specific layout that is well defined using a C++ structure.

I have been using C# for some time now, and I must admit that I find the
language a significant improvement over C++ (aside from speed at times). I
especially like how enumerations are a part of the language - I believe
the C# approach to be far better than the C/C++ approach (not claiming
this approach is unique to C#). But this issue of structures vs. classes
keeps raising its head.

I sometimes write code, in the form of services, that must communicate
with custom device drivers, often passing the control structures in
predefined record layouts. In C++ these are simple structures, and I have
been using the same in C# most of the time -- except where the structures
are not simple, and it became much easier to define a class with
MarshalIn() and MarshalOut() methods that transfer the data members
sequentially. This is especially true when some of the structures nest
other structures several levels deep.

The one thing that bothers me the most is this concept that a structure is
a 'value' type and a class is an object type. This means that there are
certain times when passing structures around in code rquires 'boxing' or
other special steps, or it cannot be done cleanly.

What happens in C# when I define a class that has a structure as its data
member (perhaps its only data member)? The structure is still allocated on
the stack, as opposed to from the heap, and so there would still appear to
be some problems with passing things around.

I am coming to the conclusion that the usefullness of structures in C# is
very limited and effective only in isolated cases. It would seem that the
main C# code should always use classes with atomic data members, and
either create and use the structure only as part of I/O operations (some
overhead in the creation and population of the structure), or use custom
Marshal methods to deal with each atomic field on its own. The style of
defining a structure to be used as a single I/O or parameter object and
then adding methods to the structure definition so it also appears to be a
class is not something good or effective in C# (although some C++ code I
have encountered relies heavily on this approach).

Am I wrong here? Have I missed something?

-ken

[Ken Allen]

Nicholas Paldino [.NET/C# MVP] wrote:

Ken,

At times I agree with you on this. It depends on the situation though. <snip/> Basically, what it comes down to is you use structures in your
programming where you feel copy-on-assignment semantics are appropriate.

Hope this helps.

Yes, this is the basic conclustion that I was coming to (thank you for
the correction on the structure as a class data member; I had meant to
pose that more as a question).

I do see value of wrapping the structure inside a class when the
structure contents are to be used as part of communication with another
component, permitting the buffer to be read and written as a unit
(although marshalling may still be involved).

My problems lie in the fact that 90% of the projects I consider deal
with communication with existing (unmanaged) components, and when the
component is in the kernel, I am forced to use unmanaged Win32 API calls
(DeviceIoControl), which means marshalling is involved in one manner or
another.

This is where I am forced to selected between marshalling a structure or
marshalling the individual data members themselves. Writing interop code
is not somthing Visual Studio makes easier!

-ken

[Jon Skeet [C# MVP]]

Ken Allen <ke******@sympatico.ca> wrote:

<snip>

What happens in C# when I define a class that has a structure as its
data member (perhaps its only data member)? The structure is still
allocated on the stack, as opposed to from the heap, and so there would
still appear to be some problems with passing things around.
No, that's not true. The idea that value types always end up on the
stack is a mistake due to people being lazy when trying to explain what
goes where.

See http://www.pobox.com/~skeet/csharp/memory.html
I am coming to the conclusion that the usefullness of structures in C#
is very limited and effective only in isolated cases.
Pretty limited, yes - basically where you really need a value type,
which is pretty rarely given that many useful ones are already in the
framework.

I don't see why that's a problem though - it's just not the same as how
C/C++ viewed structures.
It would seem that
the main C# code should always use classes with atomic data members, and
either create and use the structure only as part of I/O operations (some
overhead in the creation and population of the structure), or use custom
Marshal methods to deal with each atomic field on its own. The style of
defining a structure to be used as a single I/O or parameter object and
then adding methods to the structure definition so it also appears to be
a class is not something good or effective in C# (although some C++ code
I have encountered relies heavily on this approach).

In what way does adding methods to the structure make it "appear to be
a class"? You need to forget the concept that structures are for data
only - the difference between structures and classes is just that
structures are value types and classes are reference types.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Nicholas Paldino [.NET/C# MVP]]

Ken,

You know you can marshal classes, right? You don't ^have^ to use
structures. You can apply the marshaling attributes to a class and it
should work. There are some slight differences, but for the most part, it
works.

--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"Ken Allen" <ke******@sympatico.ca> wrote in message
news:uO**************@TK2MSFTNGP14.phx.gbl...

Nicholas Paldino [.NET/C# MVP] wrote:

Ken,

At times I agree with you on this. It depends on the situation
though.

<snip/>

Basically, what it comes down to is you use structures in your
programming where you feel copy-on-assignment semantics are appropriate.

Hope this helps.

Yes, this is the basic conclustion that I was coming to (thank you for the
correction on the structure as a class data member; I had meant to pose
that more as a question).

I do see value of wrapping the structure inside a class when the structure
contents are to be used as part of communication with another component,
permitting the buffer to be read and written as a unit (although
marshalling may still be involved).

My problems lie in the fact that 90% of the projects I consider deal with
communication with existing (unmanaged) components, and when the component
is in the kernel, I am forced to use unmanaged Win32 API calls
(DeviceIoControl), which means marshalling is involved in one manner or
another.

This is where I am forced to selected between marshalling a structure or
marshalling the individual data members themselves. Writing interop code
is not somthing Visual Studio makes easier!

-ken

[Ken Allen]

Nicholas Paldino [.NET/C# MVP] wrote:

Ken,

You know you can marshal classes, right? You don't ^have^ to use
structures. You can apply the marshaling attributes to a class and it
should work. There are some slight differences, but for the most part, it
works.

Is one assured of the order in which data members in a class will be
marhalled? One of the benefits of using a structure marked as sequential
layout is that one is assured bf the byte ordering for the marshalling.
It is not intuitive that a class would marshal as cleanly, especially
when the data memebers are strings or other reference objects - it would
seem that a 'field by field' marshalling procedure would be more
effective (but more coding effort?).

-ken