Snippet Explode String

[Romek]

> this is absolutely bugged for seperators that are longer than one char.
No it isn't. It simply doesn't support it.

> If you can't handle length n seperators, please post that.
It was useless, unneeded, and extra work.
Besides, it is posted:
"Note that if 'separator' is more than one character long, only the first character will be used."

> You even say it would work with "char(s)".
Oh damn. (s) made someone complain. =|

 

[dare2care]

I think you should add functionality so if you put maximum as -1 it is set to unlimited. (or some very high number)

 

[Romek]

There's an internal limit anyway.

.
        //  Change the [10] to the maximum amount of substrings
        private string array S [10]

 

[SerraAvenger]

old strings don't get cleaned when the struct is destroyed, thus it is possible to retrieve old data :/

// These line fix the problem
        method onDestroy takes nothing returns nothing
            local integer i = 0
            loop
                exitwhen i > .size
                    
                set .S[ i ] = null
                
                set i = i + 1
            endloop
        endmethod

 

[Romek]

> old strings don't get cleaned when the struct is destroyed, thus it is possible to retrieve old data :/
Ermm. Ok.
Not that anyone would want to retrieve old data, but the option is there.

 

[SerraAvenger]

Hypothetical funny situation:

[ALL][COLOR="RoyalBlue"]Say_No_To_War:[/COLOR] -zoom 5000
DEBUG: Action: -zoom( 5000 )
DEBUG: Zooming In( 3700 )
[ALL][COLOR="Red"]SerraAvenger:[/COLOR] -zoom
DEBUG: Action: -zoom( 5000 )
DEBUG: Zooming In( 3700 )
[ALL][COLOR="Red"]SerraAvenger:[/COLOR] Wth?? bugged map I'll never play this again!!!

...^^
I think the option should be abolished ; )

PS: Now using this in 3 systems of Krusade. BsArc still uses my old splitter though.

 

[Romek]

You see, .size is there for a reason.
From [0] to [size-1], are the parts of the string that was exploded.
Everything over that is either nothing, or old strings.

So as long as you don't go over '.size', which there's no reason why you should, then it's fine.
If .size is too small, then increase it.
If the .size limit is too small, then increase it in the snippet code.

You may also want to note that if you do:
ExplodeString(somestring, " ", 5)
But it only explodes into 3 parts, as there are no more spaces, then .size will be 3.

Edit: Besides, as someone pointed out; If I did want to implement what you said, I'd do it in the create method. Same effect, but with less function calls.

 

[SerraAvenger]

OffTopic: Ouch, my post just vanished >_>

You are REALLY asking the user to manage the consistency of YOUR system?
I hope I just misread...

If .size is too small, then increase it.
If the .size limit is too small, then increase it in the snippet code.

You may also want to note that if you do:
ExplodeString(somestring, " ", 5)
But it only explodes into 3 parts, as there are no more spaces, then .size will be 3.

This is neither related to the problem nor necessary to spot, I know these details.

Besides, putting cleaning into initialisation is not really clean.
No need to optimise where it isn't necessary, especially when it comes at the cost of readability : /

Cheers, Davey

 

[Romek]

> I hope I just misread...
I think you're just misunderstanding everything.

> This is neither related to the problem nor necessary to spot, I know these details.
Oh, but it is. The fact that the extra slots could hold old strings doesn't matter if you make sure to not use the index above [size-1]

> Besides, putting cleaning into initialisation is not really clean.
Yes it is.
Cleaning all the old values, so that all the extra arrays are blank. Same effect, but more efficient.

 

[SerraAvenger]

>Oh, but it is. The fact that the extra slots could hold old strings doesn't matter if you make sure to not use the index above [size-1]

The stuff I quoted was not related to how old strings are managed, it was related to size managment of ExpStrings
Also you should take care that nothing invalid is returned over [size-1], not the programmer who uses your code.

What would you do with a unit indexing system that returns random stuff for units that aren't indexed?

The coder might not even know when bad stuff is returned, because the player of the map inputs invalid data (eg just typing -zoom instead of -zoom VALUE). And It should be your duty to save the avid programmer lots of time trying to locate and debug the error source.

