Pointers

General FreeBASIC programming questions.
anonymous1337
Posts: 5494
Joined: Sep 12, 2005 20:06
Location: California

Post by anonymous1337 »

Probably you did not understood what I meant.
Probably you have no idea what the hell you're talking about, srsly.
if you can write an operating system without using any pointers (thereby preventing memory leaks, of course :D) then perhaps we can talk about changing FreeBASIC to not use pointers either
function pointers.. srsly useful.
Nxx
Posts: 32
Joined: Dec 23, 2007 20:50

Post by Nxx »

vdecampo wrote:Reminds me of the song..."We're on a road to nowhere!" :-)
Well good discussion I think. I dont understand why some people dont like it. Such discussions help to find truth or better understanding.
anonymous1337
Posts: 5494
Joined: Sep 12, 2005 20:06
Location: California

Post by anonymous1337 »

I dont understand why some people dont like it. Such discussions help to find truth or better understanding.
Well, someone in the discussion usually has to have some idea of what they're talking about >.>;;
Nxx
Posts: 32
Joined: Dec 23, 2007 20:50

Post by Nxx »

notthecheatr wrote: OK, if you can write an operating system without using any pointers (thereby preventing memory leaks, of course :D) then perhaps we can talk about changing FreeBASIC to not use pointers either (by the way those OSes weren't written in FreeBASIC, nor could they possibly be without rewriting rtlib - besides, every program that huge will have bugs, no matter what: even without pointers.)
I wrote OS parts though with assembly. I think an OS should use safe methods as far as possible. Where it is not possible, for example when you need to access FAT table placed in some part of the physical memory by BIOS or when you need access external devices, the OS should use POKE/PEEK-like operators for direct ports/memory access. The data once received by the program should stay is safe form all the way. The main reason for that is to stay with boudary-controlling data types (such as strings) to prevent buffer overflows.
Don't you realize that arrays are normally stored sequentially in memory? The only way you can do this is if you don't store arrays sequentially, in which case you're basically using pointers, not array indices!
Yes that is one of the problems: arrays are stored sequentually. But why not to allow arrays not to be sequentual? For example with array of objects or strings, why not to allow array elements to be separated? Take for example array of forms Forms(4) as Form1. When Forms(3) is closed, it still reserves memory even if it is unloaded because the array is sequentual. This is odd i mean. Unload Form(3) should free the memory for other uses.
KristopherWindsor
Posts: 2428
Joined: Jul 19, 2006 19:17
Location: Sunnyvale, CA
Contact:

Post by KristopherWindsor »

You wondered why pointers are necessary; here are two examples.

1)

I made a GUI library (which I will be posting soon), and it has a function that will say which button or text box (or any other object in the library) was last clicked by the user.

I could have it return the label of the object:
(note this is not exactly the real code I use for the library)
If igui.get_last_click = "Quit" Then System 'clicked the quit button
The problem is, some buttons don't need labels, some labels are always changing, some two buttons might have the same label, and string comparisons are slow.
So instead, I use pointers:
If igui.get_last_click = @my_quit_button Then System 'clicked the quit button
I can use this same code even if my_quit_button is a text box instead of a button.

2)

INIMe

This object / class I wrote uses pointer for two reasons:

2.1)

Firstly, it keeps a list of variables, but some of them are numbers, and others are strings. You cannot store numbers and strings in the same array:
mydata(1) = 55: mydata(2) = "Hi, forum!" 'not possible if mydata() is an array of a built-in type
The only way to keep both numbers and strings in the same array is with pointers:

Code: Select all

variable_pointers(variable_total) = @variable
variable_types(variable_total) = variable_enum.vdouble
In INIMe, this only requires a pointer, and a variable to specify whether the pointer points to a number (integer, single, or double) or string.
If you did this without pointers, you would need a variable for the Integer, Single, Double, and String, and another variable to state whether the element of the array is supposed to be a number or string. This would take about twice as much memory and probably would be slower.

2.2)

In the example, you can see that even though you want y to equal x, they are not equal after x changes:

Code: Select all

'Code without pointers
Dim as Integer x, y
x = 5
y = x
x = 6
Print x, y
Sleep
Sometimes you will need y to equal x, even if x changes. You can do this with pointers:

Code: Select all

'Code with pointers
Dim as Integer x
Dim as Integer Ptr y
x = 5
y = @x
x = 6
Print x, *y
Sleep
Notice that, even though x changed in x = 6, x and *y are still equal.
(This is because, x and *y access the exact same memory.)

I used this in INIMe, where y (the pointer) is part of the object, and is not managed directly by programmer who uses INIMe.
In this line, INIMe sets a pointer to point to v1:
datadb.add("variable 1", v1)
Then later in the program, the programmer might type datadb.save to save variable v1 to a file.

V1 might change between those two lines:

Code: Select all

datadb.add("variable 1", v1)
v1 = 999
datadb.save
For this object to work, datadb (the INIMe object) has to save "999" to the file, not the value of v1 when the line datadb.add("variable 1", v1) was run. This is only possible with pointers.

... And that's why pointers are necessary.
BTW, feel free to post this in QB Express. ;-)
Dr_D
Posts: 2451
Joined: May 27, 2005 4:59
Contact:

Post by Dr_D »

if fb didn't have pointers, how would we know which way to go? :p
Nxx
Posts: 32
Joined: Dec 23, 2007 20:50

Post by Nxx »

KristopherWindsor wrote:You wondered why pointers are necessary; here are two examples.

1)

I made a GUI library (which I will be posting soon), and it has a function that will say which button or text box (or any other object in the library) was last clicked by the user.

I could have it return the label of the object:
(note this is not exactly the real code I use for the library)
If igui.get_last_click = "Quit" Then System 'clicked the quit button
The problem is, some buttons don't need labels, some labels are always changing, some two buttons might have the same label, and string comparisons are slow.
So instead, I use pointers:
If igui.get_last_click = @my_quit_button Then System 'clicked the quit button
I can use this same code even if my_quit_button is a text box instead of a button.


If I remember correctly, in Borland Pascal there were variables of function and procedure type apart of concept of pointers. There were also veriables of object type.
KristopherWindsor wrote:
2.1)

Firstly, it keeps a list of variables, but some of them are numbers, and others are strings. You cannot store numbers and strings in the same array:
mydata(1) = 55: mydata(2) = "Hi, forum!" 'not possible if mydata() is an array of a built-in type
The only way to keep both numbers and strings in the same array is with pointers:
Visual Basic has a concept of collection for an array of variables of different type. You can also use arrays with universal data type Variant.
KristopherWindsor wrote:
Sometimes you will need y to equal x, even if x changes. You can do this with pointers:
In fact the concept of pointers in such use is quite safe. The pointers are safe if you

1. Don't declare variables through pointers:

Code: Select all

Dim y As Pointer
*y=5
but use constructs where all vars have their own proper name:

Code: Select all

Dim x As Integer 
y=@x
*y=5 
Or in more traditional Basic syntax:

Code: Select all

Dim x As Integer 
Set y=x
y=5 
Why it is necessary? Because in such case any variable has its own parent object where it is declared. When the parent object is deleted, the variable is deleted also. When a variable is declared through pointer, it is an orphan variable with no parent object. When the object where the pointer was declared is deleted, the variable itsef (which occupies some memory room) is not necessary deleted which leads to a memory leak.


2. Dont use pointer arithmetics.
cha0s
Site Admin
Posts: 5319
Joined: May 27, 2005 6:42
Location: USA
Contact:

Post by cha0s »

Nah, with the 'new' operator, you don't need anything more than a pointer to the address created on the heap.

We can go back and forth about which is better, but imo, the real issue here is simply that the user is given the choice whether or not to use pointers. Who are you to attempt to dictate someone else's coding style?

All that we can hope to accomplish here is to establish your opinion that pointers are dangerous, and to be honest, I (partially) agree with you. Proper abstraction will eliminate your problems. Everything uses addresses on the lowest level, the key is hiding the ability to "shoot yourself in the foot" as much as possible, behind a sane interface.

The point is, no one is forced to use pointers, just like the OO. If that was the case, I would see your complaint as substantive.
notthecheatr
Posts: 1759
Joined: May 23, 2007 21:52
Location: Cut Bank, MT
Contact:

Post by notthecheatr »

Nxx wrote:Yes that is one of the problems: arrays are stored sequentually. But why not to allow arrays not to be sequentual? For example with array of objects or strings, why not to allow array elements to be separated? Take for example array of forms Forms(4) as Form1. When Forms(3) is closed, it still reserves memory even if it is unloaded because the array is sequentual. This is odd i mean. Unload Form(3) should free the memory for other uses.
If they aren't stored sequentially, how do we know where each index is stored? Only through pointers! Then we either keep the pointers hidden from the programmer (meaning in order to use such arrays we have to use an external library, and memory is lost by keeping pointers in addition to indices - otherwise we keep them in the open and pretend they're indices, which makes no sense at all!


Oh, and trust me dude - it would not be possible to write a modern operating system without pointers. Just a fact. You can't get paging or protected mode without pointers. Not gonna happen. Even if pointers weren't in the language, they have to be used at the low-level. At the low level, all the niceties of HLL's (like arrays for example) disappear and you're left with pointers. So you can forget about that being safer, the only difference is we check array indices to make sure they don't go out of bounds. We also check pointers to make sure they don't go out of bounds, so there's really not much difference.
Nxx
Posts: 32
Joined: Dec 23, 2007 20:50

Post by Nxx »

notthecheatr wrote: Oh, and trust me dude - it would not be possible to write a modern operating system without pointers. Just a fact. You can't get paging or protected mode without pointers. Not gonna happen. Even if pointers weren't in the language, they have to be used at the low-level. At the low level, all the niceties of HLL's (like arrays for example) disappear and you're left with pointers. So you can forget about that being safer, the only difference is we check array indices to make sure they don't go out of bounds. We also check pointers to make sure they don't go out of bounds, so there's really not much difference.
Well I know how it works in the low level. There are addresses, interrupt vectors etc. That does not mean the OS should use them and pointer arithmetics. Any low-level operations when unavoidable can be done through i/o, poke operators etc. 1. Retrieve address. 2. Make calculations. 3. Use address for direct access. There is no concept of "pointers" in the assembly languages. There are simply numbers with addresses.
vdecampo
Posts: 2992
Joined: Aug 07, 2007 23:20
Location: Maryland, USA
Contact:

Post by vdecampo »

Nxx wrote:There is no concept of "pointers" in the assembly languages. There are simply numbers with addresses.
Ahem. I have tried to avoid posting in this thread like the plague, but I can't stand by and let patently false statements be bantered about like facts.

@NXX
Assembly uses pointers AND pointer arithmetic....

mov eax, DWORD PTR pImage 'Pointer to a 32bit image
mov ebx, PixelNumber 'Pointer to a specific pixel
mov edx, [eax+ebx*4] 'Calculate position of pixel and get value

I challenge you to perform this in ASM without pointers and pointer arithmetic.

And I can even write this ASM code in FreeBASIC!

Just face the fact that you want to operate in a language that hides how the computer REALLY works and will do things for you behind the scenes.

I want to operate at a much more basic level. Why? Because I can and I value the benfits of speed, scalability and control more than the added risk of mis-using pointers.

There is really no argument here. Pointers can get you into trouble. But so can lots of other things if you are not TRAINED in their proper use.

I vote on the side of pointers, hence I use FreeBASIC.

Feeding the Troll
-Vince
Nxx
Posts: 32
Joined: Dec 23, 2007 20:50

Post by Nxx »

vdecampo wrote: Ahem. I have tried to avoid posting in this thread like the plague, but I can't stand by and let patently false statements be bantered about like facts.

@NXX
Assembly uses pointers AND pointer arithmetic....

mov eax, DWORD PTR pImage 'Pointer to a 32bit image
mov ebx, PixelNumber 'Pointer to a specific pixel
mov edx, [eax+ebx*4] 'Calculate position of pixel and get value

