Snippet Alloc

[Nestharus]

onDestroy needs to be called inside of a trigger evaluation.

There is a reason why it is done that way in vJASS.

edit

struct Guard
    static method create takes nothing returns thistype
        set guard = CreateUnit(...)
        return this
    endmethod
    method onDestroy takes nothing returns nothing
        call RemoveUnit(guard)
        set guard = null
    endmethod
endstruct

struct UnitGuard extends Guard
    static method create takes nothing returns thistype
        call AddSomeCoolEffect(guard)
    endmethod

Notice that with your current design, onDestroy in Guard would not be called if UnitGuard was destroyed. This is the reason why there need to be trigger evaluations. Each instance would get a trigger and as the things are created, the onDestroy things would be piled on to that trigger. When destroy is called at any of the instances, the trigger is evaluated, meaning that all of the stuff gets properly destroyed.

If you are supporting onDestroy, you need to do that because that is what it traditionally does in vJASS.

People would be doing inheritance via delegates, meaning that you end up registering and doing all sorts of other nonsense.

I suggest just taking onDestroy out and leaving it up to the user to call it however they wish.

 

[Sevion]

I suppose taking it out makes sense.

I wasn't sure how to go about using delegates to do all of this stuff.

However, when using Alloc you shouldn't be directly extending other structs anyways. All structs should just be an array struct.

I'll just take out OnDestroy functionality and leave it up to the user.

Updated to 1.04.

 

[Sevion]

Bump. Any word on approval?

 

[Sevion]

Updated to 1.05, fixed some debug things that Anitarf suggested and added null entry deallocation protection.

 

[Bribe]

With the null instance protection and the 8190 protection enabled, your module is now just as slow as Vexorian's structs, stripping away the advantage entirely. Safety should only be optional, not mandatory. That's the problem with wc3c.net, they really love their verbosity.

Really, this is 99.99% useless now with that enabled.

 

[Sevion]

Reverted to 1.04 with the exception of keeping null entry deallocation in there (in debug mode only).

It will not run the same as default structs (except for onDestroy) when in debug mode and faster in release mode.

Still no moderator reviews?

 

[Romek]

The OnDestroy addition was quite useful, I think.
You can't properly extends structs whilst using this anyway (and if you want to, just use the standard structs instead of this), and I think this is aimed at people who just want a single data struct or something without inheritance and any other fancy stuff.

> If you are supporting onDestroy, you need to do that because that is what it traditionally does in vJASS.
This entire thing doesn't do what's 'traditionally' done in vJass anyway.

 

[Sevion]

OnDestroy can be done by the end user in the destroy method.

This is more aimed at system makers that need extra efficiency on allocation and deallocation. AIDS for example could benefit from something like this. If there is a large amount of units created/removed any amount of efficiency gain is nice.

I suppose that if I do add OnDestroy it'll more or less make it just like an unsafe vJASS struct, which would be pointless in the end.

Update: Reverted the code to exactly the same as 1.04 (except for the debug message in deallocation).

 

[tooltiperror]

I don't think anything should extend other structs or interfaces. I believe all inheritance and polymorphism should be done through taking integer parameters and the use of a delegate(s), so this is a logical addition for structs.

All structs should be array structs.

 

[Sevion]

Update: Moved the overflow check so it only checks when the instance count increases. Efficiency gainz are over nine thousaaaaaand!

 

[lep]

[...]
Safety should only be optional, not mandatory. That's the problem with wc3c.net, they really love their verbosity.

[...]

Talking about verbosity, you want me to type [ljass] extends array[/ljass] and
[ljass]implement Alloc[/ljass] and

        public static method create takes nothing returns thistype
            return thistype.allocate()
        endmethod

        public method destroy takes nothing returns nothing
            call this.deallocate()
        endmethod

for every single struct i create?!
(Taken from the "Demonstration" from the op [1][2].)
And not to forget that i neither can use [ljass]interface[/ljass]s nor normal
inheritance.

And let me get it right: i have to do all this to get speed-improvement of like
two less [ljass]if[/ljass]-statements and one assignment per instance-lifecycle?!

Well, uh, for me that sounds like a bad deal.

________
[1]: http://www.thehelper.net/forums/showthread.php/163457-Alloc
[2]: The original code:

    private struct teststruct extends array
        implement Alloc

        private string data

        public static method create takes nothing returns thistype
            //call BJDebugMsg("Created")
            return thistype.allocate()
        endmethod
        
        public method test takes nothing returns nothing
            call BJDebugMsg("Instance: " + I2S(this))
        endmethod

        public method destroy takes nothing returns nothing
            call BJDebugMsg("Destroying: " + I2S(this))
            call this.deallocate()
        endmethod
    endstruct

 

