NeuralJack Posted March 28, 2007 Posted March 28, 2007 Let's say you have a base class that 5 other classes inherit cls_Bob_Base cls_Bob_1 : Inherits cls_Bob_Base cls_Bob_2 : Inherits cls_Bob_Base cls_Bob_3 : Inherits cls_Bob_Base cls_Bob_4 : Inherits cls_Bob_Base cls_Bob_5 : Inherits cls_Bob_Base Now in the cls_Bob_Base you have a public non-overrided function called DoThis(). Performing DoThis() is done the same in every Bob class. My question is this: When you instantiate 10 Bob classes it's probably going to create 10 DoThis() functions in your system memory isnt it? Really, it only needs one memory instance of DoThis(), so it seems wasteful to even make non-overrided base functions. But, I'm pretty sure that cls_Bob_Base is never actually instantiated, anywhere, so that means DoThis() will have to be instantiated on each instance of the other bob classes. I suppose you have to make a judgement call on whether to just declare DoThis() somewhere completely different than the base class based on readability vs how much memory you want to waste needlessly. I guess it may not matter too much because my classes probably dont take up much memory at all. I wonder about this often even during regular non-inherited class construction too. There are many functions/subs in the class that could be done outside the class, in fact *most could* be done outside the class, and then there'd only be one copy of the function/Sub in memory. If you have any general guidelines -or tutorials- on when and when-not to make a function/sub inside a class, let me know. Right now, my only guildlines are to do it to avoid casting outside the class. Readability might be another good reason. Here is another example of what i'm talking about: If you have 200 instances of each Cls_1, Cls_2, Cls_3 Then you are comparing 600 memory copies of DescribeMe() in This: Public Class cls_Base Public Mustoverride Function DescribeMe() as String End Class Public Class cls_1 : Inherits cls_Base Public Function DescribeMe() as String Return "I am class 1" End Function End Class Public Class cls_2 : Inherits cls_Base Public Function DescribeMe() as String Return "I am class 2" End Function End Class Public Class cls_3 : Inherits cls_Base Public Function DescribeMe() as String Return "I am class 3" End Function End Class Verses 1 memory copy of this function on your main form or something: Public Function Describe_cls(in_cls as cls_Base) as string If typeof in_cls is Class cls_1 Return "I am class 1" ElseIf typeof in_cls is Class cls_2 Return "I am class 2" ElseIf typeof in_cls is Class cls_3 Return "I am class 3" End If End Function Quote Currently Using: Visual Basic.Net 2005, .Net Framework 2.0
MrPaul Posted March 28, 2007 Posted March 28, 2007 Methods do not add to instance size When you instantiate 10 Bob classes it's probably going to create 10 DoThis() functions in your system memory isnt it? This is not how classes work. All instances of a class share the same code - only their fields (variables) take up memory, not their properties or methods. I expect each instance will have an extra 4 bytes which points to a shared vtable, but this would be the same regardless of how many methods a class has. Public Class Foo Private m_int As Integer '... '1001 methods '... End Class In the code above, instances of Foo would most likely consist of: Any fields (not methods) inherited from Object 4 bytes allocated for the m_int field 4 bytes for a pointer to the vtable which contains the 1001 methods Note that this would be the same whether Foo had 1 or 1001 methods. Good luck :cool: Quote Never trouble another for what you can do for yourself.
NeuralJack Posted March 28, 2007 Author Posted March 28, 2007 (edited) Re: Methods do not add to instance size Ok it's great to know that they did consider memory wastage when creating classes and that all instances of a class use the same function/sub in memory to do their work. Oddly, someone was just telling me different ...saying that OOP by nature is not memory efficient but that these days memory doesnt need to be a consideration because it's cheap and plentiful Edit : After relaying what you said, they pulled back their statements and were happy to find out about how class memory was done too. Edited March 28, 2007 by NeuralJack Quote Currently Using: Visual Basic.Net 2005, .Net Framework 2.0
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.