Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

DarkBASIC Discussion / Funny thing i found out about dbc

Author
Message
Caleb1994
15
Years of Service
User Offline
Joined: 10th Oct 2008
Location: The Internet you idiot!
Posted: 13th Sep 2009 22:41
You can get the pointer to a string in a function. whatever value the function returns in Endfunction is the variable type that db thinks it is. so if you use a integer with endfunction but a string with exitfunction it returns the pointer! and if you flip that you can print a pointer! like this

function GetStrPtr(String$)
exitfunction string$
endfunction 0

function PrintPtr(Ptr)
exitfunction ptr
endfunction ""

Note, this returns the pointer to the local static copy of the variable String$ not the pointer to the String you put in so if you ran this:

String$ = "Hello, Whats your name?"
Ptr = GetStrPtr(String$)
Ptr2 = GetStrPtr("Another String")

print PrintPtr(Ptr)

it would print "Another String" not "Hello, WHats your name?".

This could be usefull when working with dll's that return pointers. you could use PringPtr(Ptr) or whatever you want to name the function, to get the string instead of using a memblock pointer and getting it that way. although whatever variable you put that string from the dll in. That variable would be the pointer to the dll's string. not a db string

New Site! Check it out \/
TheComet
16
Years of Service
User Offline
Joined: 18th Oct 2007
Location: I`m under ur bridge eating ur goatz.
Posted: 14th Sep 2009 08:02
There are a few things that can screw up DBC, but still run. Yours is one of them, I think. Here is another:



What happens if you try and point the camera to an object if that object is locked on to the screen?

TheComet


Make the paths of your enemies easier with WaypointPro!
Latch
17
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 14th Sep 2009 16:38
@Caleb1994
That's a pretty awesome discovery about exitfunction. Does:

function PrintPtr(Ptr)
exitfunction ptr
endfunction ""

Return the pointer to the integer or just the empty string? Or is it the pointer to the Function? And how could you test what pointer is being returned?


I don't know if you've run into it yet, but be careful using string pointers from DBC in a DLL. Many functions in the Win API for example, have a parameter that requires the string length. I have run into program crashes using DBC string pointers that I haven't set a length to before passing to a DLL. What I would guess is, not all DBC strings are automatically 255 bytes in length until that many bytes are stored in them. That's why printing an empty string "" only retrieves the first byte at the pointer. If it received the full 255, you'd see wierd characters representing the other 254 bytes in memory. You can run into some real trouble if you don't pass the correct length of the string with the pointer to a DLL. If you don't set the length of the string before adding it as a pointer in a DLL, you can inadvertently access memory that was reserved for something else and possible crash your program if not the whole computer.

@TheComet
Whoa! This is nutty!

1=2
print 1
wait key
end

I think I remember reading years ago that FORTRAN or maybe COBOL allows variable declarations something like that!

This looks similar to the pointer stuff that Caleb was talking about. If I were to guess, I would say that you are assigning the integer that is stored in the memory location that 1 is pointing to with the integer value of 2. But that's just a guess.

Enjoy your day.
BN2 Productions
20
Years of Service
User Offline
Joined: 22nd Jan 2004
Location:
Posted: 14th Sep 2009 19:53
Quote: "Whoa! This is nutty!"


No kidding, you could REALLY mess up someone's code by placing at the top

10=1

Or equivalent. Then all their math would fail when it used the number.

Great Quote:
"Time...LINE??? Time isn't made out of lines...it is made out of circles. That is why clocks are round!" -Caboose
pictionaryjr
15
Years of Service
User Offline
Joined: 12th Mar 2009
Location:
Posted: 15th Sep 2009 00:58
if you think about you could use something like hat1=2 then print hat1 and it would be 2, so maybe dbc prepares all numbers like a variable when you start it and assigns them a value, so all the numbers really are is variables.
Caleb1994
15
Years of Service
User Offline
Joined: 10th Oct 2008
Location: The Internet you idiot!
Posted: 15th Sep 2009 07:12 Edited at: 15th Sep 2009 07:19
Latch:

the PrintPtr(Ptr) Function returns a string, well Technically it returns the pointer but because dbc thinks it is returning a string(because endfunction is a string) you can assign it to a string variable and it will set that string to the string that that pointer points to. although if you have a bad pointer you will get a "Severe Exeption" error. in other words a "Access reading violation" in vc++ talk lol.

Havn't actually tested it with any dll's yet but that does make sense(the string length thing)

Just to make it clear GetStrPtr() Returns the pointer to the STATIC STRING VARIABLE FROM THE FUNCTION. NOT THE POINTER TO THE ACTUAL STRING YOU INPUTED. So This:



Would Print:


Just had to clarify

Although i have tested it and if you assign a string to the pointer then set the string to a different string it doesn't change the string in the function. i am geussing when you use the operator = it copies the string from the right hand string to the left hand string, and doesn't assign the pointer like the default char*(character pointer or in other words a string) data in c++ where if you used = it would assign the pointer.

The Comet: Bn2: Pictionary:

I am geussing what this is doing is creating a variable called "1" but if the variables are checked before the numbers then that would be interpreted as a variable not a number. it all depends how dbc translates it. thats my geuss that it thinks that 1 is now a variable and not a number.


Pictionary:

Quote: "if you think about you could use something like hat1=2 then print hat1 and it would be 2"


From the looks of that you are just using a regular variable. they are talking about changing values of numbers. so like change the value of 1 to 5 and the value of 5 to 100. with that this:

1 + 5 = 6

would be:

1 + 5 = 105



edit:

This function does have uses, i just found a way to use it in my Gui Functions. that way i can pass a string when the procedures only take integers! Just saying i already found a use. Yay

New Site! Check it out \/
Latch
17
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 15th Sep 2009 19:24
Quote: "I am geussing what this is doing is creating a variable called "1" but if the variables are checked before the numbers then that would be interpreted as a variable not a number. it all depends how dbc translates it. thats my geuss that it thinks that 1 is now a variable and not a number."

That's makes more sense than my pointer theory!

Enjoy your day.
Caleb1994
15
Years of Service
User Offline
Joined: 10th Oct 2008
Location: The Internet you idiot!
Posted: 16th Sep 2009 00:05 Edited at: 16th Sep 2009 02:19
Haha, Ya. although i don't really see that use in changing number values. except for a funny prank to do on someone.... hahaha



Edit:

oh comet:

Quote: "There are a few things that can screw up DBC, but still run. Yours is one of them, I think. Here is another:"


I wouldn't count this as screwing up dbc, more like tricking it you can't really mess anything up. there is no way to change pointers or alter dbc internal values so it's nearly impossible to screw it up with this.

New Site! Check it out \/
Caleb1994
15
Years of Service
User Offline
Joined: 10th Oct 2008
Location: The Internet you idiot!
Posted: 16th Sep 2009 22:17 Edited at: 16th Sep 2009 22:28
My Variable Theory was wrong! I tested it like this:



That prints:

1
1

If it was recognizing it as a variable then in the function 10 would still be 10. hmmm i geuss latches theory is the better one.

Quote: "I think I remember reading years ago that FORTRAN or maybe COBOL allows variable declarations something like that! "


Whats FORTRAN and COBOL?

Just looked up Fortran, Some of that looks a lot like dbc, including the way they have a if and endif pair and use Dimension command for arrays. hmmmm intersting. i love wikipedia

New Site! Check it out \/
Latch
17
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 17th Sep 2009 01:30
Quote: "If it was recognizing it as a variable then in the function 10 would still be 10. hmmm i geuss latches theory is the better one."


Interesting. It's almost a way to have globals in DBC without creating an array. It does seem to be behaving like a pointer. And with your other experiments with strings, does that mean there may be ways to get at pointers in DBC? It would be fantastic for 3d objects and images if that were the case.

Enjoy your day.
Libervurto
17
Years of Service
User Offline
Joined: 30th Jun 2006
Location: On Toast
Posted: 17th Sep 2009 13:16
that is very odd, have you tried:


TGC Forum - converting error messages into sarcasm since 2002.
Caleb1994
15
Years of Service
User Offline
Joined: 10th Oct 2008
Location: The Internet you idiot!
Posted: 17th Sep 2009 22:39 Edited at: 18th Sep 2009 00:04
I just did but it prints 1. although that makes sense considering if dbc is using pointers then it would assign the VALUE of the pointer not the actual Pointer.


Quote: "Interesting. It's almost a way to have globals in DBC without creating an array. "


Well you would have to use a number that is outragously huge that you would never actually use it. and even then the code would be confusing considering all the:



Hahaha.

At this point i have only been able to get pointers to static local strings of functions. not sure about using pointers all around. unless you kept object and image numbers in a string and used one function per image/object you need to use a pointer for and then used the local string pointer and the val() function. but other then that at this point i would say using pointers isn't that easy lol.

the only way you can is to find more ways to trick dbc into returning the pointer instead of value. with the string it was easy, because it is stored as a char* and if dbc returns a char* but the function is declared as return a integer then the char* will be converted to a integer and returned. with numbers i don't knw how you would "Trick" dbc like that. you would need to find a place where dbc uses pointers to numbers and then kindof intercept it in the process i geuss(kinda like the char* thing)


Edit:


I Have a idea. you could take the string pointer you get from my function and add to the pointer so if you have lets say the string "Hi" then you have the pointer to it then you add 3(3 because you have to include the null character at the end) then you can get each byte of the next variable(assuming that's how dbc does the variables. in order i mean) my only snag is i don't know how many bytes the dbc integer is.i was thinking 4 but i couldn't get that to work.

New Site! Check it out \/
TheComet
16
Years of Service
User Offline
Joined: 18th Oct 2007
Location: I`m under ur bridge eating ur goatz.
Posted: 18th Sep 2009 10:32


That would print one, because you declare the 1 as 9 after you set the variable num to 1. If you switch around the lines, I assume it would print 9:



TheComet


Make the paths of your enemies easier with WaypointPro!
Caleb1994
15
Years of Service
User Offline
Joined: 10th Oct 2008
Location: The Internet you idiot!
Posted: 18th Sep 2009 17:36 Edited at: 18th Sep 2009 17:43
Your right comet! Stupid me i didn't switch them! haha. this is really weird. The more i think about it the more it makes sense. if when you used numbers in dbc it really assigned the pointer then it makes sense that when you change the value ofthe pointer it changes it throughout the program because all number variables are global.

New Site! Check it out \/

Login to post a reply

Server time is: 2024-05-09 17:03:25
Your offset time is: 2024-05-09 17:03:25