wc3campaigns
WC3C Homepage - www.wc3c.netUser Control Panel (Requires Log-In)Engage in discussions with other users and join contests in the WC3C forums!Read one of our many tutorials, ranging in difficulty from beginner to advanced!Show off your artistic talents in the WC3C Gallery!Download quality models, textures, spells (vJASS/JASS), systems, and scripts!Download maps that have passed through our rigorous approval process!

Go Back   Wc3C.net > Resources > - Submit a resource -
User Name
Password
Register Rules Get Hosted! Chat Pastebin FAQ and Rules Members List Calendar



Reply
 
Thread Tools Search this Thread
Old 05-30-2011, 09:21 AM   #16
BBQ
User
 
Join Date: May 2011
Posts: 85

Submissions (2)

BBQ will become famous soon enough (30)BBQ will become famous soon enough (30)

Default

Quote:
Originally Posted by Bribe
That kind of typecasting would generate a data sharing conflict easily resulting in a lot of things being accidentally overwritten or erased.
It won't if you're using vJass keys. But I agree that it's not really user-friendly.
BBQ is offline   Reply With Quote
Sponsored Links - Login to hide this ad!
Old 05-30-2011, 09:54 AM   #17
Bribe
User
 
Bribe's Avatar
 
Join Date: Mar 2010
Posts: 233

Submissions (1)

Bribe will become famous soon enough (30)Bribe will become famous soon enough (30)

Send a message via AIM to Bribe
Default

Based on your example you use the unit's negated handle id as the parent key and the key as the child key- this is insufficient as the child key would then be limited to that one index.
Bribe is offline   Reply With Quote
Old 05-30-2011, 11:31 AM   #18
Anitarf
Procrastination Incarnate


Development Director
 
Join Date: Feb 2004
Posts: 8,189

Submissions (19)

Anitarf has a brilliant future (903)Anitarf has a brilliant future (903)Anitarf has a brilliant future (903)Anitarf has a brilliant future (903)Anitarf has a brilliant future (903)Anitarf has a brilliant future (903)Anitarf has a brilliant future (903)Anitarf has a brilliant future (903)

2008 Spell olympics - Fire - SilverApproved Map: Old School Alliance TacticsHero Contest #2 - 3rd PlaceSpell making session 2 winner

Default

Quote:
Originally Posted by BBQ
You may argue that the 2D-syntax Vexorian's Table provides is bad because of StringHash(string) being involved, but let me remind you that the user can manually do things like Table(-(GetHandleId(unit))[key] = 0x7FFFFFFF and/or any other combination of parent- and child-keys.
I wouldn't advocate such ugly hacks myself, really. Table simply isn't meant to do 2D stuff, the 2D support that it does have is ugly and the only reason it's there is because using native gamecache was uglier. Today, I would recommend using a native hastable over Table's 2D syntax any time. The only reason it is still included in the library is backwards compatibility.

This is the reason why I consider Bribe's comparisons between Table and Array 2D syntax to be invalid. The comparison should be made between Array and a native hashtable. Likewise, the comparison with vJass 2D arrays is not valid because the 2D arrays are not shared space - they are typically used only by whatever library declared them, where the author can ensure that they are used correctly and even if he doesn't, only that library will break.

Quote:
Originally Posted by Bribe
You overestimate the safety issue with DualArray as the person building the map has control over the SAFETY option, not the people who wrote the libraries that require it. If there are libraries present in the map that are so poorly-coded they require SAFETY to be on perhaps a simple recommendation to users that SAFETY should be on. Realistically, if the system needs such safety built-in, it probably has bigger problems than just that.
I think I already covered the rest of your post with my reply above, so let me just add a response to this paragraph. Due to the Dunning-Kruger effect, coders are unlikely to advertise that their library needs Array SAFETY to be on. Most coders will believe they wrote their code correctly until proven otherwise. On the other hand, the "speed freaks" that you seek to appease might specifically advertise that Array SAFETY should be turned off when people use their library. The whole SAFETY thing is a recipe for trouble. You can try dismissing libraries that cause these errors saying they "probably have bigger problems than just that", but at the end of the day it is still your library that bugged up just by people using its public api.
__________________
Anitarf is offline   Reply With Quote
Old 05-30-2011, 02:04 PM   #19
Bribe
User
 
