Snippet Alloc

[tooltiperror]

>Things like this are just not possible:
Well, they are, but you don't have typesafety. Which, IMO, is good. I like the idea of a more dynamically typed language.

struct Card extends array
    method play takes nothing returns nothing
        // the usual card playing
    endmethod
    implemnent Alloc
endstruct
globals
    private Card DEFAULT_CARD=Card.create()
endglobals

struct SpecialCard extends array
    delegate Card DEFAULT_CARD
    method play takes nothing returns nothing
        // special card playing stuff
    endmethod
endstruct

function PlayCard takes integer card returns nothing
    call card.play()
endfunction

You COULD do some typesafety if you wanted, that's child's play.

Ignore Nestharus for the most part, he thinks JASS is C.

 

[Narks]

Hey, if you want to reduce code-spamming just use a single alloc-method.
And personally i see no problem in "spamming" those triggers. It's a nice
way to dynamically call [ljass]function[/ljass]s in Jass.
And better not come with herp derp speed.
A normal map will not suffer from inheritance. And if you do some heavy computations
you will neither use normal structs nor the system in this thread.

i was under the impression that this system was intended for users whose goal was speed (because they were doing heavy computations or lots of allocations / deallocations or w/e)

 

[lep]

>Things like this are just not possible:
Well, they are, but you don't have typesafety. Which, IMO, is good. I like the idea of a more dynamically typed language.

Sure a dynamic language is fine. But there are some points regarding this.
At first: Jass is no dynamic language. It is no dynamic language. Period.
And, i have the feeling that there are only dynamic languages because there is no
good typesystem.
Haskells typesystem is kinda fine. It's highly strong typed but a really dynamic language.
Haskellers often say, that once your program compiles it also works properly because of its strict typesystem.

struct Card extends array
    method play takes nothing returns nothing
        // the usual card playing
    endmethod
    implemnent Alloc
endstruct
globals
    private Card DEFAULT_CARD=Card.create()
endglobals

struct SpecialCard extends array
    delegate Card DEFAULT_CARD
    method play takes nothing returns nothing
        // special card playing stuff
    endmethod
endstruct

function PlayCard takes integer card returns nothing
    call card.play()
endfunction

You COULD do some typesafety if you wanted, that's child's play.

You are trying to solve problems you created yourself. In the first way there was no
need for this.

And i don't think this works

//...
function PlayCard takes integer card returns nothing
    call card.play()
endfunction

Calling a [ljass]method[/ljass] on an [ljass]integer[/ljass]. You have to typecast it.
So you loose all your abstraction since you have to specialize on a concrete type.
Kinda works against the principles of Polymorphism.

Ignore Nestharus for the most part, he thinks JASS is C.

Problem is that Jass is neither C nor Ruby.

i was under the impression that this system was intended for users whose goal was speed (because they were doing heavy computations or lots of allocations / deallocations or w/e)

The speed gain is really negligible. And if you do some special operations in a tight loop you probably aren't using normal structs with normal allocators anyway. Either use allready existing structures or maybe precomputed values.

For normal spell-making there is no need for this.

 

[Nestharus]

eh, for tight operations when using structs, I just inline the allocate/deallocate call and it's 100% exact same code >.>.

So for tight operations, you'd still be using this >.>.

Also keep in mind that most of the time you don't need polymorphism. In fact, you never need full blown polymorphism. Usually there is only one little thing in one method that needs to be polymorphic, and that's generally in a timer or a trigger already, so no need for interfaces. This is ofc if you are squeezing out every last ounce of performance =).

Polymorphism is nice to have in a language if it actually works right, but polymorphism in JASS is slow cumbersome triggers.

 

[Sevion]

It seems I can't use StopWatch Natives on 1.26. Bummer.

I can't put this argument to rest until I can use StopWatch.

 

[Nestharus]

vJASS style, 5fps for 1500 instances (create/destroy)

globals
    integer a = 0
    integer array b
    trigger t = CreateTrigger()
endglobals

function D takes nothing returns boolean
    return false
endfunction
function E takes nothing returns boolean
    return false
endfunction

function B takes nothing returns nothing
    local integer c
    local integer x = 100
    local integer k
    loop
        exitwhen x == 0
        set c = b[0]
        if (c == 0) then
            set c = a + 1
            set a = c
        else
            set b[0] = b[c]
        endif
        set k = c
        set b[c] = b[0]
        set b[0] = c
        call TriggerEvaluate(t)
        set x = x - 1
    endloop
endfunction

struct tester extends array
    private static method onInit takes nothing returns nothing
        local integer x = 15
        call TriggerAddCondition(t, Condition(function D))
        call TriggerAddCondition(t, Condition(function E))
        loop
            exitwhen x == 0
            call TimerStart(CreateTimer(), .031250000, true, function B)
            set x = x - 1
        endloop
    endmethod
endstruct

Alloc style, 15 fps for 10,000 instances create/destroy

globals
    integer a = 0
    integer array b
endglobals

function B takes nothing returns nothing
    local integer c
    local integer x = 500
    loop
        exitwhen x == 0
        set c = b[0]
        if (c == 0) then
            set c = a + 1
            set a = c
        else
            set b[0] = b[c]
        endif
        set b[c] = b[0]
        set b[0] = c
        set x = x - 1
    endloop
endfunction

struct tester extends array
    private static method onInit takes nothing returns nothing
        local integer x = 20
        loop
            exitwhen x == 0
            call TimerStart(CreateTimer(), .031250000, true, function B)
            set x = x - 1
        endloop
    endmethod
endstruct

 

[Sevion]

Now does this convince you about Alloc's usefulness?

 

[Romek]

The issue isn't that people don't believe you that it's faster. It's easy to see that it's faster than the standard struct allocation.

 

[Troll-Brain]

@Nestharus :

Wrong copy/paste or what ?

Coz, i don't see where do you compare struct allocations here, just 15 periodic timers calling a function, and 20 periodic timers evaluating a trigger which contains 2 empty conditions which returns false.

Honestly that just should be the part from vJass, i don't see the point of the extra checks of default vJass struct allocator, if you use an invalid struct instance your map is already broken anyway.

 

[Sevion]

The issue isn't that people don't believe you that it's faster. It's easy to see that it's faster than the standard struct allocation.

Not trying to convince that it's faster, rather how much faster. With this, it's approximately 6.67x faster.

Troll-Brain, he's comparing the methods, not the actual code itself.

They are one and the same (check generated code on structs extending another struct and Alloc structs using delegates).

 

[Nestharus]

Actually, I was being nice to vJASS. It has even more overhead.

It evaluates a trigger array, not a trigger.

I'd need to look at struct initialization to see what's added to the trigger. I'm not sure, but I think that nothing is added to the trigger if onDestroy doesn't exist. If it does, then the functions or w/e are added to the trigger. But again, I am 100% unsure since I've never looked at vjass struct initialization =P

Anyways.. someone else can look, but that just means that vjass is actually slower than what that little stress test thingie showed =D

It also has this for types
set si__a_type[this]=1

 

[Sevion]

Bump for approval?

 

[Sevion]

Bump ^_^

 

[Lyerae]

Bump for Sevion!

 

[tooltiperror]

6.67% speed increase is noticeable if these are running in a T32 callback, for example.

This is written good, safety is safe, and I've used it myself :thup:

Approved.