Global Group standard?

[Jesus4Lyf]

library_once GlobalGroup
    globals
        group GROUP=CreateGroup()
    endglobals
endlibrary

library MyLib requires GlobalGroup
...

I don't think it is appropriate to redirect someone to get GroupUtils or something for the sake of this (the global group), BUT...
We could standardise this for use. It is as simple as putting the top 5 lines at the end (or start) of your library, and will not collide with other systems which do the same - if you have two libraries with this line at the top, it will implement once and share the group.

I think it would be very neat. The best advantage is not saving one handle - it is if you use a group in a system only to do enums on map initialisation and then would destroy it, as this leaks.

But then I think this is madness because:

library_once GlobalGroup uses optional GroupUtils
    globals
        group GROUP
    endglobals
    private struct Init extends array
        private static method onInit takes nothing returns nothing
            static if LIBRARY_GroupUtils then
                set GROUP=ENUM_GROUP
            else
                set GROUP=CreateGroup()
            endif
        endmethod
    endstruct
endlibrary

And so it grows. o.o

(Actually, I kinda like it.)

 

[GetTriggerUnit-]

You're tourmented!

Seems useful to avoid leaks.
Maybe so-so if you have to put it at the top of every code ^_^.

 

[Jesus4Lyf]

>Seems useful to avoid leaks.
Yeah, and you avoid more if you use the second one, which is nice.

It is all insignificant. <_<

 

[Narks]

Some kind of framework that people would use that includes lots of systems, but components that are not used in the framework are excluded from the compiled (lol compiled jass) map...

 

[Jesus4Lyf]

That would require the framework to know about every system that uses it, and check if it does, otherwise not import those components.
Furthermore, it isn't possible.
But the Optimizer should remove unused code.

Anyway. I don't think a framework is necessary or feasible, but I think libraries could paste this at the top to do the group thing... just because it is a leak that is worth catching on some level, and can be done in a reasonably logical way.

 

[Nestharus]

I've been interested and trying to do stuff like this for a long time, for example with my old Map Framework project.

But again, not really possible with pure JASS. You'd pretty much have to make a compiler to actually work with it : \.


While it's an interesting idea for pasting at the top of the map, the issue is trying to make it a standard isn't it ; p. Personally, I use something like this, except that each system gets its own global :\. Standalone Complex, lol.

 

[Romek]

I'm not too bothered in copying that into a script each time when using a new static group will have virtually no impact whatsoever on anything at all.

 

[Troll-Brain]

As GroupUtils really serves a purpose, this is really useless alone.
I don't really like the way how GroupUtils was built, but anyway it's more a standard.

The GROUP_ENUM is not the major thing of GroupUtils, i would say even it's the minor one.

 

[Romek]

GroupUtils is horribly coded. If I ever need group recycling, I'd use anything but that. Fortunately, as all dynamic groups I need are struct members, recycling is easy.

This is like making a mountain out of a mole-hill. A group per script (if even that) is such an insignificant problem (can it be called a problem?), that it's just a waste of time and effort trying to 'solve' it.

 

[Jesus4Lyf]

Ugh, everyone is missing the point.

