Pointers without *

[Codemonger]

Would be nice if pointers can be declared or initialized once using the * and then after that you could drop the * ... This would make code look cleaner and easier to read.

I like the idea of not having to initialize the memory for the pointers but the constant * irritates me. It says in the docs:

Note: Other than in C/C++ in PureBasic the * is always part of the variable name. Therefore *ptr and ptr are two different variables.

Why is this, is this just a design direction or is their a logical reason behind this.

[venom]

perhaps like:

ptr_to_struct.*mystruct
ptr_to_struct\... etc

[Codemonger]

I was thinking more like so ---

from Documentation:

Code: Select all

*MyScreen.Screen = OpenScreen(0,320,200,8,0)
mouseX = *MyScreen\MouseX ; Assuming than the Screen structure contains a MouseX field

what i would like to see:

Code: Select all

*MyScreen.Screen = OpenScreen(0,320,200,8,0)
mouseX = MyScreen\MouseX ; Assuming than the Screen structure contains a MouseX field

after initialization or declaration of the variable then you should not need the pointer. As far as I understand this is just semantics and would be done during parsing/preprocessing or whatever and shouldn't effect how the code works.

[Kale]

Would be nice if pointers can be declared or initialized once using the * and then after that you could drop the *

Maybe i havn't thought this request through enough but i think that would be way too confusing! FACT: Strictly declared variables avoid bugs.

[Codemonger]

Maybe i havn't thought this request through enough but i think that would be way too confusing! FACT: Strictly declared variables avoid bugs.

Yeah, but variables should only be declared once, otherwise your code would look like this:

Code: Select all

*MyScreen.Screen = OpenScreen(0,320,200,8,0) 
mouseX = *MyScreen\MouseX.Screen ; Assuming than the Screen 
mouseY = *MyScreen\MouseY.Screen ; Assuming than the Screen structure contains a MouseX field

You don't wan't to add .Screen every time you use the variable , so why add the asterisks. Heres my view on it:

The asterisks is OK for the initial declaration .. this tells the compiler that the variable is 32 bit long pointer and points to a structure that looks like XXXX. This is really only necessary for the compiler initially so when the compiler finds the pointer variable later in the program it can determine how many bytes have been offset from the initial memory address (the pointer refers to) where the data is stored using the declared structure. So beyond the initial declaration the pointer would only be as usefull or useless as adding the suffix of .variabletype ie .Screen

Anyway I don't think the * should be required beyond that point, as just like any variable in your program you should know what it is, and the compiler should also.

[PolyVector]

Well you wouldn't have Strings drop the $ after declaration would you?

[Dare2]

It would break things if the * was dropped.

However I agree with Codemonger in a conceptual sense. And although there is nothing recently posted, there have been a fair few posts in beginners that showed confusion with *varName -v- varName and the fact that they are not the same variable.

Also using $ for strings, although traditional, gives yetta way to do things. Perhaps it should be deprecated and no longer shown in the manual. Long live dot s (stirring the pot here ).

[blueznl]

i like strings! i love the $$$...

though i don't use it much anymore

keep it basic, $ is so basic that it's a bit hard to take out

re. *... currently all pointers are 32 bit long, once 64 bits show up, there may be an issue indeed with pointers...


pointers are a bit wacky, here's how things are now:

a = 5

means var a gets val 5

*a = 5

means var *a gets val 5

*a\BYTE = 5

means 5 is written in memory on the spot where *a points to

i am not going into the strange behaviour and naming scheme of pointers within structs... (this is something that should be changed asap imho)


to do things differently, and perhaps more logical, would break ALL existing code (duh), as the * would no longer be a part of the varname

a = 5

means var a gets val 5

*a = 5

would mean: write a long int (the default type, as no type has been given) to memory at the location where a points to

*a\BYTE = 5

ok, so we write a byte at that spot

would i take that change lightly? no... would i accept it? yes, as it would do the structure of the language quite some good, but lots of old users would be alienated


in a way, a pointer is nothing more but a var, often combined with a peek / poke, in gfabasic there were a few alternative wordings, some suggestions (dunno if they are good ones )

Byte{ <varname> } = <expression>
Byte{ a } = 5

(the reason they choose the {} characters is that too many users already used arrays with the name 'byte' of course a simple search and replace would fix this, so i'd take Byte() Word() Long() ULong() UWord() UByte() Quad() and UQuad() any time...)

I personally think this:

BYTE( a ) = 5

is more readable than

POKEB( a , 5 )

actually, i'd love to see fred adopt the above additional commands Byte() Word() etc., for readability as well as future compatibility, and the current pointer syntax could be kept alive without creating incompatibility (we'll accept the confusion )


oh darn, i ranted again, sorry

[tinman]

*a.BYTE = 5

means 5 is written in memory on the spot where *a points to

No, that is the same as your previous example. The value 5 is assigned to the variable/pointer *a. If you were to then write *a\b = 5 then the value 5 would be written to the byte in memory which is addressed by the value of *a.

(we'll accept the confusion :-))

Bah, you know that pointers rule! ;p

[blueznl]

ouch, typo, gonna re-edit

*a.byte <> *a\byte

oops

[freedimension]

The * is not only the declaration of a pointer, its part of the name and IMHO it's good the way it is.
The one thing I hate about C is, that pointers always look different, depending on what you are doing - in PB it's much cleaner and easier to understand