Bribe's Avatar
 
Join Date: Mar 2010
Posts: 233

Submissions (1)

Bribe will become famous soon enough (30)Bribe will become famous soon enough (30)

Send a message via AIM to Bribe
Default

I really see your point of view now. While I don't support "training wheels" within a controlled environment, this should follow more of a chaos-theory principle and needs to be adaptable enough for multiple libraries to extend it without fear of crash. The point you bring up is much more valuable than a simple speed improvement.

For DualArrays, speed freaks can still inline "this + key" (for those who know what they are doing) or simply use native hashtables to avoid the arithmetic altogether. DualArray has very high-level execution and should be considered with a high-level performance cost.

DualArrays are still useful creatures for producing high-storage, dynamic arrays without nearing the hashtable limit so they still have a place in this library or perhaps as an optional coupled library.

Last edited by Bribe : 05-30-2011 at 02:18 PM.
Bribe is offline   Reply With Quote
Old 06-01-2011, 08:46 PM   #20
Nestharus
User
 
Join Date: Jul 2007
Posts: 220

Nestharus has little to show at this moment (6)

Default

Quote:
Most coders will believe they wrote their code correctly until proven otherwise

C'mon, I've once written a massive 1000+ line library that only had 1 small error in it that I happened to find before anyone else ; ). Granted, I must say that I've only ever been able to pull that off once ^)^.


My philosophy on safety is this:
Make safety debug only, but include error messages. If people are seeing those error messages, then that means that they need to debug the systems causing those error messages. Having a bandaid to solve the problem isn't a solution at all : P.

While I was writing Encoder, I ofc debugged in debug mode. I'd sometimes see other library errors pop up, which told me that something was going on somewhere. This allowed me to fix up Encoder so as to have 0 errors (well, it ended up having a tiny error, but I found that soon enough in debug mode).

I think debug mode should be used to debug systems. Once a system is debugged, there is no longer a need for the safety, it is just all extra fluff. A lot of people say that this extra fluff is so small that it isn't noticeable, and that is true in most maps, but some maps have so much in them that this extra fluff can make them begin to lag. I've actually worked on one such map that had more systems in it than I care to mention and easily had 1000+ units on the map at a given time (had to do special queue things in order to decrease the unit counts to help reduce the lag).

Yea, in the professional world, you always want safety on because you don't know what those idiots in that other department might do to break your resource, and there is just too much going on to try and make everything fit together (the safety just makes sense there, it's way easier), but in a smaller map team environment or systems design environment, it's better to debug those systems to be entirely error free than to just rely on safety all the time for errors that those systems seem to have.

Authors of generally used resources should be responsible enough to thoroughly debug their own resources. I know I spent a very long time checking every possible nook and cranny of BigInt when I wrote it.


One of the bigger issues I think with replacing an older library is the changing of standards, but Bribe did provide an API to support that older library, so I don't see the problem. I know one problem a lot of people face with my UnitIndexer system today is that I refuse to provide an API to AutoIndex or AIDS =).

I've used Bribe's library in struct generation (1 table per struct instance), thus having the potential to generate thousands of tables. That goes well beyond the hashtable limit. While one hashtable may seem proper for that resource, does it make sense to continue to reinvent the wheel for 20 or 30 or 40 different resources? It makes much more sense to rely on a single resource, no matter how simple that single resource may be. That is the joy of modularity =).

Last edited by Nestharus : 06-01-2011 at 08:50 PM.
Nestharus is offline   Reply With Quote
Old 06-01-2011, 10:13 PM   #21
Captain Griffen
Dread Lord of the Cookies
 
Captain Griffen's Avatar


Content Director
 
Join Date: Sep 2003
Posts: 5,375

Submissions (2)

Captain Griffen is a glorious beacon of light (497)Captain Griffen is a glorious beacon of light (497)Captain Griffen is a glorious beacon of light (497)Captain Griffen is a glorious beacon of light (497)Captain Griffen is a glorious beacon of light (497)

Approved Map: Warlords[Quicksilver #2] - 1st Place

Default

Quote:
Originally Posted by Nestharus
C'mon, I've once written a massive 1000+ line library that only had 1 small error in it that I happened to find before anyone else ; ). Granted, I must say that I've only ever been able to pull that off once ^)^.

