Delete type instance
BlitzMax Forums/BlitzMax Programming/Delete type instance
| ||
| In blitz3d this would print "joe knows his friend died" but in blitzmax it prints "bob" So how do I fully delete bob like in blitz3d? Type person Field friend:person Field name:String EndType Local joe:person=New person Local bob:person=New person joe.name="joe" bob.name="bob" joe.friend=bob Release bob bob=Null FlushMem If joe.friend<>Null Then Print joe.friend.name Else Print "joe knows his friend died" EndIf |
| ||
| The problem is that joe has grabbed bob's hand and saved him from the river flushmem. With bmax's garbage collection system as long as your program has a way to access the type, it'll exist. Once you lose both the reference 'bob' and the reference 'joe.friend', flushmem will free it. There is however, no way for you to know that flushmem has freed it since you can't access it. The only way to know is by checking the amount of memory your program uses, and seeing it lower on flushmem. (Check out MemAlloced()). A program written with a garbage collection system rather than the traditional system is usually more stable because you can't have non-null references that don't point to objects. |
| ||
| so there is really no way to do it like in blitz3d? ok so I have to go through every person and set friend to null if friend=joe, then cycle through each dog and do If dog.owner=joe Then dog.owner=Null then do that for all my other types that can point to a person, finally do joe=null It is going to be very hard to convert some of my blitz3d programs. My problem is not that I want the memory free. it is that I neeeeeeed everything else to know that thier friend died in the same loop that he dies. when I kill him, aint no one can keep him alive and aint no one gonna think he is still alive, no ones gonna remember him |
| ||
| Don't worry C, just about everyone but mark has a strong dislike of the gc from what I've seen, myself definitely included. But salvation is at hand, just goto the blitz module folder and open up Blitz_GC.C. It's the source to the garbage collector. You can easily improve it by adding forceful delete.(I'll be releasing a module to the effect soon enough) |
| ||
| hmm thanks, maybe that is what the Delete command will do |
| ||
| Er, what's the point of having a forceful delete?! All references pointing to it won't be equal to null anyway. The garbage collector is one of the best things about Max, and using manual delete makes it pointless. |
| ||
| I dont have BMax on this machine so I cant really write the code here but I think you would have to : Create a Global TList within person to keep track of all the instances of person. Then you would have two functions. One to create a person which would add person to the internal list and return the pointer to the person. The second would be a delete function which you can pass a person as a param and it would go through each person and set to null any person.friend that points to the person you want to delete. then it would remove the person from the list and will return null. In your code you would then have : Local joe:person=person.New ("joe") Local bob:person=person.New ("bob") joe.friend=bob bob = person.remove(bob) |
| ||
| I'm going to wave my hand in the air and say that I really like the way the garbage collector works in Max. Here's how you can do what you want to do: Type person Field friend:person Ptr Field name:String EndType Local joe:person=New person Local bob:person=New person joe.name="joe" bob.name="bob" joe.friend= Varptr(bob) 'Release bob bob=Null FlushMem If joe.friend[0]<>Null Then Print joe.friend[0].name Else Print "joe knows his friend died" EndIf If you want you could have methods in person to hide the pointer code Method getFriend:person()
return friend[0]
End Method
Method setFriend(p:person)
friend = Varptr(p)
End Method |
| ||
| Er, what's the point of having a forceful delete?! All references pointing to it won't be equal to null anyway. The garbage collector is one of the best things about Max, and using manual delete makes it pointless Yes they will. I'm not talking about replacing it completely, I'm talking about offering the option. The refs system will be left in place, but in controlled siturations you can circumvent it and use your own direct.(It seems possible from the code, it's all there, including ref inc'ing and dinking.) I feel it's needed because nearly everything I've done so far(Bar trinity, but that's only thanks to a custom profiler build from scratch) has exhibited massive memory leaks in tight siturations. Like an Ase loader balooning to 900mb, despite numerous methods of flushing the memory.(Once per loop, over every 10,000 loops. At the end of every scope, within custom modules.. But nothing really seems to stem the tide of leaked memory in *Certain*(Not all) siturations. I think a lot of is this is to do with HOW it actually works internally, as it seems to fragment memory a helluva lot in complex tasks. It would be great, if it worked however, or the docs were updated to the point of clarity. |
| ||
| Why don't you post code that demonstrates a problem? Manual deletion will NOT be a magic cure for fragmentation, it probably won't help at all. FlushMem should flush everything lower in the stack than where it's placed, and I know my game has no memory leaks, so it's probably something you're doing wrong. |
| ||
| Probably, which is why I said I'd be just as happy with clearer docs. Atm I see a lot of confusion, even mark himself admiting he's confused about the release side of things now.(A joke? Maybe. but based on a little truth perhaps..) |
| ||
| . |
| ||
| I personally like the garbage collector, I just think it needs a few tweaks first. |
| ||
| Don't worry C, just about everyone but mark has a strong dislike of the gc from what I've seen, myself definitely included. Err, speak for yourself. I'm very happy with the garbage collector and have zero issues with it. |
| ||
| I was not speaking for you warren, nor did I ever give any indication of intent to. I was clearly refering to the people who have voiced concerns and their frustration at the gc. If you have had no such problems, you're replying to that which did not happen.(Me implying you don't like it. I did not.) If you are, you're retorting needlessly... |
| ||
| just about everyone but mark has a strong dislike of the gc from what I've seen, myself definitely included |
| ||
| *Just about everyone but <Blah>" It's lingo to the same effect as "Everyone and his pet monkey", not a litteral statement. And more to the point It's still only talking about people who have had issues with the gc. Which incidentally, I just informed you of for a second time, and here I am doing so for a third time just in case there is any confusion. If I have to make it clear for a fourth time, you're leaving yourself in the unfortunate position of being a clear and present troll. -- |
| ||
| *Just about everyone but <Blah>" It's lingo to the same effect as "Everyone and his pet monkey", not a litteral statement. Words mean things. If you're not going to be using English, please include a disclaimer at the top of your posts. |
| ||
| And common sense is free, use it next time. |
| ||
| Antony, you are being an arse again. |
| ||
| Dear John, you are being a troll again. What is it, fifth time in less than a month? Are you insecure? Of course if my so-called likeness to a arse is a problem for you, take it up with the mods. Do not however, try to reduce the thread into a troll-fest. It didn't work the other four times, and it won't now. Accept that and get on with your life. |
| ||
| I've attempted to write numerous functions to do delete custom types in C. Prolly the problem is I'm not very used to writing C. Anyway, I've tried nearly everything I could think of, setting the refs variable of the object class to 0, attempting to delete the memory, etc. doesnt seem to work. It'd be cool to have a method that sets all references to null... |
| ||
| Hi, If you have some code that exhibits leaks, please post it. |
   |