Page 1 of 2
OOP easy with Macro New and Delete
Posted: Wed Jul 18, 2007 10:46 am
by Nico
The Macro:
Code: Select all
; File New_Delete.pb
Macro New(Pointer,Class)
Pointer#_.Class#_=AllocateMemory(SizeOf(Class#_))
Pointer#_\Vtable=?Class
Pointer#.Class=@Pointer#_\Vtable
Class(Pointer)
EndMacro
Macro Delete(Pointer,Class)
Pointer#_.Class#_=Pointer
Class#_(Pointer)
FreeMemory(Pointer)
EndMacro
Test:
Code: Select all
; Important:so that the macro works, it's imperative
; - that the name of the structure is the same that the name of the interface followed by the character "_"
; - that the structure possesses the variable Vtable (First position in structure; Important)
; - that the names of procedures Constructor and Destructor possess the same name as that of the interface
; - that the name of load of the data in DataSection is the same as that of the interface
; For Reminder: *This = Address of the variable Vtable
; it is important that this variable Vtable is declared in the first position
; in the Structure so that: *This.Calcul _ =*This.Calcul
; if Vtable was declared in the second position, we would have: *This.Calcul_ =*This.Calcul-8
; it thus allows us to replace in the procedures *This.Calcul by *This.Calcul_
; we so choose to work on the functions or on the members by taking the one or the other one
; Functions of the class
Interface Calcul
SetData(a.l,b.l)
Addition()
Multiplication()
EndInterface
; Member of the class
Structure Calcul_
Vtable.l ; Important first position
a.l
b.l
EndStructure
; Constructor of the class
; Called after creation of the resources
Procedure Calcul(*This.Calcul_)
Debug "--------------------------"
Debug "Constructor"
*This\a=0
*This\b=0
Debug "--------------------------"
EndProcedure
; Destructor of the class
; Called before liberation of the resources
Procedure Calcul_(*This.Calcul_)
Debug "--------------------------"
Debug "Destructor"
Debug "--------------------------"
EndProcedure
IncludeFile "New_Delete.pb"
Procedure.l Setdata(*This.Calcul_,a.l,b.l)
*This\a=a
*This\b=b
EndProcedure
Procedure.l Addition(*This.Calcul_)
ProcedureReturn *This\a + *This\b
EndProcedure
Procedure.l Multiplication(*This.Calcul_)
ProcedureReturn *This\a * *This\b
EndProcedure
New(*Pointeur,Calcul)
*Pointeur\Setdata(5,3)
Debug "Addition= "+Str(*Pointeur\ Addition())
Debug "Multiplication= "+Str(*Pointeur\ Multiplication())
Delete(*Pointeur,Calcul)
DataSection
Calcul:
Data.l @SetData(),@Addition(),@Multiplication()
EndDataSection
Posted: Wed Jul 18, 2007 11:15 am
by Trond
And strings will just float around on the heap after Delete()?
Posted: Wed Jul 18, 2007 11:21 am
by Kale
Trond wrote:And strings will just float around on the heap after Delete()?
Surely PB's garbage collector will take care of cleaning up the heap.
Posted: Wed Jul 18, 2007 11:35 am
by srod
I think that Trond is correct.
In the case that the set of class members contains strings (i.e. structure Calcul_ in the above example) then because AllocateMemory is used to allocate a structure of this type, the strings themelves will not be freed automatically by Purebasic in response to the FreeMemory() command.
This problem is discussed here:
http://www.purebasic.fr/english/viewtop ... ng+strings
Posted: Wed Jul 18, 2007 11:46 am
by Trond
Kale wrote:Trond wrote:And strings will just float around on the heap after Delete()?
Surely PB's garbage collector will take care of cleaning up the heap.
PB doesn't have a garbage collector, and you should be the one to know.
Posted: Wed Jul 18, 2007 12:17 pm
by Kale
Trond wrote:Kale wrote:Trond wrote:And strings will just float around on the heap after Delete()?
Surely PB's garbage collector will take care of cleaning up the heap.
PB doesn't have a garbage collector, and you should be the one to know.
Why? Reading that post above, I didn't realise PB strings where not garbage collected! Maybe one ought to be added. Theres a nice function in the above post for properly freeing strings if need be.
Posted: Wed Jul 18, 2007 1:13 pm
by Kaeru Gaman
just a little remark:
international it's called OOP
Poo is what little children make into their swaddles...
Posted: Wed Jul 18, 2007 3:34 pm
by Nico
I know, i'm french.
Programmation Orientée Objet
Posted: Wed Jul 18, 2007 4:08 pm
by Xombie
PB does clean up after itself... if it knows when to do it.
I'd posted under coding questions about strings within dynamically allocated structures and was told that (of course) PB didn't clean them up. That makes sense to me.
PureBasic will clean up after itself and remove strings (and other things) that are created in the "normal" course of programming.
So I believe that PB does in fact have garbage collection.
Posted: Wed Jul 18, 2007 4:14 pm
by DarkDragon
Xombie wrote:PB does clean up after itself... if it knows when to do it.
I'd posted under coding questions about strings within dynamically allocated structures and was told that (of course) PB didn't clean them up. That makes sense to me.
PureBasic will clean up after itself and remove strings (and other things) that are created in the "normal" course of programming.
So I believe that PB does in fact have garbage collection.
PB just calls every libraries to end up and clean their stuff with the keyword "End". It doesn't have a real GC like Java's GC.
Posted: Wed Jul 18, 2007 4:18 pm
by Trond
Xombie wrote:PB does clean up after itself... if it knows when to do it.
I'd posted under coding questions about strings within dynamically allocated structures and was told that (of course) PB didn't clean them up. That makes sense to me.
PureBasic will clean up after itself and remove strings (and other things) that are created in the "normal" course of programming.
So I believe that PB does in fact have garbage collection.
Automatic memory management doesn't have to be garbage collection, which is a special type of automatic memory management that PureBasic does not have.
Posted: Thu Jul 19, 2007 11:01 pm
by Rescator
There are some flaws with those macros in the first post.
Like delete assumes the pointer is valid, there is no check.
And even worse the new macro does not check if the memory was actually allocated or not, it just assumes it worked and tries to use it.
Program crashes just waiting to happen!
Posted: Fri Jul 20, 2007 7:11 am
by Nico
It is just an example to show what we can make with the macro!
Posted: Fri Jul 20, 2007 10:49 am
by Trond
Rescator wrote:There are some flaws with those macros in the first post.
Like delete assumes the pointer is valid, there is no check.
And even worse the new macro does not check if the memory was actually allocated or not, it just assumes it worked and tries to use it.
Program crashes just waiting to happen!
You should never have invalid pointers in your program. As soon as you do, you have a bug already.
Posted: Sun Jul 22, 2007 12:46 am
by Rescator
Trond wrote:Rescator wrote:And even worse the new macro does not check if the memory was actually allocated or not, it just assumes it worked and tries to use it.
Program crashes just waiting to happen!
You should never have invalid pointers in your program. As soon as you do, you have a bug already.
Allocating memory can fail, you should always check if it is valid.
Obviously if you fail to allocate memory the system is most likely in deep shit already
I make a habit to always check if allocations work, and if they fail I report a error back to the user.
Obviously I have seen memory issues where not even task manager can open, so in those cases a error message may fail to display as well due to too low memory.