Thread Rating:
  • 1 Vote(s) - 5 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Function to edit a string (*solved*)
#1
Bug 
I'm having trouble passing a string to a Function in order to edit it. The code which works fine outside of a Function just won't modify the string inside the Function for some reason. Any idea what I'm doing wrong?
Code:
DIM a$ AS String

FUNCTION editStringFN(stringToEdit$ AS String, position AS Integer, newLetter$ AS String) AS String
    stringToEdit$(position)=newLetter$
    RETURN stringToEdit$
END FUNCTION

CLS
a$="sample"
PRINT a$; "- original string"

'try to edit string via the function
a$=editStringFN(a$, 1, "i")
PRINT a$; "- function fails to edit"

'same edit without using the function
a$(1)="i"
PRINT a$; "- works as regular code"
Reply
#2
Hmm. Judging from the wiki documentation, ByREF seems to be what I need here, but it doesn't seem to help. The example usage is with arrays not strings. Is there a way to achieve what I'm trying to do here?
The reason I wanted to use a function is that I have several sprites stored as strings, and I want to edit multiple sprites in fundamentally the same way - hence the function to avoid code repetition.
Reply
#3
Yes, you need to use ByRef if you want the variable passed to the SUB / Function to be changed. Otherwise, you're passing a copy of the value. ByRef also works with strings and numeric variables.
Try and tell me, please. Rolleyes
Reply
#4
No, it doesn't seem to work. See example - the function won't edit the string:
Code:
DIM a$ AS String

FUNCTION editStringFN(ByREF stringToEdit$ AS String, pos AS Integer, newLetter$ AS String) AS String
    stringToEdit$(pos)=newLetter$
    PRINT AT 10,0; stringToEdit$
    RETURN stringToEdit$
END FUNCTION

CLS
a$="sample"
PRINT a$; "- original string"

'try to edit string via the function
a$=editStringFN(a$, 1, "i")
PRINT AT 1,0;a$; "- function fails to edit"

'same edit without using the function
a$(1)="i"
PRINT a$; "- works as regular code"
Reply
#5
Ok. This looks like a regression bug that compiler tests failed to detect! Sad
This is *CRITICAL*. Will fix it ASAP.

One more thing: If you pass it byref you don't need to return the value since it's already changed.
Reply
#6
Okay, this beta fixes that bug. Please, try it and tell me if it works Rolleyes :

http://www.boriel.com/files/zxb/zxbasic-...ta9.tar.gz
http://www.boriel.com/files/zxb/zxbasic-...-beta9.zip
http://www.boriel.com/files/zxb/zxbasic-...-win32.zip
http://www.boriel.com/files/zxb/zxbasic-...x64.tar.gz
http://www.boriel.com/files/zxb/zxbasic-...cos.tar.gz
Reply
#7
This fixes the BYREF issue with my simple test program I posted above in this thread. However, it makes my game code unstable and crashes the Spectrum. Will send the code via PM.
Reply
#8
I had originally been returning the amended string from the FUNCTION using RETURN, which is no longer necessary when using BYREF.
I had deleted the RETURNed result from my code, but I forgot that I had declared the function AS STRING, which Boriel quickly spotted.
I needed to delete that from the end of the FUNCTION declaration, since I was no longer returning anything. Once that was done the code was stable. 

To avoid this error condition I presume a compiler check is needed for FUNCTION type declarations when nothing is being RETURNed. Perhaps it should require such a FUNCTION to be changed to a SUB instead. I've done this in my code since I noticed the compiler was defaulting the FUNCTION type to float when the declaration was removed.
Reply
#9
(01-03-2021, 12:44 AM)patters Wrote: I had originally been returning the amended string from the FUNCTION using RETURN, which is no longer necessary when using BYREF.
I had deleted the RETURN from my code, but I forgot that I had declared the function AS STRING, which Boriel quickly spotted.
I needed to delete that from the end of the FUNCTION declaration, since I was no longer returning anything. Once that was done the code was stable. 

To avoid this error condition I presume a compiler check is needed for FUNCTION type declarations when nothing is being RETURNed. Perhaps it should require such a FUNCTION to be changed to a SUB instead. I've done this in my code since I noticed the compiler was defaulting the FUNCTION type to float when the declaration was removed.

Yes, I'm working on it. This is a bit harded than it sounds as I was planning to start code-analysis for v1.15 onwards. Anyway, I'll add little code analysis now.
Reply


Forum Jump:


Users browsing this thread: 4 Guest(s)