>While it's an interesting idea for pasting at the top of the map
No, for pasting at the top of every library. This standard is required by system writers only, not map authors (they don't need to know a thing or import anything to use this).

>As GroupUtils really serves a purpose, this is really useless alone.
This means systems using only the ENUM would not require the extra import, and it would cost nothing. If they did import it, it would use GroupUtils in effect.

>A group per script (if even that) is such an insignificant problem
Does anyone care about a group per script? I said:
>The best advantage is not saving one handle - it is if you use a group in a system only to do enums on map initialisation and then would destroy it, as this leaks.

This is carefully thought out, cost free, and probably a nice thing to use. I expected similar responses (rejecting it anyway because it's a non-issue), but from people understanding what I was doing and why...

It solves the leaks caused by enumerating on map init and destroying.

 

[Troll-Brain]

It solves the leaks caused by enumerating on map init and destroying.

I would say this is really irrelevant.
Seriously, no matter that you code well or like a shit, this leak is really really in low priority of leaks (we are talking about map init only, right ?), and virtually can't affect your map.

Don't confuse more people with trying to add one quite useless standard

 

[Hatebreeder]

I would say this is really irrelevant.
Seriously, no matter that you code well or like a shit, this leak is really really in low priority of leaks (we are talking about map init only, right ?), and virtually can't affect your map.

Don't confuse more people with trying to add one quite useless standard

"useless standard"?
Hmmm... afaik, people actually do stuff with groups/forces on Map init.
A leak is a leak, no matter how you turn it.

If the leak is insufficient lastly depends on the one coding.
In my opinnion this is good for people that want to keep their maps clean, despite the fact that you don't encourage people to keep it clean - it is though, a bit exaggurated if you state this as a Map stadard, but nevertheless it's all user preference, no?

 

[Troll-Brain]

despite the fact that you don't encourage people to keep it clean

That's obvious that you don't know me

Well, i simply want to mean GroupUtils does already do that and more.
Group recycling and GroupRefresh.

And still, even if you don't use groups for more than an instant, the extra code included inside the library is irrelevant.

but nevertheless it's all user preference, no?

Yes, like opinions, i just gave mine.

 

[Hatebreeder]

Yes, like opinions, i just gave mine.

To me, it sounded more like a judgement.
But meh, whatever =P

Jesus, will this also work for boolexpr?

 

[Jesus4Lyf]

You mean the principle working for boolexpr utils?
Yea but... just use boolexpr utils?..

The problem with GroupUtils is everyone (nearly) hates the recycling (for efficiency). Lol.

 

[Troll-Brain]

The problem with GroupUtils is everyone (nearly) hates the recycling (for efficiency). Lol.

Sadly, i have to agree.
At least that's the case for me, but still it should be irrelevant compare to create/destroy a group all the time.
Hmm, we need a benchmark

Anyway i use GroupUtils but with my version :

library GroupUtils initializer init
 
globals
    //* Group for use with all instant enumerations
    group ENUM_GROUP = CreateGroup()
    
    //* Temporary references for GroupRefresh
    private boolean Flag                                              = false
    private group Refr                                                = null
    
    //* Arrays and counter for the group stack
    private group array Groups
    private integer Count = 0
    
    // Dummy unit for released groups
    private unit Dummy
endglobals

private function AddEx takes nothing returns nothing
    if Flag then
        call GroupClear(Refr)
        set Flag = false
    endif
    call GroupAddUnit(Refr, GetEnumUnit())
endfunction
    
function GroupRefresh takes group g returns nothing
    set Flag = true
    set Refr = g
    call ForGroup(Refr, function AddEx)
    if Flag then
        call GroupClear(g)
    endif
endfunction

function NewGroup takes nothing returns group
    if Count == 0 then
        return CreateGroup()
    else
        set Count = Count - 1
    endif
    debug call GroupClear(Groups[Count])
    return Groups[Count]
endfunction

function ReleaseGroup takes group g returns boolean
    static if DEBUG_MODE then
    
        if g == null then
            call BJDebugMsg(SCOPE_PREFIX+" Error: Null groups cannot be released")
            return false
        endif
    
        if IsUnitInGroup(Dummy,g) then
            call BJDebugMsg(SCOPE_PREFIX+" Error: Groups cannot be multiply released")
            return false
        endif
    
        if Count == 8191 then
            call BJDebugMsg(SCOPE_PREFIX+" Error: Max groups achieved, destroying group")
            call DestroyGroup(g)
            return false
        endif
        
    endif

    call GroupClear(g)
    debug call GroupAddUnit(g,Dummy)
    set Groups[Count] = g
    set Count = Count + 1

    return true
endfunction

function IsGroupReleased takes group g returns boolean // use it for debug purpouse only
    return IsUnitInGroup(Dummy,g)
endfunction


private function init takes nothing returns nothing
     debug set Dummy = CreateUnit(Player(13),'hfoo',0.,0.,0.)
     debug call ShowUnit(Dummy,false)
endfunction

endlibrary

I really hate this extended array and GetHandleId - OFFSET stuff.
Also, i don't see anything wrong with recycling a group which wasn't in the stack.
Because there is not GetTriggeringGroup function, or whatever, and if the user release a private group which shouldn't be, he should be shot anyway.

 

[Viikuna]

Its probably because Rising_Dusk is more a map maker than system maker. Those guys care more about debugging and stuff like that than efficiency, because most of their time is spent by fixxing random bugs from their maps.

edit. But yea, lols. I too use a modified version of GroupUtils myself

 

[Jesus4Lyf]

I use Recycle. Troll's modified GU is not good for detecting double frees, actually.

GU would be standard if it wasn't lame.
I agree that freeing a group should be fine regardless.
I also agree with Viikuna:
>Those guys care more about debugging and stuff like that than efficiency, because most of their time is spent by fixxing random bugs from their maps.


(PS. My background is mapper, I mapped in GUI for about 4-5 yrs before looking at JASS.)

 

[Troll-Brain]

I use Recycle. Troll's modified GU is not good for detecting double frees, actually.

Why ?
Anyway it's something personal and for me it's just fine. (as a personal thing )

 

[Jesus4Lyf]

method onCreate takes nothing returns nothing
    set this.g=GetGroup()
    call GroupEnumUnitsInRange(.g,stuff)
endmethod
method onDestroy takes nothing returns nothing
    call ReleaseGroup(this.g)
endmethod

Add double free bug -->

method onCreate takes nothing returns nothing
    if this.g==null then
        set this.g=GetGroup()
    endif
    call GroupEnumUnitsInRange(.g,stuff)
endmethod
method onDestroy takes nothing returns nothing
    call ReleaseGroup(this.g)
endmethod

And it helps how?