Strings passed as references if accessed like an array
#1✎ 188212Me21Syntax HighlighterReceived for creating the code syntax highlighter on SBSNight PersonI like the quiet night and sleep late.Express YourselfDEF EXAMPLE ARG$
ARG$[0]="R"
END
STRING$="TEST"
EXAMPLE STRING$
?STRING$
REST
EDIT: All strings are passed as references. Have fun. (You can still use the STRING$=STRING$+"" (or STRING$*1) trick to get around this)
Posted
Edited
by 12Me21
#2✎ 477SquareFingersDon't you mean "Strings passed as references"... and stop there? Try INC ARG$,"ING"
Posted
Edited
by SquareFingers
#3✎ 90HackTheWorldsSecond YearMy account is over 2 years oldWebsiteSummer 2016 Contest ParticipantI participated in the SmileBASIC Source Summer 2016 Contest!Programming ContestReadingI like to read books!HobbiesYou can use PUSH and POP on strings as well so I think strings just act like arrays in SmileBASIC. I can see where there might be a problem but this also sounds kinda useful if you ask me. The real problem is that there is no almost no type checking with DEF, which means you can put a string into array parameter or an array into a string parameter.
Posted
#4✎ 188212Me21Syntax HighlighterReceived for creating the code syntax highlighter on SBSNight PersonI like the quiet night and sleep late.Express YourselfI don't really see the lack of type checking to be a problem, since it would just cause an unnecessary error. I suppose it could catch a few typos, but it would also break many programs where people have tried to use the minimum amount of characters or something.
Posted
#5✎ 90HackTheWorldsSecond YearMy account is over 2 years oldWebsiteSummer 2016 Contest ParticipantI participated in the SmileBASIC Source Summer 2016 Contest!Programming ContestReadingI like to read books!HobbiesIf you were to write an DEF that expected an array as a parameter, why would you ever want a string to be passed in? It would just cause an error somewhere in the DEF. That's why there should some type checking with DEF functions. If you specify two strings for the coordinates in a GPSET command, it throws a type mismatch error because GPSET can't work with two strings. That's what should happen with DEF in my opinion. You define the parameters and a call to that function simply won't work unless the arguments match the parameter types.
Posted
Edited
by HackTheWorlds
#6✎ 188212Me21Syntax HighlighterReceived for creating the code syntax highlighter on SBSNight PersonI like the quiet night and sleep late.Express YourselfWhat about arrays and string arrays
how is
DEF EXAMPLE ARRAY$
different from
DEF EXAMPLE STRING$
or
DEF EXAMPLE NUMBER
different from
DEF EXAMPLE ARRAY
and what if you wanted to accept multiple variable types?
like
DEF CPRINT COLOR%,VARIABLE
COLOR COLOR%
PRINT VARIABLE
END
Posted
#7✎ 1130snail_Power UserQSP Contest 1 Contest ParticipantI participated in the first SmileBASIC Source QSP Contest!HelperReceived for being very helpful around SmileBASIC SourceAchievementsAmazing ContributorSomeone thinks I'm an awesome person who has done so much for the community!AchievementsStrings behave as linear arrays when used in such contexts so this is generally normal behavior. HOWEVER, I've noticed that strings are by-reference when accessed as arrays (this includes stack instructions PUSH etc.) and by-value when otherwise. At least, this appears to be the case to me.
DEF TEST I$
I$="A"
END
VAR A$="B"
TEST A$
?A$
A$ isn't mutated at all. It's still "B". And yet:
DEF TEST I$
I$[0]="A"
END
VAR A$="B"
TEST A$
?A$
A$ becomes "A" this time. This behavior is inconsistent and the only reason I can think of why is that string operators instantiate a new string in the heap (immutable strings like basically everything else) and array operations manipulate the memory in-place. In the first case I$ becomes a local reference which is destroyed when the scope exits.
Posted
#8✎ 477SquareFingersIt's not inconsistent, once you take in all the implications of a string variable containing a reference to a string value. Imagine you didn't use a parameter, instead you assumed that the incoming string was always in the global variable A$. Then,
DEF TEST I$
becomes
DEF TEST
VAR I$
I$=A$
Now, I$ contains a reference to the same thing A$ refers to. If you manipulate the thing referred to by I$, then you manipulate the thing referred to by A$, because they refer to the same thing. If you make a new string, and its reference is put into I$... you're not changing the fact that A$ refers to what it refers to.
Posted
Edited
by SquareFingers