For disagreeing, you sure are adding a lot of weight to what Anitarf said. There's no way to know for sure code doesn't have bugs in it.

Your post utterly ignores that this is a library which could be used by lots of different systems. Hence, a problem in one system could lead to other systems breaking. At which point, you have a debugging nightmare. Errors can pop in over time from tiny little changes in the code, little updates which you don't think will cause a problem, etc., rather than just being in the initial release.

So for a resource like this, the potential cost in terms of ridiculous debugging is not worth a tiny speed cost.
__________________
Quote:
Originally Posted by Earth-Fury
Griffen is correct, you are not.
Quote:
[13:32] <Akolyt0r> hmm.. stil i want to have some unused women
Captain Griffen is offline   Reply With Quote
Old 06-30-2011, 07:49 PM   #22
BBQ
User
 
Join Date: May 2011
Posts: 85

Submissions (2)

BBQ will become famous soon enough (30)BBQ will become famous soon enough (30)

Default

Quote:
Originally Posted by Bribe
Based on your example you use the unit's negated handle id as the parent key and the key as the child key- this is insufficient as the child key would then be limited to that one index.
Well, speaking about 2D-syntax, the one provided by your library is not perfectly safe either.
Collapse Zinc:
//! zinc
library DualArrayTest requires Array {
    
    DualArray firstArray, secondArray;
    constant integer ARRAY_SIZE = 0x2000;
    constant key KEY;
    
    function print(string message) {
        DisplayTimedTextToPlayer(GetLocalPlayer(), 0.0, 0.0, 50.0, message);
    }
    
    function onInit() {
        firstArray = DualArray[ARRAY_SIZE];
        secondArray = DualArray[ARRAY_SIZE];
        
        firstArray[ARRAY_SIZE][KEY] = 0x7FFFFFFF;
        secondArray[2*ARRAY_SIZE][KEY] = 0xF;
        
        print(I2S(firstArray[ARRAY_SIZE][KEY]));
        /* Prints "15" instead of "2147483647". */
    }
}
//! endzinc

Last edited by BBQ : 07-01-2011 at 08:14 PM.
BBQ is offline   Reply With Quote
Old 07-01-2011, 06:19 PM   #23
Bribe
User
 
Bribe's Avatar
 
Join Date: Mar 2010
Posts: 233

Submissions (1)

Bribe will become famous soon enough (30)Bribe will become famous soon enough (30)

Send a message via AIM to Bribe
Default

Seeing as how I doubt anyone here is also keeping up with the libraries on hiveworkshop.com:

Quote:
Originally Posted by Bribe;1950116
1. You are exceeding the array bounds when you try to reference ARRAY_SIZE. 8192 size means that you can access slots 0-8191.

2. You are super-exceeding it by using 2*ARRAY_SIZE. That shows a complete disregard for the functionality of the thing. If you had tested this, it would have thrown plenty of errors.

3. This is nothing I haven't though of before, that's why the checks in the getindex method make sure that the key has to be equal or greater than 0 and less than the array size.
Bribe is offline   Reply With Quote
Old 07-01-2011, 08:14 PM   #24
BBQ
User
 
Join Date: May 2011
Posts: 85

Submissions (2)

BBQ will become famous soon enough (30)BBQ will become famous soon enough (30)

Default

Okay, apparently, I had taken the version from THW where the checks are debug-only and altered the names by myself. And I was aware that I was doing stuff I wasn't supposed to be doing.

Sorry about that.

Last edited by BBQ : 07-01-2011 at 08:18 PM.
BBQ is offline   Reply With Quote
Old 10-22-2011, 08:41 PM   #25
Bribe
User
 
Bribe's Avatar
 
Join Date: Mar 2010
Posts: 233

Submissions (1)

Bribe will become famous soon enough (30)Bribe will become famous soon enough (30)

Send a message via AIM to Bribe
Default

This has been heavily edited so that it no longer breaks backwards compatibility. Anitarf, if forwards compatibility is truly a problem people can make a note saying this requires Table 4.0 (similar to how we say a resource requires JassHelper 0.A.2.B even though the noobs always try to use the one that came with the JNGP download).

Edit: Another update to split the library into two parts: Table has only the API of Vexorian's Table, but if you make your library require TableEx you have access to storing the multiple types, and it protects forwards-compatibility because you aren't requiring Table but requiring TableEx.

