Class or structure for array.

[Qwert]

Hello,

if you have an array with some class as element type and a same sized array
with some structure as element type, and that class and structure have the
same fields (for example 10 integers), is it correct to assume that the
array with the classes uses less memory (than the array with structures)
before the objects are initialized (X bytes per object) and uses more memory
after all the objects are initialized (same fields + X bytes per object) ?

Thanks.

 

[Herfried K. Wagner [MVP]]

if you have an array with some class as element type and a same sized
array with some structure as element type, and that class and structure
have the same fields (for example 10 integers), is it correct to assume
that the array with the classes uses less memory (than the array with
structures) before the objects are initialized (X bytes per object) and
uses more memory after all the objects are initialized (same fields + X
bytes per object) ?

An array of structures uses more memory than an array of class instances
whose items point to 'Nothing'.

 

[Lucky]

hi Qwert,
i'm agree with Herfried. structure is a user definded data type just
like class but the difference is structure doesnt required to be
instanciated. thus structure objects are maintaining references on
stack memory unlike classes those maintaines references in heap memory.
stack memory is limited in comparison of heap memory so that structures
occupies more memory in stack when they get references. that's why
structure is quite costlier than class.

there are more reasons related to memory but to cut the story in short,
structure eats lots of memory when they get instanciated.

 

[Mattias Sjögren]

thus structure objects are maintaining references on stack memory

I'm not sure exactly what you mean by that, but there are no
references involved for value types (Structures). And when you have an
array of the structure the elements are heap allocated inline in the
array object, not on the stack.

structure eats lots of memory when they get instanciated.

They "eat" exactly the size of their members (plus padding for
alignment), no more and no less. Compared to classes where you have a
small per-object overhead, they are quite cheap.


Mattias

 

[Cor Ligthert [MVP]]

Mattias,
to stack memory,

I have not in any way a problem with the simple way Lucky describes it, is
it in fact not true than it is in my opinion in sense true to show what is
the difference.

If you have a car that uses petrol, than the motor is not going on petrol,
than it is on air mixed with vaporized petrol. You will probably never say
that.

Just my opinion,

Cor

 

[m.posseth]

Structures are also much faster to access


here is some more info regarding structures vs classes


the official reading materiall

http://msdn.microsoft.com/library/d...n-us/vbcn7/html/vaconstructuresandclasses.asp

and a verry clear explanation

http://www.devcity.net/Articles/79/practical_oop_1.aspx


regards

Michel Posseth [MCP]

 

[Cor Ligthert [MVP]]

Michel,

Structures are also much faster to access

That is as long as there is programming.

Everything direct to reference on stack zero (or used stack) is the much
fast to use.

Cor

 

[Cor Ligthert [MVP]]

most or whatever



Cor

 

[Armin Zingler]

Michel,



That is as long as there is programming.

Everything direct to reference on stack zero (or used stack) is the
much fast to use.

Cor, what is stack zero or used stack?


Armin

 

[Cor Ligthert [MVP]]

Armin,

Just a freedom of speech, I mean the main part of the program when you look
at the located memory.

However it can be of course forever for any stack after that.

Main(0)
Stack(1)
Stack(1,1)
Stack(2)
End

However be aware that we here are talking about thousends of nanoseconds.

Cor

 

[Qwert]

Thank you all.

 

[Armin Zingler]

Armin,

Just a freedom of speech, I mean the main part of the program when
you look at the located memory.

However it can be of course forever for any stack after that.

Main(0)
Stack(1)
Stack(1,1)
Stack(2)
End

However be aware that we here are talking about thousends of
nanoseconds.

What is this above? Maybe there is something I don't know. I only know that
each thread has it's stack linearily being filled from end to start.


Armin

 

[Cor Ligthert [MVP]]

Armin,

I can be as well that I misinterpret it, however for me the working from a
stack has always been this

Main,
Call method1
means stack(1) is opened
In stack 1 is callex method x
means stack (1.2) is opened, if 1.2 exits it returns in (1)
at the next program addres (stack 1.2 becomes unreachable)
If stack 1 ends than it goes on tho the next program address in
main.

This has nothing to do with the way a program is written by the way the
methods can be called everywhere.

However if it is not done in this way in Net than it is my misunderstanding.
As you probably always have seen, I am not so much interested in *how* the
program acts under the hood. It cost tons of time and you gain in my opinion
mostly nothing with it. I assume that those who did their job doing this for
us, did the right job. It is bad enough if you have to go deeper because of
a lack of documentation.

Just my opinion about that of course.

Cor

 

[Armin Zingler]

Cor,

the stack is a linear piece of memory. Every location on the stack can be
accessed directly. It's only an offset that has to be added when accessing a
specific item. The value that is added has no impact on the speed, just like
the time is the same if you access b(17) or b(50) in an array.


Armin

 

[Cor Ligthert [MVP]]

Armin,

the stack is a linear piece of memory. Every location on the stack can be
accessed directly. It's only an offset that has to be added when accessing
a specific item. The value that is added has no impact on the speed, just
like the time is the same if you access b(17) or b(50) in an array.

After that I had sent it, I was realising me that. That was why I wrote
thousands of nanoseconds to you in a previous message.

AFAIK cost adding zero to a register less time than adding a million (there
is not any overload to catch). However very very very very very less time.



Not needed to reply, you are right.

Cor