Memory (Structure vs Class) 
Author Message
 Memory (Structure vs Class)

I'm trying to determine which way to go.  With a structure (Vb type)
I can control the memory allocation.  For example:

MyType
    arrSomeData1()
    arrSomeData(2)
End Type

In the above if the structure is used, but only arrSomeData(2) is
dimensioned, then then memory for arrSomeData(1) is never allocated.

==================

Can the same thing be accomplished within a class?
My guess is you would have to declare the arrays within the class and then
use a property to dimension the array when needed.



Sun, 15 Jan 2012 21:40:02 GMT  
 Memory (Structure vs Class)


Quote:
> I'm trying to determine which way to go.  With a structure (Vb type)
> I can control the memory allocation.  For example:

> MyType
>     arrSomeData1()
>     arrSomeData(2)
> End Type

> In the above if the structure is used, but only arrSomeData(2) is
> dimensioned, then then memory for arrSomeData(1) is never allocated.

> ==================

> Can the same thing be accomplished within a class?
> My guess is you would have to declare the arrays within the class and then
> use a property to dimension the array when needed.

As far as any "Array Allocation" goes there need not be any special
differences between the two strategies. The obvious example would be a VB
Class which simply used the UDT for its local storage.

Within context there is little difference between a UDT or Class - they are
both "types". You would chose one over the other for other reasons.

-ralph



Sun, 15 Jan 2012 22:04:48 GMT  
 Memory (Structure vs Class)
Ralph:

Thanks for response

Quote:
>>You would chose one over the other for other reasons.

Never seen a list of reasons why one vs other.
Can you shed some light?


Quote:



>> I'm trying to determine which way to go.  With a structure (Vb type)
>> I can control the memory allocation.  For example:

>> MyType
>>     arrSomeData1()
>>     arrSomeData(2)
>> End Type

>> In the above if the structure is used, but only arrSomeData(2) is
>> dimensioned, then then memory for arrSomeData(1) is never allocated.

>> ==================

>> Can the same thing be accomplished within a class?
>> My guess is you would have to declare the arrays within the class and
>> then
>> use a property to dimension the array when needed.

> As far as any "Array Allocation" goes there need not be any special
> differences between the two strategies. The obvious example would be a VB
> Class which simply used the UDT for its local storage.

> Within context there is little difference between a UDT or Class - they
> are
> both "types". You would chose one over the other for other reasons.

> -ralph



Sun, 15 Jan 2012 22:33:10 GMT  
 Memory (Structure vs Class)


Quote:

> >>You would chose one over the other for other reasons.

> Never seen a list of reasons why one vs other.
> Can you shed some light?

The UDT is a static list of variables.  You get what you pay for.
If any need validation, or other modifications, you have to add
code to do that here, there, and everywhere.

The class is encapsulated data.  Validations and modifications can
be added once to the class, and get applied to all who use the class.

UDTs are good for passing and persisting related data.  For any
other use beyond that, consider using a class....

LFS



Sun, 15 Jan 2012 23:35:30 GMT  
 Memory (Structure vs Class)
As I recall, I believe classes grew out of structures in an attempt to
link the data with the variables that refer to or use the data.

