Pointers without *
-
- Enthusiast
- Posts: 384
- Joined: Sat May 24, 2003 8:02 pm
- Location: Canada
- Contact:
Pointers without *
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.
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.
<br>"I deliver Justice, not Mercy"
    - Codemonger, 2004 A.D.
    - Codemonger, 2004 A.D.
-
- Enthusiast
- Posts: 384
- Joined: Sat May 24, 2003 8:02 pm
- Location: Canada
- Contact:
I was thinking more like so ---
from Documentation:
what i would like to see:
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.
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
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.
<br>"I deliver Justice, not Mercy"
    - Codemonger, 2004 A.D.
    - Codemonger, 2004 A.D.
-
- Enthusiast
- Posts: 384
- Joined: Sat May 24, 2003 8:02 pm
- Location: Canada
- Contact:
Yeah, but variables should only be declared once, otherwise your code would look like this:Maybe i havn't thought this request through enough but i think that would be way too confusing! FACT: Strictly declared variables avoid bugs.
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
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.
<br>"I deliver Justice, not Mercy"
    - Codemonger, 2004 A.D.
    - Codemonger, 2004 A.D.
-
- Enthusiast
- Posts: 499
- Joined: Wed Sep 17, 2003 9:17 pm
- Location: Southern California
- Contact:
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
).
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

@}--`--,-- A rose by any other name ..
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
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'

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
Last edited by blueznl on Sat Oct 02, 2004 9:10 pm, edited 1 time in total.
( PB6.00 LTS Win11 x64 Asrock AB350 Pro4 Ryzen 5 3600 32GB GTX1060 6GB)
( The path to enlightenment and the PureBasic Survival Guide right here... )
( The path to enlightenment and the PureBasic Survival Guide right here... )
- tinman
- PureBasic Expert
- Posts: 1102
- Joined: Sat Apr 26, 2003 4:56 pm
- Location: Level 5 of Robot Hell
- Contact:
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.blueznl wrote:*a.BYTE = 5
means 5 is written in memory on the spot where *a points to
Bah, you know that pointers rule! ;pblueznl wrote:(we'll accept the confusion :-))
If you paint your butt blue and glue the hole shut you just themed your ass but lost the functionality.
(WinXPhSP3 PB5.20b14)
(WinXPhSP3 PB5.20b14)
ouch, typo, gonna re-edit
*a.byte <> *a\byte
oops
*a.byte <> *a\byte
oops
( PB6.00 LTS Win11 x64 Asrock AB350 Pro4 Ryzen 5 3600 32GB GTX1060 6GB)
( The path to enlightenment and the PureBasic Survival Guide right here... )
( The path to enlightenment and the PureBasic Survival Guide right here... )
-
- Enthusiast
- Posts: 613
- Joined: Tue May 06, 2003 2:50 pm
- Location: Germany
- Contact: