? Strings passed as references if accessed like an array (Page 1) ● SmileBASIC Source Forums

Sign In

Register
*Usernames are case-sensitive
Forgot my password
This website has been moved, please see this post

Strings passed as references if accessed like an array

  • #1 ✎ 1882 12Me21 Syntax Highlighter Received for creating the code syntax highlighter on SBS Night Person I like the quiet night and sleep late. Express Yourself DEF 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 ✎ 477 SquareFingers Don't you mean "Strings passed as references"... and stop there? Try INC ARG$,"ING" Posted Edited by SquareFingers
  • #3 ✎ 90 HackTheWorlds Second Year My account is over 2 years old Website Summer 2016 Contest Participant I participated in the SmileBASIC Source Summer 2016 Contest! Programming Contest Reading I like to read books! Hobbies You 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 ✎ 1882 12Me21 Syntax Highlighter Received for creating the code syntax highlighter on SBS Night Person I like the quiet night and sleep late. Express Yourself I 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 ✎ 90 HackTheWorlds Second Year My account is over 2 years old Website Summer 2016 Contest Participant I participated in the SmileBASIC Source Summer 2016 Contest! Programming Contest Reading I like to read books! Hobbies If 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 ✎ 1882 12Me21 Syntax Highlighter Received for creating the code syntax highlighter on SBS Night Person I like the quiet night and sleep late. Express Yourself What 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 ✎ 1130 snail_ Power User QSP Contest 1 Contest Participant I participated in the first SmileBASIC Source QSP Contest! Helper Received for being very helpful around SmileBASIC Source Achievements Amazing Contributor Someone thinks I'm an awesome person who has done so much for the community! Achievements Strings 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 ✎ 477 SquareFingers It'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