Last edited by Bribe : 10-23-2011 at 08:55 AM.
Bribe is offline   Reply With Quote
Old 10-27-2011, 11:59 AM   #26
Vexorian
Free Software Terrorist
 
Vexorian's Avatar


Technical Director
 
Join Date: Apr 2003
Posts: 14,898

Submissions (37)

Vexorian has a reputation beyond repute (1062)Vexorian has a reputation beyond repute (1062)Vexorian has a reputation beyond repute (1062)Vexorian has a reputation beyond repute (1062)Vexorian has a reputation beyond repute (1062)Vexorian has a reputation beyond repute (1062)Vexorian has a reputation beyond repute (1062)

Hero Contest #3 - 2nd Place

Default

It seems to add functionality that I wouldn't like in Table. I liked Table's minimality. If you like to make this library, I beg you to call it something else and not advertise it as a new version of Table and let Table be that small quick replacement of gamecache .

In other words, you may even create your new implementation of the library and name it Table. But no library that has requires Table should ever expect to use the new features or added limits. If they want that they should use TableBribe or whatever. It seems like that's what you did with the last update, but I think it needs underlining.

Quote:
allows up to 2^32 instances instead of up to 400,000 instances.
This sounds funny inside my head, I am not sure that is the intended emotion. I cannot for the life of me picture even a c++ game engine that would need more than 100000 instances of an associative array, but I guess that maybe you do. However, the real funny bit is the part about allowing up to 2^32 instances. I think the real limit is far lower than that. For starters, since integers are signed, it is likely 2^31-1 numerically. And even so, I bet even 4GB of RAM computers will die if warcraft 3 actually uses more than 100000000 instances of Table, the number might be smaller even.
__________________
Zoom (requires log in)Wc3 map optimizer 5.0
Someone should fix .wav sound in this thing.
Zoom (requires log in)JassHelper 0.A.2.A
Turns your simple code into something that is complicated enough to work.
Faster != more useful
Vexorian is offline   Reply With Quote
Old 10-27-2011, 12:46 PM   #27
Bribe
User
 
Bribe's Avatar
 
Join Date: Mar 2010
Posts: 233

Submissions (1)

Bribe will become famous soon enough (30)Bribe will become famous soon enough (30)

Send a message via AIM to Bribe
Default

I was in a rush when I typed the value "2^32" and it did come out funny, I apologize for that.

The update to add all types to the Table library would require someone to use TableEx in their map. However upon reading your statement I do see a benefit to merging the whole thing into a library entitled TableEx.

I do not see an overhead in terms of compiled, optimized code. In fact, my library will work out shorter than yours if you have the MAX_INSTANCES variable set to a workable enough amount. There are a lot of systems that have evolved from Table and require many dimensions (storing Tables within Tables).

The original name of this library was NewTable but someone whose name I will not mention talked me into calling it Table. I should have a word with him and in the meanwhile I suppose I could trash the TableEx add-on because the length of the compiled code discourages people (I do see your point in Table being a short-and-sweet solution).

At the very least could you please update your Table library so that Table instances can stored data from within module initializers? Just merge the "InitHashtable" line to make "private hashtable ht = InitHashtable()", then the biggest downfall of the Table system will be eliminated (InitHashtable does not crash the thread nor is there a conceivable op limit initializing globals).
Bribe is offline   Reply With Quote
Old 08-01-2015, 04:53 AM   #28
Bribe
User
 
Bribe's Avatar
 
Join Date: Mar 2010
Posts: 233

Submissions (1)

Bribe will become famous soon enough (30)Bribe will become famous soon enough (30)

Send a message via AIM to Bribe
Default

OK, after 4 years, I have updated this library to incorporate everything that I originally wanted and more. TableArray and HashTable structs have been coded WHILE preserving the obsolete 2D syntax that the original Table, however there is no chance of colliding values - making this a theoretically safer option than Vexorian's.
Bribe is offline   Reply With Quote
Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off


All times are GMT. The time now is 07:18 PM.


Affiliates
The Hubb The JASS Vault Clan WEnW Campaign Creations Clan CBS GamesModding Flixreel Videos

Powered by vBulletin (Copyright ©2000 - 2019, Jelsoft Enterprises Ltd).
Hosted by www.OICcam.com
IT Support and Services provided by Executive IT Services