[Implemented] StringField() empty string out-of-range

[Demivec]

I request that StringField() return an empty string for out-of-range indexes.

As of PB 4.41 it does this if the index is too high, but not if it is too low (< 1).
If it is too low it is returning the same result as it would if the index were 1.

[ts-soft]

I put sometimes the false index (0) in my code (FindString) and it works. Why will you change this?
I would request: only a compilerwarning, but code should work as in all pb-versions!

[Kaeru Gaman]

@ts:
well, it fact it did not work, it just did not crash.

Code: Select all

a$ = "one,two,three,four"
Repeat
  b$ = StringField(a$,field,",")
  field +1
  Debug b$
Until b$ = ""

as you see, when you start with 0 the result is wrong because the first field is returned twice.

in the discussion thread I voted that this is not to be called a bug,
just take care not to request invalid indices below 1.

[Demivec]

@ts-soft: Code should work as in previous versions of PB, since the behavior wasn't defined for out-of-range indexes

@ts:
well, it fact it did not work, it just did not crash.

Code: Select all

a$ = "one,two,three,four"
Repeat
  b$ = StringField(a$,field,",")
  field +1
  Debug b$
Until b$ = ""

as you see, when you start with 0 the result is wrong because the first field is returned twice.

in the discussion thread I voted that this is not to be called a bug,
just take care not to request invalid indices below 1.

@Kaeru Gaman: I agree that it is not a bug. It just seems peculiar. Here is a sample work-around that does what I requested:

Code: Select all

a$ = ",one,two,three,four"
c = CountString(a$,",")
Repeat
  b$ = StringField(a$,field + 1,",")
  field +1
  Debug b$
Until  field > c + 1

I believe you spoke against changing it based on speed concerns. If the needed fix is that a check of the indexes be coded prior to calling StringField() then I think this could be done faster natively.

Perhaps a simple help file update could be made instead of a feature request. I'll leave that to the Admins.

[Mistrel]

An empty string suggests nothing between two fields. By returning the whole string you can actually compare your result to assess a "done" condition without knowing the number of fields ahead of time.

[Demivec]

An empty string suggests nothing between two fields. By returning the whole string you can actually compare your result to assess a "done" condition without knowing the number of fields ahead of time.

That's a good point.

Code: Select all

a$ = "too_low,one,two,three,four,too_high"
c = CountString(a$,",")
Repeat
  b$ = StringField(a$,field + 1,",")
  field +1
  Debug b$
Until  field > c + 1

[Fred]

While it's not strictly speaking a bug (undocumented behavior), a runtime debugger check has been added and it will return a null string if < 1 is used.

[UserOfPure]

So just to confirm: this runtime debugger check (and the extra code it uses) will NOT be present in final executables, right?

[Fred]

No, debugger runtime check are only added to the executable when the debugger is activated.

[Kurzer]

You could return the seprator string in case of invalid index.
It's variation of Mistrels suggestion.

[Mistrel]

Considering as how I rely on the current implementation I would rather this not be changed. It's more convenient to have it return the entire string when exceeding the index count than otherwise.

[blueznl]

I dunno, Mistrel, but it just might make sense do return an empty string. I mean, there's nothing there, so why should it return anything?

Take the string "a||c|d|", it contains 5 elements:

1 "a"
2 ""
3 "c"
4 "d"
5 ""

Now there's nothing at position 6, 7, 8 and so on, so to me it makes sense to return an empty string And if that applies to ound of bounds on the right side, then I would expect the same behaviour on the left side.

Oh well, it's all a matter of taste, I guess

[Foz]

Oh well, it's all a matter of taste, I guess


Somehow it does seem sensible to me if

if... what?

[Michael Vogel]

While it's not strictly speaking a bug (undocumented behavior), a runtime debugger check has been added and it will return a null string if < 1 is used.

I'm not sure if I will like to see differences in program execution between debugger mode and non debugging mode
This won't make debugging easier, what do you think?
Michael

Or do we have already other functions which are not working identical when debugging is switched on or off -- just not recognized by me

[Trond]

While it's not strictly speaking a bug (undocumented behavior), a runtime debugger check has been added and it will return a null string if < 1 is used.

I'm not sure if I will like to see differences in program execution between debugger mode and non debugging mode
This won't make debugging easier, what do you think?
Michael

Or do we have already other functions which are not working identical when debugging is switched on or off -- just not recognized by me

What do you mean? Its legal input remains the same. Only it fails more gracefully.

In my opinion, it should be legal to use out-of-bounds fields, and these should return null strings. This way the command is more forgiving, and in some situations it may be useful.