PureBasic Forums - English

I did a search for this, with variations, and found an interesting slanging match on multiple processes.

But nothing on what I was looking for.

So, is there a way to find the type of a variable, from a pointer or address to that variable.

Eg:

No, it's not possible because PureBasic doesn't has any extra (mainly useless) information to know of which type is a variable. Anyway, it groups all the long, word and byte together, so it could be possible to detect these primitive type (for global/main variable only) by comparing their addresses.

Okay, thanks for the answer. Appreciate it.

Any progress now that PB 4 is out? I understand it's been heavily redesigned, could that make it easier to determine the type of a variable?

MEMORY DEGRADING WARNING ON...

Sometime back I peeked around the value returned by @Variable and @Array() and found some interesting things... I even wrote some simple routines to swap variables around... and I also wrote insert and delete array elements; but wondered what happened with the memory allocated to string element that were pushed out of the end of an array and became orphaned.

I felt I was on thin ice because I was assuming that the method of storing variables might change... so I stopped.

This does remind me... Insert() and Delete() are mighty handy array operations and are simple additions at low level... Fred?

No, PB isn't an intepreted langage which means you can't really detect of which type is a variable on runtime (especially when being in a procedure).

RichardL wrote:This does remind me... Insert() and Delete() are mighty handy array operations and are simple additions at low level... Fred?

Every value is at the base address of the array plus the index multiplied by the size of the type (or a pointer). Insert and delete will need to move every index of the array that is after where you insert or delete. Not hyper-efficient, actually.

Hi Trond.
I'm not sure this is right...

For insert and delete of varibles of known size (all numeric types) this can be very efficient.

Using the customary rules for moving a block where the destination and source overlap it is quicker to move the variables in memory than use a BASIC loop that needs to compute address' from the array index each time.

As an alternative, copying the entire array to a buffer and putting it back could take advantage of high speed block moves. I admit this is not a nice method, but when speed is of the essence it is a technique worth considering. ( I have done this in a hardware system and used an FPGA to move RAM blocks around... the alternative was to design an address mangle that left the data static and remapped the addresses with an ALU... even nastier )

Do the Intel family processors have MOVE *A1, *A2, N ? If so then block moves should run like grease lightning. (No PC ASM here, yet!)

You can probably do these functions yourself as ReDim is available with PB4 (with the help of MoveMemory()).

What's the point of MoveMemory() when we've got CopyMemory()??

Trond wrote:What's the point of MoveMemory() when we've got CopyMemory()??

MoveMemory() moves it and CopyMemory copies it?

CopyMemory() doesn't work if the memory areas overlaps.

It definetely does. I've used it like that many times.

Kale wrote:

Trond wrote:What's the point of MoveMemory() when we've got CopyMemory()??

MoveMemory() moves it and CopyMemory copies it?

MoveMemory() leaves a black void?

Trond wrote:It definetely does. I've used it like that many times.

Code: Select all

Mem = AllocateMemory(6)
For I = 0 To 5
  PokeB(Mem + I, I)
Next

For I = 0 To 5
  Debug PeekB(Mem + I)
Next
Debug "---"
CopyMemory(Mem, Mem+2, 6-2)
For I = 0 To 5
  Debug PeekB(Mem + I)
Next

Backwards too?

freedimension wrote: Backwards too?

Code: Select all

...
CopyMemory(Mem, Mem-2, 6-2)
...

Surely, provided you do not write outside allocated memory (Mem-2).