I challenge you to perform this in ASM without pointers and pointer arithmetic.
It is not pointers. It is addresses.
vdecampo wrote: Just face the fact that you want to operate in a language that hides how the computer REALLY works and will do things for you behind the scenes.
Any language hides how the computer really works. For example you do not have access to processor's registers etc.
vdecampo wrote: I want to operate at a much more basic level. Why? Because I can and I value the benfits of speed, scalability and control more than the added risk of mis-using pointers.
Then you better should consider using C language. Though anything you can do with pointers can be done in safe way. Many programmers also cried that they need goto, but in fact you can do anything without thios operator if the language supports proper constructs.
vdecampo wrote: I vote on the side of pointers, hence I use FreeBASIC.
I saw the source code of FreeBasic and it made impression of a slightly modified C. You even the type of variable in declarations write before the name of variable unlike conventional Basic and Pascal. You use ''return'' operator just like in C. You use syntax like "MyRecord->Next->Next" instead of traditional for Basic "MyRecord.Next.Next". Finally you adopt the pointer syntax from C with @ and * operators. This syntax is essintial only for pointer arithmetics. Traditional Basic way with Set operator does not allow pointer arithmetics. Bt the syntax in FB is dangerous not only because it allows pointer arithmetics, but also because missing * or @ may cause program fault or hidden error, and errors of such class (missing *, @, * instead of @ etc) are very usual for C programming.
cha0s
Site Admin
Posts: 5319
Joined: May 27, 2005 6:42
Location: USA
Contact:

Post by cha0s »

Why did you ignore what I said?

Why are you still feeding this guy? He's obviously just trolling. vdecampo showed an example of using a pointer, and then doing arithmetic on it, in ASM, and this is a common thing.

Nxx, get a life.
anonymous1337
Posts: 5494
Joined: Sep 12, 2005 20:06
Location: California

Post by anonymous1337 »

It is not pointers. It is addresses.
That's what pointers are, ya dumb ass.
You even the type of variable in declarations write before the name of variable unlike conventional Basic and Pascal.
Use -lang qb then.
You use ''return'' operator just like in C.
Always did that, even in QB.
You use syntax like "MyRecord->Next->Next" instead of traditional for Basic "MyRecord.Next.Next".
For pointers, yes, you use ->. It's so we can tell them apart. FB could use the . if it wanted to, I'm sure - But we'd lose out on a good syntax, aye.
Traditional Basic way with Set operator does not allow pointer arithmetics.
You're not thinking of the right BASIC.
Bt the syntax in FB is dangerous not only because it allows pointer arithmetics, but also because missing * or @ may cause program fault or hidden error, and errors of such class (missing *, @, * instead of @ etc) are very usual for C programming.
Sucks for people like you who are too stupid to learn how to use things properly.
Why are you still feeding this guy?
He is a very good troll - And he stops at times to ask decent questions D: Set an example, Mr. StopFeedingTheTroll!

Well, I am guilty as well ;_;
VirusScanner
Posts: 775
Joined: Jul 01, 2005 18:45

Post by VirusScanner »

I think there's a valid point here. I personally am in favor of getting rid of all loop statements also, as they are unneeded. Instead, we can replace them with the much more traditional looking (and easier to understand...?) line numbers and GOTO. For example, this (bad) code:

Code: Select all

for i as integer = 0 to 10
  print i
next
end
Would be better written like this (note that implicit variables and suffixes make it even better):

Code: Select all

10 i% = 0
20 if i% = 10 goto 60
30 print i%
40 i% = i% + 1
50 goto 20
60 end
The second bit is obviously er... doing something, whereas with the first bit it takes a good hour or so to figure out it's printing the numbers 1 through 10. I can't figure out why anyone but those evil C programmers would put anything as ugly as a FOR loop into their language. Therefore, I'm boycotting... every programming language in existance? I guess I'll just have to write my own (what a concept).

---

I don't think it really matters if someone made a language that compiles C code with curly braces replaced with end* and called it BASIC. There are so many BASICs out there that I don't think there's a clear definition of what's BASIC and what's not anymore. The point is, in the end it's up to the people working on the compiler what goes in and what stays out. Sure, they could have designed it a million other ways, but they didn't, and I don't think there's any use arguing about it. If you can write a compiler that doesn't use pointers, I'd be very impressed (as I am with the fact the first FB was written in VBDOS), and then you're welcome to use your language all you want. But I think you may find yourself wishing you had pointers after a while. That's all I'll say.
Locked