What is best... define.s variable or define variable.s

[Oso]

And following on from Shardik's post, you can also do this:

Code: Select all

Define MyString.s = "Test 1"
Define MyString$ = "Test 2"
Define *MyString = @"Test 3"

Thanks to all for the examples, the subject has covered more than I expected

What would the use of pointer variables be, typically, as in your example? I'm aware they exist, from short excursions into C programming in the past but their use has always been rather unclear to me.

In other words, when you can say NAME$="My name" and then overwrite that with NAME$="New name", why would you want to instead define *NAME and then POKE its memory location?

[Oso]

Yes, the type is only needed for the declaration. [snipped]

Thanks, what I had in mind was whether it was better to reference the variable with its type throughout the code, so that it becomes self-documenting.

For example, in the code, if you define productCode.s but later just use productCode, others won't necessarily know when looking at a piece of code that it's a string. I know they look at how it's defined, but would it be better to just use productCode.s throughout? Or would that be regarded by most PB developers as being over the top?

[Little John]

For example, in the code, if you define productCode.s but later just use productCode, others won't necessarily know when looking at a piece of code that it's a string.

That's why infratec wrote:

Personally I prefer the $ at the end for strings, this is always at the end of the variable and so I see that it is a string.

For the same reason, I personally also use only string variables (and named string constants, too) with $ at the end.
It's almost impossible to overestimate the importance of code readability.

[Demivec]

What would the use of pointer variables be, typically, as in your example? I'm aware they exist, from short excursions into C programming in the past but their use has always been rather unclear to me.

In other words, when you can say NAME$="My name" and then overwrite that with NAME$="New name", why would you want to instead define *NAME and then POKE its memory location?

The use of pointers is definitely for more advanced purposes and coding. Some of these include: to increase speed of execution by not copying data but instead by using a pointer to it; for use with API functions that act on and return pointers to data and structures; for use with some PureBasic functions that require and return pointers in their functions (i.e. prototypes, callbacks, the ChangeCurrentElement() list function, almost all memory functions).

As you noticed with the simple example that was given to change a string's content, it isn't necessarily more efficient or effective to use a pointer than another method to accomplish something. The choices on what to do are based on a balance of the usual range of values of ease of use, speed, simplicity, need, programmer's skill and preferences, adaptability, debugging, etc.

[BarryG]

What would the use of pointer variables be, typically, as in your example?

I don't know, to be honest. I was just pointing out that the same variable name with a leading asterisk can also exist in addition to the others.

[Olli]

Appending to the queue of Shardik, BarryG, then #NULL...

And following on from Shardik's post, you can also do this:

Code: Select all

Define MyString.s = "Test 1"
Define MyString$ = "Test 2"
Define *MyString = @"Test 3"

Debug MyString  ; "Test 1"
Debug MyString$ ; "Test 2"
Debug PeekS(*MyString) ; "Test 3"

In addition to barry's post above:
When using addresses of string literals, keep in mind that identical literals will be reused, so different pointer variables could point to the same string, affecting each other:

Code: Select all

EnableExplicit

Define s1.s = "test"
Define s2.s = "test"
s2 = "test2"
Debug s1             ; test
Debug s2             ; test2

Define *s3 = @"test"
Define *s4 = @"test"
PokeS(*s4, "x")
Debug PeekS(*s3)     ; x
Debug PeekS(*s3)     ; x

But I don't know why you would want to use pointers to string literals, especially poking at them will corrupt memory if the poked string is to long. There is no automatic reallocation like with normal string operations:

Code: Select all

*s = @"0123"
ShowMemoryViewer(*s, 100)
Delay(1000)
PokeS(*s, Space(38))
ShowMemoryViewer(*s, 100)

... I post this short example :

Code: Select all

Define MyString.s = "Test 1"
Define MyString$ = "Test 2"
Define *MyString = @"Test 3"
Define *OtherString.string\s = "Test 4"

Debug *OtherString\s

