Any known bugs in TMap since 1.30?
BlitzMax Forums/BlitzMax Programming/Any known bugs in TMap since 1.30?
| ||
| I'm having some problems with TMaps in 1.30 on Windows. Specifically, I'm iterating through one with EachIn and Values() and it's finding the same object twice, even though it's only ever added once. I've got debug checks in place to ensure that only five objects are ever added, and to be doubly sure, immediately before the bug occurs, I iterate through the Keys() and call GetKeyForValue() and this confirms that only the five objects are in there. As you can imagine, this is a real pain in the butt. I don't really want to patch it up by checking for the same one twice because it's treating the symptoms instead of the causes. Trouble is, I don't know what the causes are. So I'm wondering if any bugs have been reported or fixed since 1.30 which might explain this? I've tried the bug forum and there's nothing there. |
| ||
| Only thing I remember ist that mixing Strings and Objects in a Map messes it up. |
| ||
| There's only one change according to versions.txt: 1.32 Null keys no longer allowed in TMaps. Asserts have been added to guard against this. |
| ||
| @Gabriel: I know it's a tiresome phrase but I'd really recommend that you try to pinpoint the problem by writing some small code that reproduces the defect. Since you got the project that causes these symptoms (and thus know what you usually feed the map with, when strange things occur) you are the one with the best knowledge to write such a test application. |
| ||
| Thanks guys. I already wrote my own wrapper to ensure that Null keys are not used. When you talk about strings and objects, do you mean using them as keys or values? As far as I know, I'm only using strings as keys and objects as values. I'm currently working under the assumption that something is happening inside the For..EachIn loop which interferes with the iterator, but I can't see anything which should affect that. AAMOF, I thought that returning an iterator as Values() does was precisely to ensure that you couldn't mess with it. @Gabriel: I know it's a tiresome phrase but I'd really recommend that you try to pinpoint the problem by writing some small code that reproduces the defect. Since you got the project that causes these symptoms (and thus know what you usually feed the map with, when strange things occur) you are the one with the best knowledge to write such a test application. It's not a tiresome phrase, it just takes more time to break down a game spread over nearly 400 include files down into a fifteen line demo of the problem than some people seem to think. It's not for the want of trying that I haven't managed it so far. |
| ||
| I didn't even know you could use eachin with maps! For each thing I want in a map, I have a management type that has a list of string ids and the map. Whenever I add an item, it puts the id in the list and adds to the map under the id. The reason I did this, is I can then eachin the list of ids to access each item from the map. |
| ||
| Post an example. |
| ||
| I've got debug checks in place to ensure that only five objects are ever added I would be worried about adding AND removing objects while using the result of MapKeys(). Both ops will make such an array out of date: Global m:TMap=New TMap MapInsert m,"a","1" MapInsert m,"b","2" MapInsert m,"c","3" MapInsert m,"d","4" For k$=EachIn MapKeys(m) j$=String(MapValueForKey(m,k)) If k="c" MapRemove m,"d" Print k+","+j Next Oh, keys is an iterator not an array, that's kind of unexpected (and new?)... If keys is going to return an iterator then I would consider both Add and Remove ops could be made safe rather than the chaos output above. |
| ||
| I'm not adding any objects while using the result of MapKeys, but I am removing them. I was under the impression that keys was always an iterator, but I may be wrong about that. If remove isn't presently safe then that's probably the problem. Thanks for the explanation. I'll move over to marking for removal at a later date and that should fix it. |
| ||
| Yes I find deathlists are always best :) |
| ||
| There is this: http://www.blitzbasic.com/codearcs/codearcs.php?code=2544 I could swear that i remeber someone writing a Tmap replacement that claimed to be faster. i cant seem to find it though. Edit: Here it is. http://www.blitzmax.com/codearcs/codearcs.php?code=1907 |
| ||
| So maps aren't safe for random adding and removing? |
| ||
| So maps aren't safe for random adding and removing? Don't you mean, "So, while using a map iterator, maps aren't safe for random adding and removing?" |
| ||
| I don't know! ;) I'm just using the Insert and Remove methods of TMap.. I've never directly used an iterator and wouldn't know how to if I wanted to. I was using TLists before to store my game objects, but I often found myself having to pick out an individual object frequently to update, using their id. (This is mainly because it is a multiplayer game, and alas you can't send object references over the network and expect it to work ;o so I have to use a system of IDs instead to receive orders). I could use arrays, but objects are created and destroyed regularly.. so I found TMaps to be the ideal compromise. So is it safe to use them for this purpose? My whole game will kind of depend upon this fact :O |
   |