Personally, I'm a fan of concurrent dictionaries per map using an x and y pair as the key and the item structure as the value. Sometimes... going too far out of the box can be pretty harmful (if you don't build upon what you already know). If you know something isn't coded properly, that's a good time to go out of the box. It's like hiring a consultant. You don't hire a consultant to find problems in a good company. You hire a consultant to fix problems that you already know are problems.
Tips and Tricks to CO Programming
01/28/2012 01:19
Spirited#16
01/28/2012 05:12
12k#17
As I said again, I wasn't arguing if it was "MORE" or "less" efficient. But if you insist on me proving my point its just as efficient or more then the typical method I can. I just assume I shouldn't have to explain myself considering this thread isn't based on that idea; its based on getting more ideas thrown out there. It was just an example and nothing more. If you don't like it, dont use it. If you do, then great.Quote:
The two are not always mutually exclusive...
If something is not efficient then regardless of its functionality then it is not the ideal solution.
Please god... lets not all turn into hipster programmers who code something so it's not so 'mainstream'. Obviously conquer sources that are public are FAR from optimized but doing something just to be unique is not the way to go... Your reasons for adopting a new system should be efficiency and or ease of use.
Your system is neither which is why korv was insulting it (and now I get to jump on that bandwagon it seems)
01/28/2012 06:26
_tao4229_#18
Read this page, then read the thread title.
This is why we can't have nice things.
This is why we can't have nice things.
01/28/2012 10:48
Lateralus#19
Normal data structures don't scale as well vs. Concurrent in general. Go by the rule - if a collection is accessed by more than one thread, go for concurrent. But uh, your way of storing items is as Korvacs said. You'll run into problems.