Snippet List Optimum Speed

[kingkingyyk3]

For real life usage? Put it in demo map. I believe you can use it to make a poker card games.

 

[Nestharus]

A demo map isn't viable for this... they are just standard collection implementations

 

[Jesus4Lyf]

Err, documentation makes no sense, description is incoherant, no demo map, horrible syntax and no indication of what this does or how to use it.
Graveyarded.

 

[Nestharus]

Added some decent documentation with a description of each thing in this as well as how to use each thing. The API that was included in the code was just that, an API =p.


As for a demo map, that would be very silly for this.

Syntax cannot be fixed unless it is done in cJASS (unless Zinc has added definitions). You use vJASS and you get bad syntax and that's about all there is to it.

 

[Romek]

cJass isn't supported here anyway.

 

[Nestharus]

cJass isn't supported here anyway.

hence the reason it's in vjass with a quicko cJASS API add on that just converts the textmacros into definitions =)

 

[Jesus4Lyf]

After looking at Malloc, I conclude that this should NOT have namespaces (as it just allows horrible collisions) and that if the rest of the functionality is more difficult to use than to write yourself as well, then this belongs in the graveyard in a very permanent way.

 

[Nestharus]

The only thing that was more difficult to use than to write yourself was indexed arrays, which is why it wasn't included ; ). I know I said that in the guide : P.

I know I said that somewhere

Why not indexed memory? Indexed memory is so simple that'd it'd actually be harder using macros than writing it from scratch ><.

As for namespaces, I know I've had instances where I needed multiple lists going on at once in a given space. Normally I'd use multiple structs for this, but as there is no inline keyword, I have to do it thru definitions/macros : (.

Now, with the default implements and so on, it just uses a default namespace. Remember, there are different layers of APIs. Now if macros had overloaded arguments then I could make them do a default namespace argument too. I see no reason why to remove namespace as I do provide the default and then go on to provide custom if the user chooses to have it.

So this has a heap, dequeue, stack, and queue in it I believe.

Also you could easily write a little utility using this for dequeues etc that is faster than the current ones ; ), but I did it this way because there are a few ways to do these things. I know one time I did allocation based on 2D array slots, and another time based on ids. I've also done single instance dequeues and multi instance dequeues, so again, that's why this is in a macro form rather than a hardcoded form. It's meant to be a framework because there are too many variants of what can be done with these collections. It simple provides the basic operations so you don't have to do them over and over again.

Yes, the API is ugly at the macro layer, but if you do learn it it can be a time saver : ). If there were inline methods, I'd certainly do it through methods instead to get rid of a lot of the args and make the interface easier to deal with. Also, if there were definitions in Zinc (not sure if Vex added them yet), I'd certain move the macros towards an XML/OO style code block.

And remember, there is always a pretty powerful default namespace module API that's pretty and a super simple default collection that'd be more like those other systems but implemented like a regular dequeue with a head and a tail to save on add/remove operations.

 

[Sevion]

I have tried to use this, but cannot for the life of me.

 

[Nestharus]

I'll write another guide then on Tuesday. Sunday and Monday I'm going to be way too busy to deal with this.

 

[Chaos_Knight]

And this does?

 

[Romek]

People usually opt for a neat balance of ease of use and speed of code in JASS. Most lean towards ease of use as this is JASS, not real programming. Speed isn't of as much concern at all, and nobody will ever tell the difference between a 'fast' or 'slow' system; whereas the ease of use of systems is relatively important.

This system completely sacrifices ease of use for the sake of speed, and therefore has the ugliest interface I've seen to date in any system. And the advantages of this over a system with a [del]nice[/del] remotely usable interface? This one's 0.1 nanoseconds faster.

Is it worth it? Of course not.
Please, quit this obsession with 'fast' code.

 

[Nestharus]

Again, rewriting the guide because the first layer's API is just as easy to use as any system out there =). I made this with the knowledge that the lowest layer was seriously insane, hence 3 layers. Middle is only semi-insane. Today I don't have enough time to write it.

First layer is just implementing 2 modules, the heap and the collection type, so it's mainly just about using the methods like add, remove, etc.

 

[Sevion]

I really have to agree with Romek on this one. The interface is horrible -_-' This snippet isn't user-friendly at all.

 

[Nestharus]

Complete rewrite : |

 

[Sevion]

Why do you continue to refuse to explain why people should use your snippets/systems over others.

You explain nothing about why I should use:

struct myStruct extends array
    implement MallocStruct
    // yada yada
endstruct

over

struct myStruct
    // yada yada
endstruct

You don't exactly explain anything -_-'

And no, a Wikipedia article is not "explaining".

Also, "that's part of vjass" isn't a valid reason to not explain.

 

[Nestharus]

Because using regular structs is asking for a world of invisible background code trouble, like random triggers for destroy and create, triggers for virtually every method you add, chained allocation (when the instances should just be sync'd), and etc... sure, I agree with chained creation and what not, but only in cases where you are performing ini. I mean, that's a standard practice ; |. Chained allocation is a standard practice too, but you don't need that for vjass because structs are just arrays and you can only have 8190 instances meaning you might as well base the instances off of a root struct.


Anyways, all of this background code just makes me always want to do [ljass]struct extends array[/ljass] because that has 0 background code. It allows me to take advantage of the nice OO syntax and avoid the hassle of the code I despise. Every struct I ever make always extends an array. For extending other structs, I do a variety of tricks since delegates require syncing....


Anyways, malloc allows standard memory allocation that is easy to write and customize for structs that extend arrays.

to me, [ljass]struct extends array[/ljass] is a much smarter way to go. It's how I always do things and having a malloc thing for writing allocate methods is better than writing it from scratch every time and better than standard struct background code.

Vexorian was doing hybrid class/struct craziness >.<.

 

[Lyerae]

> Vexorian was doing hybrid class/struct craziness >.<.

The entire concept of vJASS is craziness, though pure insanity would be a better explaination.

 

[Nestharus]

edit
Too many changes : P

 

[Nestharus]

Changes
Ok, made loads of changes and planning to make a few more.

Dequeues

• Made a special style of malloc for dequeues
• Changed dequeue design to single head
• Moved to spiffy link style operations
• Added pop, push, shift, and unshift operations for dequeue

Dmalloc

• includes allocate, allocateCount, and deallocate(node1, node2)
• 2 fields instead of the standard 3
• freed instances are stored in a sort stack instead of a freed array to take advantage of the links. .previous and .next are updated etc, but it works like a stack. This allows large numbers of nodes to be deallocated without a loop.

Planned additions-

• SMalloc, or special malloc for Stacks
• Queue

Differences between these collections and others
These collections specialize in ranged operations. If you are only dealing with single operations and never plan on dealing with ranges, you can still use these as they do have specialized single operations, but some situations might be a little slower.

I believe that these are the only collections at the moment on any of the sites that do specialize in range operations, so this shouldn't be in the graveyard ; P.

I could add more that specialize in single operations and follow the same design style as these things if people want, but there are already tons of things out there that do single operations.

This follows a unique 3 layer design style.

Layer 1 is probably the layer most people would use and is just like any other library you might use, implement the module and use the methods.

Layer 2 is used for writing methods, which can then be packed into a module.

Layer 3 is used for writing modules, which can be packed into methods, which can be packed into a single module.