OOP easy with Macro New and Delete

[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

[Trond]

And strings will just float around on the heap after Delete()?

[Kale]

And strings will just float around on the heap after Delete()?

Surely PB's garbage collector will take care of cleaning up the heap.

[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

[Trond]

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.

[Kale]

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.

[Kaeru Gaman]

just a little remark:

international it's called OOP

Poo is what little children make into their swaddles...

[Nico]

I know, i'm french.

Programmation Orientée Objet

[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.

[DarkDragon]

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.

[Trond]

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.

[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!

[Nico]

It is just an example to show what we can make with the macro!

[Trond]

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.

[Rescator]

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.