[Nestharus]

no, structs that extend structs also spam triggers and evaluate them on destroy.

 

[tooltiperror]

This should use a delegate like AIDS does. As lep pointed out, redeclaring [LJASS]create[/LJASS] and [LJASS]destory[/LJASS] for a struct that simply needs to be allocated out of scope is a waste of space. Just add in this.

private struct DEFAULT_ALLOC extends array
    method destroy takes nothing returns nothing
        call this.deallocate()
    endmethod
    static method create takes nothing returns thistype
        return thistype.allocate()
    endmethod
    implement Alloc
endstruct
globals
    private DEFAULT_ALLOC DEFAULT
endglobals

And then just add in [LJASS]DEFAULT[/LJASS] as a [ljass]delegate[/ljass]. That saves six useless lines.

And WC3C really is a verbosity loving site. I mean, which THW we get crap like [LJASS]x.create(10,"temp",this.unit,24,"some\\special\\effect\\mode.mdx")[/LJASS].

 

[Sevion]

You don't need to declare create and destroy.

You can just use allocate/deallocate directly.

 

[lep]

You don't need to declare create and destroy.

You can just use allocate/deallocate directly.

Nah, that's no real option.
As soon as i want to do some stuff at initialization i have to write a create [ljass]method[/ljass]. So in my first version of my script i don't need a [ljass].create[/ljass] so i use [ljass].allocate[/ljass] all through my code.
The something changes and i need a create [ljass]method[/ljass]. Now i have to
change my whole script for a thing JassHelper does for free.

And all that hassle for two missing [ljass]if[/ljass] statements and no errorchecking...
Yeah, no, thanks.

And if you want to reduce the sloc generated why not use a single counter for all structs, eh M;D
When nobody overflows anyway...

 

[Narks]

no, structs that extend structs also spam triggers and evaluate them on destroy.

huh, then what does delegate translate to?

 

[Sevion]

I don't think you understand, lep.

We don't use a single counter for all structs because it would not support recycling which would make overflowing happen a lot more often.

 

[lep]

I don't think you understand, lep.

We don't use a single counter for all structs because it would not support recycling which would make overflowing happen a lot more often.

last two lines were sarcasm.
Maybe i should use the Sarcasm Tag.

And it would support recycling...
And do you think you have at any time more than 8190 struct instances?
That actually would be a good reason for a custom allocator, to do some analyzing
logs.

It's nice that you seem to care for overflow in that case but not in the regular case.

meh, i would never use this anyway but noobs shouldn't get fooled with this "SPEED MEGA OPTIMIZATION" where every unit creation is probably slower than a struct alloc/dealloc cycle.

 

[Nestharus]

/yawn

the primary reason people write structs that extend arrays is to avoid the trigger spamming that jasshelper structs do when you extend off of them >.>.

you seem to have ignored that statement that when calling the destroy method, it evaluates a trigger if there are any struct extensions involved.

it's just much smarter to use delegates >.>.

it also generates a useless line or w/e

read more here
http://www.hiveworkshop.com/forums/...ls-280/coding-efficient-vjass-structs-187477/

 

[lep]

/yawn

the primary reason people write structs that extend arrays is to avoid the trigger spamming that jasshelper structs do when you extend off of them >.>.

you seem to have ignored that statement that when calling the destroy method, it evaluates a trigger if there are any struct extensions involved.

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.

it's just much smarter to use delegates >.>.

And this method described in here can't really use inheritance at all, since
you're encouraged to use [ljass]delegate[/ljass]s.
That way you loose the abstractation of [ljass]interface[/ljass]s.
Things like this are just not possible:

interface Mover
				method move takes real x, real y returns nothing
endinterface

function AddToMovers takes Mover m returns nothing
//...
endfunction

For me correct types and abstractions are way more smarter than than
destroying type safety and error-checking.

You guys seem to focus way more on the specialisation than on abstractation.
And ofc on negligible speed performance.
(Not to mention all that hassle i allready pointed out to just use this method.)

it also generates a useless line or w/e

Oh noes, that will totaly kill my map.
If this bothers you so much and Wc3Optimizer doesn't removes it, it's easy
to just write a like three-line script to remove that particular lines.

read more here
http://www.hiveworkshop.com/forums/...ls-280/coding-efficient-vjass-structs-187477/

It's not like i don't know what's JassHelper's doin'...

JassHelper does a kinda good job to give us a higher-level language and you are
killing it with these things.
All those Boilerplatecode for doing simple things JassHelper does automatically.
No. No. No need for this.

And how goes that quote again?

Premature optimization is the root of all evil.