VB To Aurora

[Zen]

Im trying to convert some stuff from VB to Aurora but ive come accross this and i dont know what it is...

Code Select Expand


Public Type API_myulonglong
   bytes(1 To 8) As Byte
End Type


The (1 To 8 ) is what i dont understand. Can anyone help me out?

Lewis

[Ionic Wind Support Team]

It's an int64 since VB doesn't have one

[Zen]

Cheers Paul.

Lewis

[Zen]

Come across another one now, this time (1-9), still byte though.

Lewis

[Ionic Wind Support Team]

That is their way of defining an array.

VB and most basics allow using a 1's based index.

bytes(1-9) as byte

Translates to

byte bytes[9];

in aurora.

[Zen]

oh ok i see. Thanks Paul

Lewis

[Paul Squires]

That is their way of defining an array.

VB and most basics allow using a 1's based index.

bytes(1-9) as byte

Translates to

byte bytes[9];

in aurora.

Then I would assume that in Aurora the upper base of the array would be 8

byte bytes[8];   // 9 elements, 0 to 8

right?

[Parker]

In Aurora, IBasic, C, ... arrays are zero based, but when you define them you tell how many elements there are. So this array
int array[8];
makes array[0] to array[7]. It has the same behaivor in C.

[Paul Squires]

Ah, yes, that makes sense. Time for me to break out my C books....   

I am used to defining arrays in terms of lowest bound to upper bound.

[Barney]

I wish modern compilers or interpreters would do what Hewlett-Packard's BASIC was able to do in early 70's and that is, to define the array boundaries completely arbitrary. Here's the example:

DIM array[1900:2099]

This would create an array (we called it matrix then) of 200 elements and one would work with those elements by addressing them within defined boundaries, not from 1 to 200 or 0 to 199. This was (and still is) far more productive in terms of programming 'cause I as a programmer did not have to create and use the translation functions. I was addressing the arrays in the most natural manner pertinent to the problem. In this case the array index is actually a year.

array[1905]=something
something=array[2014]

If I used array[2120] in my code a compiler (or a run time package) would warn me that the array index is out of bounds.

I'd like to see something like that implemented in Aurora.

I also wish more people would know about HP BASIC, which in some of its more specialized parts is still years beyond what modern languages are giving me. But that's anoither story... 

Barney

[Parker]

That's an odd feature that some BASIC languages have, and it's actually more confusing to someone who has never used that method before, since you would assume that an array that goes up to 2099 actually has that many elements (actually 2100, 0 to 2099).

There are some modern languages that have that, mostly BASIC I think, but to me it looks a bit strange. I guess it's up to Paul, but I'd just use this method:

Code Select Expand

array[year-1905] = y;

They use the "TO" keyword, by the way.

Code Select Expand

dim array(10 to 20) as integer

[ThadMiller]

I suppose in looking at VB code, it's best to realize that declaring an array is Dim a(LowerBoundary To UpperBoundary) As Integer so when only 1 number is specified, it is the UpperBoundary and the LowerBoundary is defaulted to 0.  So if you Dim a(9) As Integer, you actually have 10 elements (0-9).

As for what to use in Aurora, that's up to Paul... as long as it's documented, it's easy to work around (there's not really much complex about arrays).

I have to mention a bad array experience I have had though... Microsoft wrote IIS, and Internet Explorer, right?  Both use VBScript.  So WHY is it that local VBScript is 1 based, while server side VBScript is 0 based?  It really makes troubleshooting DHTML a lot of fun.

-Thad

[Bruce Peaslee]

I have to mention a bad ... experience ... Microsoft

-Thad

I'll second that!

[Ionic Wind Support Team]

Aurora uses zero based arrays, the same as 99% of the other compiled languages out there.  Which makes more sense because '0' in terms of computer memory is a location, not a quantity.  All memory addresses start at 0.

int a[9];

has indexes 0 through 8 (9 total locations).   

Interpreters have the luxury of mucking about with index values.  Although I wouldn't call it a luxury.  Just something else to confuse programmers.  A variable in an interpreter is not a memory address, it is usually a structure of some sort that is allocated dynamically and passed along each step of the program. 