Besides I'm a DRY programmer. I'm not going to write a check for indicies whenever I'm trying to access an array. I'll let the accessing function do it.

>Yes it is.
>Cleaning all the old values, so that all the extra arrays are blank. Same effect, but more efficient.

If you think so...
I usually let my washing mashine wash my dish after eating, not only when I see I have no clean plates anymore.

And still I don't think the few extra calls here and there really matter that much. I'm not exploding 500 strings per second, am I?^^
If I was, then most probably my code is the problem, not the few extra function calls / trigger evaluations per exploding.

 

[Romek]

> Also you should take care that nothing invalid is returned over [size-1], not the programmer who uses your code.
Not really. If someone chooses to deliberately misuse the system, then what can they expect, working code?

> What would you do with a unit indexing system that returns random stuff for units that aren't indexed?
That's a silly comparison.

As for your -Zoom thing:

Explode: "-Zoom 5000"
[0] -> "-zoom"
[1] -> "5000"
.size = 2

Explode: "-Zoom"
[0] -> "-zoom"
.size = 1

Check if .size is greater than 1 before zooming. If it isn't, then don't do anything.
Also, if all the extra slots were "", then the game would zoom right into the ground (0 zoom).

> If you think so...
Same effect, different method.
The result will be that all unused indices will be "".
I don't know why you're dragging this on.

Also, your example works in my favour:
> I usually let my washing mashine wash my dish after eating, not only when I see I have no clean plates anymore.
Whether you wash the dishes before you eat, or you wash them after. You'll have them clean the next time you eat something.

> And still I don't think the few extra calls here and there really matter that much. I'm not exploding 500 strings per second, am I?^^
Same effect, one is shorter and more efficient. Which would you pick?

 

[SerraAvenger]

If someone chooses to deliberately misuse the system, then what can they expect, working code?

Deliberately is just such a hard word.
Accidentally fits the situation much better.
If you hit the "EVOKE FATAL ERROR" button by accident, you are glad if it pops a message "Really evoke fatal error?".
BTW, you might add this comment to your snippet:

.size will be the amount of array slots used. WARNING: Because I think it's not worth the hazzle implementing a safety check for bad indicies, note that you need to cnp the following lines whenever you're trying to access a ExpString field ( replace INDEX by the index you are requesting, CODE by the Code in which your are accessing the field and EXPSTRING by the name of the ExpString variabe you use. )

if INDEX < EXPSTRING.size and INDEX > 0 then
    CODE
debug else
    debug call BJDebugMsg( "Bad Index requested!" )
endif

If you do not, the code may show random behaviour. Thanks for your cooperation and sorry for any inconvience caused.

...This must be the longest post for a snippet ever...

> What would you do with a unit indexing system that returns random stuff for units that aren't indexed?
That's a silly comparison.

The difference being that you return random stuff for indicies that aren't indexed instead of units that aren't indexed?

Check if .size is greater than 1 before zooming. If it isn't, then don't do anything.

DRY = DontRepeatYourself.
I'm not going to cnp 2 extra lines whenever I'm accessing a ExpString field.

Also, if all the extra slots were "", then the game would zoom right into the ground (0 zoom).

I'm checking for the parameter to have a valid value, thanks.
Because there always might be users who really end up typing really small values - even if just accidently, I'm trying to help my users.
No need for a "You stupid moron, by clicking this button the game fataled. It even says "EVOKE FATAL ERROR" !"

Whether you wash the dishes before you eat, or you wash them after you after. You'll have them clean the next time you eat something.

after I after :S?
So you hypothetically never wash your dish unless you're going to eat something, and see you have no clean plates anymore?
(assuming your dishwasher washes it almost instantly)

Same effect, one is shorter and more efficient. Which would you pick?