Also from a memory perspective (based on my internet reading for NET --  
haven't found anything for VB Classic)  that classes are referenced on the
heap while structures would be the stack unless declared global.

I was always taught to go to lowest level -- hence stack would be better.
Whether just the class reference goes on the heap and the class itself is
handled on the stack is unknown (to me).

Whether any of this means a hoot with the amount of memory today also is
unknown.


Quote:


>> >>You would chose one over the other for other reasons.

>> Never seen a list of reasons why one vs other.
>> Can you shed some light?

> The UDT is a static list of variables.  You get what you pay for.
> If any need validation, or other modifications, you have to add
> code to do that here, there, and everywhere.

> The class is encapsulated data.  Validations and modifications can
> be added once to the class, and get applied to all who use the class.

> UDTs are good for passing and persisting related data.  For any
> other use beyond that, consider using a class....

> LFS



Mon, 16 Jan 2012 00:01:46 GMT  
 Memory (Structure vs Class)


Quote:
> As I recall, I believe classes grew out of structures in an attempt to
> link the data with the variables that refer to or use the data.

I suppose you could put it that way. It is more useful however to consider
both as just 'programming constructs' to create a block of memory with
addressable (is that a word? lol) elements. Such a block of memory which is
treated as a single "thingy" is referred to as a "Type".

Bundling a bunch of related variables into one package and passing that
around instead of all the separate variables is obviously very convenient.
The WinAPI makes use of several structures. In order for VB to work with the
WinAPI and other published APIs - VB provides a construct to create such
blocks of memory by declaring UDTs. (They could have just called them
"structs", but since VB is an OOPL they opted for the more 'OO' term of
"User-defined Types".)

OOPLs introduced the concept of Objects and then respectively a programming
construct to create them. That construct is called a 'Class'. In
implementation (down at the dirty little level of 1s and ohs) there is no
difference between a struct and an object. The end result is a block of
memory with addressable elements.

Objects are often considered different because they can have methods. But
actually so can structs (Easier to accomplish in C than VB, but possible.)
The major difference is as Larry pointed out - creating objects (by using
the Class construct) makes it easier for a programmer to build OO solutions
(data hiding, polymorphism, etc.).

Quote:

> Also from a memory perspective (based on my internet reading for NET --
> haven't found anything for VB Classic)  that classes are referenced on the
> heap while structures would be the stack unless declared global.

That is pretty much language and development platform dependent, and of
course context. In VB UDTs could be on the stack, in a data segment, or even
on the heap - all depends on where they are declared and or how they are
used.

In VB objects can only be declared on the heap. Other languages allow for
the same versatility as for structs.

 > I was always taught to go to lowest level -- hence stack would be better.

Quote:
> Whether just the class reference goes on the heap and the class itself is
> handled on the stack is unknown (to me).

> Whether any of this means a hoot with the amount of memory today also is
> unknown.

In general, use the construct that makes the most logical sense for the
solution. "Pre-optimizing" while developing a program (other than simple
common sense) is a distraction and often a waste of time.

Most of the time, when you are using an OOPL and have identified a bundle of
associated 'values' - you usually have a Type and a Type usually means an
Object.

-ralph



Mon, 16 Jan 2012 02:18:02 GMT  
 Memory (Structure vs Class)
Thanks for the input Ralph.  Helped clear up a few things

Quote:
> In VB objects can only be declared on the heap.

So, does the reference just reside on the heap or is the entire class
(property, methods, etc.) all on the heap?

If all on heap, ever run out of heap space?

David


Quote:



>> As I recall, I believe classes grew out of structures in an attempt to
>> link the data with the variables that refer to or use the data.

> I suppose you could put it that way. It is more useful however to consider
> both as just 'programming constructs' to create a block of memory with
> addressable (is that a word? lol) elements. Such a block of memory which
> is
> treated as a single "thingy" is referred to as a "Type".

> Bundling a bunch of related variables into one package and passing that
> around instead of all the separate variables is obviously very convenient.
> The WinAPI makes use of several structures. In order for VB to work with
> the
> WinAPI and other published APIs - VB provides a construct to create such
> blocks of memory by declaring UDTs. (They could have just called them
> "structs", but since VB is an OOPL they opted for the more 'OO' term of
> "User-defined Types".)

> OOPLs introduced the concept of Objects and then respectively a
> programming
> construct to create them. That construct is called a 'Class'. In
> implementation (down at the dirty little level of 1s and ohs) there is no
> difference between a struct and an object. The end result is a block of
> memory with addressable elements.

> Objects are often considered different because they can have methods. But
> actually so can structs (Easier to accomplish in C than VB, but possible.)
> The major difference is as Larry pointed out - creating objects (by using
> the Class construct) makes it easier for a programmer to build OO
> solutions
> (data hiding, polymorphism, etc.).

>> Also from a memory perspective (based on my internet reading for NET --
>> haven't found anything for VB Classic)  that classes are referenced on
>> the
>> heap while structures would be the stack unless declared global.

> That is pretty much language and development platform dependent, and of
> course context. In VB UDTs could be on the stack, in a data segment, or
> even
> on the heap - all depends on where they are declared and or how they are
> used.

> In VB objects can only be declared on the heap. Other languages allow for
> the same versatility as for structs.

> > I was always taught to go to lowest level -- hence stack would be
> > better.
>> Whether just the class reference goes on the heap and the class itself is
>> handled on the stack is unknown (to me).

>> Whether any of this means a hoot with the amount of memory today also is
>> unknown.

> In general, use the construct that makes the most logical sense for the
> solution. "Pre-optimizing" while developing a program (other than simple
> common sense) is a distraction and often a waste of time.

> Most of the time, when you are using an OOPL and have identified a bundle
> of
> associated 'values' - you usually have a Type and a Type usually means an
> Object.

> -ralph



Mon, 16 Jan 2012 03:18:17 GMT  
 Memory (Structure vs Class)


Quote:
> Thanks for the input Ralph.  Helped clear up a few things

> > In VB objects can only be declared on the heap.

> So, does the reference just reside on the heap or is the entire class
> (property, methods, etc.) all on the heap?

[Note: what follows is a 10,000 foot view. There are chapters, articles, and
even whole books written on the subject.]

VB uses COM protocol for objects. Thus in VB an 'object reference' is
actually a reference to an Interface. It is a pointer to block of
information that is 16 or 32 bytes(?). (I think the later, but brain not
working at the moment. I'm sure someone will quickly correct me. ha)

With COM, components are published with an Interface - can be viewed as a
simple list of what is available - and then a coClass or actual object that
can service that interface.

So looking at the simple case of a local Class defined in VB.

    Dim cls As Class1    ' this declares and defines a block of memory (that
16/32 byte thingy) that provides information on what kind of coClass is
needed.
It resides in the program text section or data section depending where used.

    Set cls = New Class1

The object that is specificied in the reference is now created and a block
of memory which is essentially a vtable or struct containing the available
attributes or methods is created on the heap.

The code for this object is in the program text section and is only loaded
once or as needed, ie, if you have had 100 Class1 objects open - you would
have 100 blocks of the Class1 Interface reference info and Class1's private
data created on the heap - but that would be it.

Or look at it another way ...
Two classes (clsA and clsB) with identical interfaces and identical storage,
but clsA has very short methods with little code, while clsB has methods
that contain lines and lines of code.

With the exception that clsB methods may require more stack space for
automatic variables (when those methods are running/called). The 'heap' or
memory requirement would be identical.

Quote:

> If all on heap, ever run out of heap space?

Sure - even with VMM all memory is essentially limited at some point - to
the total ram and hd space available. Memory per se is seldom a problem with
the massive creation of VB objects. Usually a program or system runs out of
"resources" (file sizes, string sizes, GDIs, handles, etc.) long before it
ever actually runs out of "memory". The real problem is usually, because of
the redirected way VB manages objects, with it becoming horribly slow.

-ralph



Mon, 16 Jan 2012 04:07:51 GMT  
 Memory (Structure vs Class)



Quote:
> Thanks for the input Ralph.  Helped clear up a few things

> > In VB objects can only be declared on the heap.

> So, does the reference just reside on the heap or is the
> entire class (property, methods, etc.) all on the heap?

The instance-data (including the pointer to the VTable) is
all on the heap.
The Properties and Methods reside "in your Binary", which is
already loaded into Memory and then only jumped to.

Quote:
> If all on heap, ever run out of heap space?

No, it's more likely to run out of stack-space than
to run "out of heap".

Olaf



Mon, 16 Jan 2012 08:24:38 GMT  
 Memory (Structure vs Class)
Thanks Ralph and Mr. Schmidt.

Really helped.  I see I need to track down a book or two (if I can find one
on classic VB anyone).

Consider this thread closed.
Have a nice day.

David.


Quote:



>> Thanks for the input Ralph.  Helped clear up a few things

>> > In VB objects can only be declared on the heap.

>> So, does the reference just reside on the heap or is the
>> entire class (property, methods, etc.) all on the heap?
> The instance-data (including the pointer to the VTable) is
> all on the heap.
> The Properties and Methods reside "in your Binary", which is
> already loaded into Memory and then only jumped to.

>> If all on heap, ever run out of heap space?
> No, it's more likely to run out of stack-space than
> to run "out of heap".

> Olaf



Mon, 16 Jan 2012 10:03:43 GMT  
 
 [ 10 post ] 

 Relevant Pages 

1. Structures vs. classes

2. Structure vs Class

3. Structure vs Class - Performance Gain?

4. Serializing a Class within a Class (Previously Structures)

5. Memory vs MDI instance vs BAS module question

6. memory leaks and classes within classes

7. Class Libraries vs. Classes

8. Performance: Compiled Classes as DLL vs Classes in Application Code

9. Performance: Compiled Classes as DLL vs Classes in Application Code

10. data class vs datacontrol vs data environemt

11. Performance: Compiled Classes as DLL vs Classes in Application Code

12. Allocating Memory and Structures.

 

 
Powered by phpBB® Forum Software