LinkedList Breaks With Null Objects [1.30]
Archives Forums/BlitzMax Bug Reports/LinkedList Breaks With Null Objects [1.30]
| ||
It's been mentioned before, but I can't find it in the bugs forum, and it's still happening with 1.30 so I guess it hasn't been fixed.Global List:TList=New TList List.AddFirst(Null) List.AddFirst(Null) List.AddFirst(Null) Print List.Count() For Local O:Object=EachIn List Print "Here is an object we have found!" Next Now you have a list with no objects, no ability to remove objects ( because they're not there ) and the count is always going to be wrong. I really don't mind if it ignores null objects completely, throws an error in debug, crashes spectacularly or whatever, but it really isn't good to just silently ignore the null object but increase the count anyway. |
| ||
| I noticed this today when a call to Remove an item from the list resulted in a exception where link._value was Null... |
| ||
@Brucey. If you change line 252 of brl.mod/linkedlist.mod/linkedlist.bmx toIf link._value And link._value.Compare( value )=0 Return link And rebuild modules, then it won't crash when removing objects with Null objects in the list. |
| ||
@Gabriel: modifying the TList.Count() method as below will clear the list of all Null references when List.Count() is called.Method Count() Local link:TLink=_head._succ,count While link<>_head If link._value = Null link.Remove() Else count:+1 End If link=link._succ Wend Return count End Method edit:Example code SuperStrict Global List:TList=New TList Type TMyType Field x:Int = 0 End Type List.AddFirst(Null) List.AddFirst(New TMyType) List.AddFirst(Null) List.AddFirst(New TMyType) List.AddFirst(Null) list.AddFirst(New TMyType) Print List.Count() For Local O:Object=EachIn List Print "Here is an object we have found!" Next |
| ||
| Not being funny but do we really want to have to fanny about re-fixing all the broken mods ourselves every time there's an update? Case in point: Centred windows by default in DX and GL. And this, obviously. |
| ||
| GfK, I understand what you're saying, but look on the bright side. At least you can fix broken modules. Unlike Blitz3D where you must wait until it becomes a priority fix and then wait for the update to come out. Of course, it would be nice that when someone does post a fix, that it is incorporated into the module officially. Only needs a copy and paste. |
| ||
| Time to start hassling the powers that be then, me thinks ;-) |
| ||
| If you distribute your modules then you are dependent on BRL to fix errors. I think an error should be generated if Null is used with lists or maps. |
| ||
| Hi, > I think an error should be generated if Null is used with lists or maps. I agree...can anyone provide a compelling reason why Null should be allowed in lists/maps, considering it slows/complicates list handling in general. The fix for ForEach could indeed be messy... |
| ||
| Should it throw an error when you try to add a Null, or should it just silently not do it. |
| ||
| Hi, >Should it throw an error when you try to add a Null, or should it just silently > not do it. I think it should throw an error - ie: use an Assert( obj ). |
| ||
| a collection of objects is exactly that.... a collection of objects. I think there shouldn't be nulls in the any collection let alone a list. obviously, changing this may break some peoples code though but I'm for the Assert( obj ). |
| ||
| Hi, Okay, asserts added to TList and TMap - now up on SVN. While I was there, I 'fixed' TList.First,TList.Last,TList.RemoveFirst and TList.RemoveLast so that they no longer throw exceptions - instead, they now return Null if the list is empty. If had several requests for this behaviour, but if anyone has any objections to it I can revert to exceptions here. |
| ||
| While I was there, I 'fixed' TList.First,TList.Last,TList.RemoveFirst and TList.RemoveLast so that they no longer throw exceptions - instead, they now return Null if the list is empty. |
   |