TLists Reporting Incorrect Counts?
BlitzMax Forums/BlitzMax Programming/TLists Reporting Incorrect Counts?
| ||
Has anyone experienced TList returning 1 from the Count() method despite not actually containing any objects? I don't much fancy producing a small example from a huge game engine, so I'm hoping that someone might have come across it before and be able to give me an idea where the solution might lie. I'm still using 1.28 if that makes a difference. I don't think there were any bugs fixed with TLists in 1.30 though, were there? EDIT: I forgot to mention that I've overridden the compare method and I sort the list often. Not sure if that would make a difference. Perhaps. |
| ||
Nope. Maybe you should implement a check for the bug and log the the data (if there really is any) in the list. |
| ||
There isn't any. I wish there was, then it would be my bug. |
| ||
I use it to keep track of number of tanks left in an old tank game I made. I have used it on 1.26, 1.28 and 1.30 and never had any problems. I am using 1.30 at the moment. I made a simple example to test it: Local list:TList Type TEco Field Forest:Int Field trees:Int Field animal:Int Field river:Int End Type list = New TList For n = 0 To 500 Local e:TEco = New TEco e.Forest = Rnd(5) e.trees = Rnd(57) e.animal = Rnd(350) e.river = Rnd(4) list.addlast(e) Next Print list.count() For e:teco = EachIn list list.Remove(e) Next Print list.count() everything works fine here. |
| ||
Yes, I know it works 99.9% of the time or someone would have found it and solved it years ago. Nevertheless, there clearly is - or was - a bug in there somewhere or I wouldn't have an empty list reporting a count() of 1. I'm just hoping that someone has had it happen before and might know what triggers it. Probably a bit of a long shot, I guess, or they would have reported it before. EDIT: Just spotted something I forgot to mention in my first post. Added it now. |
| ||
As usual requirement.....try to duplicate the problem using a very scaled down version of the code that you can post here. I've been using Tlists for everything and never had a problem with the count report. Maybe you have a pointer, alias, etc, still addressing an object and it hasn't been garbage collected yet? |
| ||
Never seen it. I've also overridden the compare method to sort items in the list and still don't get any problems. Are you manipulating the TLinks in any other way? |
| ||
There's something in the back of my mind about this from ages ago - something to do with a null object somehow getting added to a TList and throwing the count off. I realise this isn't much help. |
| ||
I don't think I'm adding a null object to a list, although I can confirm that doing so causes the list to return a count() of 1, so either that issue was fixed since 1.28 or it hasn't been fixed. What I think I am doing is adding two objects with the exact same (float) value for the field which Compare() uses to sort the list. I could see this being a problem if I worked on the list without TLinks, but I never do. |
| ||
I would probably write in code where the TList is suppose to be 0, and dump the contents of the list. Something like thisIf WhatListIsSupposeToContain = 0 And MyList.Count() <> 0 For Local o:Object = Eachin MyList If o = Null Print "Null Object Found" Else Print "Object Found" If MyType(o) Then Print "And it is of Type MyType" End If End If If the list is truely empty, then nothing will print. If the list has a Null reference, then it'll print that. If it contains an object and it is one you added, then you'll know that. If you discover that one of your own objects isn't being deleted, you might check the contents to find out which one. |
| ||
Are you adding somewhere an object that is different to the rest of the objects in the list? As that count will see those as well, but you will not find them when you iterate the list. I have done that and it is a pain, esp if you are using types with similar names. Cheers. |
| ||
Just thinking. I remember a while ago, there was a problem with some of the TList methods when you would override the Compare method. Apparently the built in function would also use Compare, but would expect it to work in its default behavior. You could try replacing Compare with its alternate version and see if the problem disappears. If you're not sure how the alternative version works, here's a small example. |
| ||
Wow, I totally expected this to be a post from years ago, haha! But nontheless: THANK YOU! My god, finally I find something that's perfectly what I was looking for... and it works beautifully! I'm making a little synthiziser right now to design pregeneratable sounds for small games. As part of the editing I generate markers for envelopes of all kinds. This sorting was perfectly what I needed! Now I can move on... YES! 8) (...sounds like a commercial for BMax, doesn't it... LOL) |
| ||
Use TList.IsEmpty( ) and if it's not empty, then the list element count is TList.Count( ) + 1 Here's a little function for you. Function ListCount:Int( List:TList ) If ( List.IsEmpty ) Return 0 Else Return List.Count( ) + 1 EndIf End Function |
| ||
Ive just spent the last 10 mins wondering why my Tlists were not clearing. I had overridden the COMPARE function too, changing it to CompareFunc has solved my problem too. I traced it to being every time I removed from the TLIST the list was resorted so I was always having 1 or 2 items left in the list. Many thanks |