Page 1 of 2
StringVar.s contra StringVar$
Posted: Sat Jul 01, 2023 11:08 am
by micha-b
I know StringVar.s and StringVar$ are two different things - but what makes them different?
What's the deeper sense of having two different types for string variables and when to use which one?
Kind regards,
Micha B.
Re: StringVar.s contra StringVar$
Posted: Sat Jul 01, 2023 11:19 am
by STARGÅTE
In the background, these strings are from exactly the same type, performance etc.
But keep in mind that the $ is part of the variable name. So you can declare StringVar$ and StringVar.s as separate variables (but it is not recommended).
I think, the declaration with the $ is just a leftover from the good old Basic era, similar to Dim instead of NewArray for example.
I prefer to use only StringVar.s
Re: StringVar.s contra StringVar$
Posted: Sat Jul 01, 2023 11:30 am
by luis
They are the same data type but two different variables.
I prefer to use StringVar$ because when I look at the source then I can spot strings easily, I never use .s if I can avoid it.
Sometimes I have to use StringVar.String when I want to pass a input-output string to a procedure and that to me is horrible enough to look at.
Re: StringVar.s contra StringVar$
Posted: Sat Jul 01, 2023 12:02 pm
by Little John
Some people prefer the toilet paper to hang down the front, others prefer it to hang down the back.
Re: StringVar.s contra StringVar$
Posted: Sat Jul 01, 2023 12:14 pm
by jacdelad
Little John wrote: Sat Jul 01, 2023 12:02 pm
Some people prefer the toilet paper to hang down the front, others prefer it to hang down the back.
Comparing parts of purebasic with toilet paper? You should prepare yourself for a shitstorm.
I use both variants without any pattern.
Re: StringVar.s contra StringVar$
Posted: Sat Jul 01, 2023 12:50 pm
by infratec
If you use $ at the end, you can avoid the word String in front to see that it is a string
Less typing, easier to read.
Re: StringVar.s contra StringVar$
Posted: Sat Jul 01, 2023 1:02 pm
by luis
Religious wars started for a lot less.
I would prepare my flag with a $ on top of it but someone could misunderstand it.
Re: StringVar.s contra StringVar$
Posted: Sat Jul 01, 2023 1:46 pm
by infratec
But you need .s in a structure if you use it for ExtractJsonStructure() because $ does not fit the name of the json key.
Else, .s and $ are usable vice versa.
Re: StringVar.s contra StringVar$
Posted: Sat Jul 01, 2023 2:19 pm
by Mijikai
.s is stylistically more consistant therefore $ should be rejected.
Re: StringVar.s contra StringVar$
Posted: Sat Jul 01, 2023 2:46 pm
by RASHAD
I agree with luis
When I receive an error message Number expected instead of a string I catch where the error exist directly
But still no harm to have both
Re: StringVar.s contra StringVar$
Posted: Sat Jul 01, 2023 2:52 pm
by mk-soft
infratec wrote: Sat Jul 01, 2023 12:50 pm
If you use $ at the end, you can avoid the word String in front to see that it is a string
Less typing, easier to read.
But you have to press the shift key to get a "$".
It is best not to mix
A dynamic string variable is a pointer to the characters of string
When a string is changed, the pointer can change, for example, if the memory space for the new string is too small.
To pass a string ByRef to a function, one must pass the pointer to the pointer of the string (Stupid text!).
Code: Select all
Global fixedString.s{16}
Global fixedString${16}
Global dynamicString.s
Global dynamicString$
Global structString.String
fixedString = "Hello "
fixedString$ = "World!"
dynamicString = fixedString + fixedString$
dynamicString$ = UCase(dynamicString)
Debug dynamicString
Debug dynamicString$
structString\s = dynamicString$
Procedure fcStringByRef(*refStr.String)
*refStr\s = "*** " + *refStr\s + " ***"
EndProcedure
fcStringByRef(@structString)
Debug structString\s
Since number variables have a fixed size, this can pass the pointer to the number
Code: Select all
Global varInteger.i
Procedure add(*var.Integer, value = 1)
*var\i + value
EndProcedure
varInteger = 10
Debug varInteger
add(@varInteger, 10)
Debug varInteger
Re: StringVar.s contra StringVar$
Posted: Sat Jul 01, 2023 5:40 pm
by Mohawk70
I use $ for protected/local scope & .s for global scope.
Re: StringVar.s contra StringVar$
Posted: Sat Jul 01, 2023 9:20 pm
by idle
I alway just thought someone's having a bad day no need to swear$ @#$##
I prefer .s
Re: StringVar.s contra StringVar$
Posted: Sat Jul 01, 2023 10:02 pm
by skywalk
Whoa! A single character tells me string data type or not. What's not to like?
Next you .s people will demand we drop the * from all our *Pointers?!?
Never!
Re: StringVar.s contra StringVar$
Posted: Sat Jul 01, 2023 10:34 pm
by idle
skywalk wrote: Sat Jul 01, 2023 10:02 pm
Whoa! A single character tells me string data type or not. What's not to like?
Next you .s people will demand we drop the * from all our *Pointers?!?
Never!
people have to use pointers 1st!
I'd prefer *foo.i or *str.s