I'ld take the third option, which is more efficient, more readable, and shorter.
And If one is more conventional and the other one is a tiny bit more efficient (on a place where efficiency doesn't matter at all), I'll go with the conventional one.

Anyway, since we have the source I'll just fit this to my needs. No need in arguing with you about the way you code

 

[Romek]

> BTW, you might add this comment to your snippet:
No.

> after I after :S?
Scratch the last "I after", and reread.

> So you hypothetically never wash your dish unless you're going to eat something, and see you have no clean plates anymore?
This is where the whole dishwasher thing fails.
The ExpString is cleaned instantly. So time isn't an issue.
And ExpStrings don't rot and stink either. So that isn't an issue.

To be honest, you seem to be the only one with a problem about this. Nobody should use the indices equal to, or above .size. There's even a clear and easy way of checking this.
And you seem to be making up some pretty random situations in which clearing the indices would actually help. And even those aren't anything major.

> I'ld take the third option, which is more efficient, more readable, and shorter.
There are 2 options there. The first one, and the second one.
Neither of them are particularly 'unreadable' either. So it's just about efficiency.
And if it's more readable for you, I don't really care to be honest. This wasn't created with you reading it in mind.

> Anyway, since we have the source I'll just fit this to my needs. No need in arguing with you about the way you code
Indeed.
Feel free to modify the code however you like, as long as you don't resubmit it anywhere.

(I just remembered, I need to add support for multiple character separators. So much other stuff to do though. =|)

 

[JerseyFoo]

It's been a long time since I JASSed, so probably some syntax issues here, but this ought to be more efficient.

function splitString takes string b, string s, integer m returns array
    local integer x = 0
    local integer y = 1
    local integer n = 0
    local string array pieces
    m = IMaxBJ(m, 1)
    set local integer l = StringLength(s)
    loop
        exitwhen y > l or n >= m
        loop
            exitwhen y > l or SubString(s, y - 1, y) == b
            set y = y + 1
        endloop
        set pieces[n] = SubString(s, x, y - 1)
        set n = n + 1
        set x = y
        set y = y + 1
    endloop
    return pieces
endfunction

splitString(" ", "Don't rock the boat baby", 4) = ["Don't","rock","the","boat"]
splitString("-", "Don't rock the boat baby", 4) = ["Don't rock the boat baby"]


to remove 'max' functionality, delete

• , integer m
• line "m = IMaxBJ(m, 1)"
• " or n >= m" from line "exitwhen y > l or n >= m"

I don't see why a struct would be used for a basic function but again; very rusty.

I included "m = IMaxBJ(m, 1)" in case JASS allows optional parameters. Going by your code I'm assuming a non-opted integer would be 0.

EDIT: looked around and found that "local array pieces" must be "local string array pieces" ?

 

[Romek]

I'm aware that this could be made slightly more efficient, and I'm also aware that I need to add support for multiple-character separators.
I'm fully capable of editing minor codes, thanks.

I'll update this soon, MrApples.

Edit: It doesn't look like your code will work with multiple separator characters next to eachother;
splitString("^", "Hello^^^World", 2) ?

 

[Troll-Brain]

Just my opinion, but instead of search the best speed ever, i think having the less strings generated (with SubString) does more matter, because of how war3 handle them.

If it's possible thought.
Anyway i guess having the less SubString possible means also the best efficiency.

 

[JerseyFoo]

Edit: It doesn't look like your code will work with multiple separator characters next to eachother;
splitString("^", "Hello^^^World", 2) ?

The code needed 2 new lines, I've added them. I don't see a situation where that would be useful either.

splitString("^", "Hello^^^World", 2) should return ["Hello",""]. As would explode() or String.split()

I'm fully capable of editing minor codes, thanks.

What are you referencing to?

I need to add support for multiple-character separators.

What's the point? JASS has terrible string manipulation, any situation that would require this can be done in a better fashion.

 

[JerseyFoo]

Excuse the double post.

I've been told through the User CP that JASS doesn't allow returning arrays. Now I see why you would use a struct, but why not use a global?

explodeString() sets results to global udg_explodeString

It may seem awkward but JASS itself is awkward.

 

[Romek]

Other than the fact that you have to clear them up, dynamic arrays/structs are a much neater way of doing this.
Besides, what if one wants to keep the results for a while?

 

[JerseyFoo]

Besides, what if one wants to keep the results for a while?

Same way as they would with anything else, store it to a variable.

local array = udg_explodeString