StringVar.s contra StringVar$

[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.

[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

[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.

[Little John]

Some people prefer the toilet paper to hang down the front, others prefer it to hang down the back.

[jacdelad]

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.

[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.

[luis]

Religious wars started for a lot less.
I would prepare my flag with a $ on top of it but someone could misunderstand it.

[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.

[Mijikai]

.s is stylistically more consistant therefore $ should be rejected.

[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

[mk-soft]

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

[Mohawk70]

I use $ for protected/local scope & .s for global scope.

[idle]

I alway just thought someone's having a bad day no need to swear$ @#$##
I prefer .s

[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!

[idle]

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