[#NULL]

... I post this short example :

You have to work a little more on that one though . It's wrong and causes an IMA. It's just a pointer, you need to allocate and assign a memory to before writing.

<edit>

Code: Select all

Define structString.String\s = "test1"
Debug structString\s

Define *pStructString.String = AllocateStructure(String)
*pStructString.string\s = "test2"
Debug *pStructString\s
FreeStructure(*pStructString)
*pStructString = 0

[Olli]

I knew, there are always risks in participating in a queue of regulars like that.

Code: Select all

Define other.string\s = "real test 4.1"
Define *another.string = AllocateMemory(SizeOf(string) )
*another\s = "real test 4.2"

@NULL
You have been faster...
I do not know if, in this way, I must use AllocateStructure()

[Oso]

That's why infratec wrote:

Personally I prefer the $ at the end for strings, this is always at the end of the variable and so I see that it is a string.

For the same reason, I personally also use only string variables (and named string constants, too) with $ at the end.

Yes, $ is convenient and it makes it clear throughout the code. But I was thinking more in terms of the range of variable types, not only strings. For example, the PB documentation lists a dozen Basic Types, some of which include the below.

Code: Select all

.b byte
.c character
.u unicode
.l long
.i integer
.d double

Let's assume we've defined our variables at the top of our code. When someone else happens to be maintaining the main body of our code, it isn't always going to be clear what the types are, just from looking at variable names alone. It's necessary to keep referring back to the definitions, in other words.

Therefore, would it be reasonable to append all variables with their type, throughout the code? Or would that be regarded as unnecessary 'bloat' by many PB developers? It's often better to follow the developer community norms.

[Oso]

You have to work a little more on that one though . It's wrong and causes an IMA. It's just a pointer, you need to allocate and assign a memory to before writing.

Code: Select all

Define structString.String\s = "test1"
Debug structString\s
Define *pStructString.String = AllocateStructure(String)
*pStructString.string\s = "test2"
Debug *pStructString\s
FreeStructure(*pStructString)
*pStructString = 0

I have to admit, some of this is ahead of my capability at the moment, as I've only been learning PB for a few days, but I noticed you've defined a pointer without the @ before the literal string. In some of the previous examples, starting with BarryG's, the literals are prefixed with @... but not in the above "test2".

Code: Select all

Define *s3 = @"test"
Define *s4 = @"test"

[Tenaja]

, would it be reasonable to append all variables with their type, throughout the code? Or would that be regarded as unnecessary 'bloat' by many PB developers? It's often better to follow the developer community norms.

If you have ten programmers, you'll get a dozen opinions on that!

Personally, I started going prefixing the type back in the 90s and usually stick with that. So instead of MyString and MyInt, I use sMyString and iMyInt. I think Petzold got me started on that, but not sure.

[Oso]

, would it be reasonable to append all variables with their type, throughout the code? Or would that be regarded as unnecessary 'bloat' by many PB developers? It's often better to follow the developer community norms.

Personally, I started going prefixing the type back in the 90s and usually stick with that. So instead of MyString and MyInt, I use sMyString and iMyInt. I think Petzold got me started on that, but not sure.

Yes, I think I've seen int and str used as prefixes in Visual Basic code in the past.

[#NULL]

You have to work a little more on that one though . It's wrong and causes an IMA. It's just a pointer, you need to allocate and assign a memory to before writing.

Code: Select all

Define structString.String\s = "test1"
Debug structString\s
Define *pStructString.String = AllocateStructure(String)
*pStructString.string\s = "test2"
Debug *pStructString\s
FreeStructure(*pStructString)
*pStructString = 0

I have to admit, some of this is ahead of my capability at the moment, as I've only been learning PB for a few days, but I noticed you've defined a pointer without the @ before the literal string. In some of the previous examples, starting with BarryG's, the literals are prefixed with @... but not in the above "test2".

Code: Select all

Define *s3 = @"test"
Define *s4 = @"test"

*s3 and *s4 are bare pointers without anything stringy about them. They just happen to point to memory location where a string is stored.
\s is accessing a structure field of name 's' and of type '.s' so it behaves like a normal string variable, just that it's part of a structure. The pointer *pStructString does not point to a string, it points to a memory block of type 'String', a predefined structure (which contains a string variable in form of a field named 's'). Note the allocation does not use the backslash, because we assign to the structure pointer, not to the string field. But the string assignment uses the backslash to assign to the field. No @ required because the pointer/memory/string management is done automatically by PB in the background, that's what the string type (.s) is for after all.
https://www.purebasic.com/documentation ... emory.html
https://www.purebasic.com/documentation ... tures.html

[Oso]

*s3 and *s4 are bare pointers without anything stringy about them. They just happen to point to memory location where a string is stored.
\s is accessing a structure field of name 's' and of type '.s' so it behaves like a normal string variable, just that it's part of a structure. The pointer *pStructString does not point to a string, it points to a memory block of type 'String', a predefined structure (which contains a string variable in form of a field named 's'). Note the allocation does not use the backslash, because we assign to the structure pointer, not to the string field. But the string assignment uses the backslash to assign to the field. No @ required because the pointer/memory/string management is done automatically by PB in the background, that's what the string type (.s) is for after all.
https://www.purebasic.com/documentation ... emory.html
https://www.purebasic.com/documentation ... tures.html

It's interesting but the documentation doesn't mention 'predefined structure'. In those two pages mentioned, there's only this line that makes use of .string but it doesn't say much about the meaning of .string or why it's .string and not .s

Code: Select all

  *Pointer.String = @*Text  ; *Pointer points on *Text

I can see from trying it out, that .string is a reserved word and that I can't change this to an arbitrary text like stringy. Likewise it allows .long, .word, .byte, .integer, but I can't seem to find any coverage of them, or why they are not .l .w .b .i etc. @*Text is used in the above example. Hopefully I'll get the hang of this at some point

[#NULL]

I don't know if the documentation talks about predefined structures, but you can find them in
Menu > Tools > Structure Viewer > Tab 'Structures' > scroll down list to 'String' and doubleclick to see Definition