View RSS Feed

Development Team Blog

Address and Pointer, what's up with that?

Rate this Entry
If you've been a VDF developer for a while you've undoubtedly come across Pointer, but what about the Address type? Isn't that just redundant?

Pointer has been around seemingly forever, but you may or may not know that Pointer is not a real data type in its own right. If you type Pointer in the Visual DataFlex Studio editor and hover your mouse cursor over the word, you'll see a tooltip that says "Alias type Pointer Integer". So even though it's been around for so long, and it's documented as a valid type, it's really just Integer in disguise. This means that any calculations or conversions with Pointer is treated just as Integer, because, well, it really is Integer.

Address is not really new, it was introduced all the way back in VDF 7, but it's managed to stay in the shadows. As opposed to Pointer, Address is actually a real distinct data type in all its glory. This means that the compiler and runtime treats Address differently from Integer/Pointer.

The specifics of the Address type has not been clearly documented, mostly because it's been considered advanced usage and peculiar behavior. For the most part Address is sort of like Pointer/Integer. But there's one important difference in advanced usage scenarios, automatic conversion between Address and String type performs a null terminated C string copy operation. That's a mouthful, and it's not something most VDF developers do all that much. You really need to know what you're doing as it's very easy get it wrong and cause a crash or memory leak. This specific behavior was the main reason this data type was created, for fast and efficient conversion between null terminated C style strings and VDF String type. It was an internal need for WebApp support back in VDF 7 and WebApp Server 3.

The Address type also came with a few related functions, Alloc(), Free(), AddressOf() and some other memory management functions. This enables a VDF developer to perform low level pointer manipulation and memory management operations, and glue it together with the higher level String type.

Like I said, the main trick with Address is to quickly and easily access/copy a null terminated C string. For example:

    Address pStr
    String sStr
    Move pStr to sStr
In one neat and compact line of code, Move pStr to sStr, it's performing a low level null terminated C string copy operation, automatically resizing and assigning the VDF String variable accordingly.

This also works the other way around, but then you have to make sure you have allocated a buffer large enough to hold the null terminated C-style string. IOW, with greater power comes greater responsibility. It's giving you easy access to bridge low level memory buffer manipulation with high level VDF types, but it's your responsibility to make sure it's doing the right thing.

There are some other neat tricks you can pull off when combining these things to bridge low level memory access with String, such as a quick and easy Char[] to String conversion:

Procedure TestIt
    Char[] myCharArray
    Address pStr
    String sStr
    Move (Ascii("H")) to myCharArray[0]
    Move (Ascii("e")) to myCharArray[1]
    Move (Ascii("l")) to myCharArray[2]
    Move (Ascii("l")) to myCharArray[3]
    Move (Ascii("o")) to myCharArray[4]
    Move 0 to myCharArray[5]

    //Treat the Char[] as a null terminated C string and quickly copy it to a String variable
    Move (AddressOf(myCharArray)) to pStr
    Move pStr to sStr

    Showln sStr    
The Address type is also used in other places in the framework for passing around large buffers that are otherwise impractical or too big to be handled by String. For example, the paXml property.


  1. Bernhard Ponemayr's Avatar
    Wow, i wish that i got this Infos some Year's ago. That makes some things really easier to handle.

    Best thanks for giving us this helpful Info's.
  2. Frank Cheng's Avatar
    Totally agree with Bernhard there