A compiler simply reserves space for a variable, by either using the stack, or specifying it in the data table of the executable.  The only information about a variable once it is compiled is its address.  No place to store a 'start' and 'end' index and still remain compatible with the API, other compiled languages, etc.

Consider an external function, in a static library:

declare extern MyFunction(int a[]);

The empty braces signifies that a is an array.  Arrays are always passed by reference so the only information you can give that function is the address of the array.  Function parameters are pushed onto the stack, 32 bits at a time.

int array[100];
MyFunction(array);

The first statement reserves 100 integer sized locations in memory and the second passes that address to the function.  The 100 is the reserved amount and not given to the function.  There is no way for the function to know whether or not you have allocated enough space. 

If you look at the Windows API you will see the most common solution to the problem.  Thats is to pass a second variable indicating how large the array is.  A string is an array of bytes

DECLARE IMPORT,GetWindowTextA(hwnd as UINT,lpszText as STRING,nMaxCount as INT),INT;

nMaxCount in this case is the size of the string, or byte array.  It is up to the programmer to specify the correct size.  In Aurora and my other languages I make it a bit easier, by allocating a string on the heap, asking windows how long the text to be returned is, and  return that string in the GetText methods of CControl.

So the bottom line is you won't see things like:

DIM array[1900:2099]

In compiled languages.  Because there is no way to pass that information.  And even if the compiler allowed it locally, in a single source file, you would run into problems trying to use it with projects.

Paul.

[Parker]

I have to say though, it's possible, but it makes all the array handling weird and require function calls and hidden pointer access to add and retrieve members from the array. You would define a structure

Code Select Expand

struct Array
{
    int lbound;
    int ubound;
    pointer pData;
}

And to use it

Code Select Expand

Array a;
a.pData = new(int, 10); // Define 10 ints, although they're from 100 to 109.
a.lbound = 100;
a.ubound = 109;
if (offset >= lbound and offset <= ubound) a.*(int)pData[offset-a.lbound] = 12;

The equivalent using a real array of 0 to 9 would be

Code Select Expand

int a[10];
a[offset] = 12;

You really don't want (and neither does Paul ) the compiler injecting all that code for array access. However, when operator overloading is supported (assuming it is), you'll be able to make a safe dynamic array that lets you do things like that.

[Barney]

Oh, I do realize something like DIM array[a:b] is much easier to do in interpreted environment and very hard in compiler environment. It was just a tought, because I really like the feature and use it a lot in my statistical programming. I never really expected it to be included, especially since it's fairly easy to implement it with properly designed classes used in my program.

Barney

[Ionic Wind Support Team]

[qoute]
You really don't want (and neither does Paul Wink ) the compiler injecting all that code for array access. However, when operator overloading is supported (assuming it is), you'll be able to make a safe dynamic array that lets you do things like that.

There is already a dynamic array class written in Aurora.  It is included with the samples. (oop1.src).

You don't need operator overloading just for safe dynamic arrays.  the only thing operator overloading gives you is code that might be easier to read, in some circumstances.  Harder to follow in others since you don't know what the class behaviour is just by looking at the code.

I have seen very poor overloading.  Classses using math operators, such as '+' to do things that have nothing to do with addition or concatenation. 

For those that don't know what parker has been bugging me about...consider a dynamic array.  You have two functions called SetAt and GetAt that take an integer index:

SomeArray::GetAt(int nIndex), int
{
....
}

SomeArray::SetAt(int nIndex, int nValue)
{
....
}


Which can be used on their own of course:

ar.SetAt(0, 100);
ar.SetAt(1,200);

Operator overloading lets you change the way the compiler treats certain symbols and create a method for handing them.  For example we could have syntax like this:

SomeArray::Operator[] ( int nIndex ),int
{
   return GetAt(nIndex);
}


As I stated in another topic that would be a lot of work for me to convince the parser to allow a method on the left hand side of an equal sign.

cl[1] = 100;

cl.Operator[] (1) = 100;

So it may be some time before we have such capabilities.

[Parker]

For those that don't know what parker has been bugging me about...

Sorry

I realize it's not necessary, and very hard to implement, just nice to have...

Well if you are going to try implementing it, I wish you lots of luck. If not, it's just a convenience and I'm okay without it.