Learning to use Aurora

[Haim]

How can I learn to use Aurora?  I have no experiemce in C/C++ but  I do have good knowledge of Borland's Delphi and OOPS in general.
Can anyone refer me to materials/documentation that will help me get acquainted with Aurora's syntax?
I have looked into the .inc files, and I can see the structures and functions. I need help with the syntax, and some "strange" operators such as "::", "-->" etc.
I am considering the purchase of the Aurora license and any help here would be greatly appreciated.

[Ionic Wind Support Team]

John S has started some documentation.  Here is a post copied from the tab Control thread that explains what OOP is and some of the syntax involved.

The -> is a shortcut form of dereferencing a pointer and accessing a member variable or function.  It works when the type of the pointer is know to the compiler. 

mytype *p = new(mytype,1);

//these are equivelents.
*(mytype)p.member = 1;
*p.member = 1;
p->member = 1;

Anyway here is that post.

A class is a type of variable, a very advance type but just a variable nonetheless.

Class, OOP, etc all came about with the idea of encapsulation.  Objects should manage their own data and not external global variables. 

Lets say you have a UDT containing all of the members needed to represent an image. 

Code Select Expand


struct myimage
{
int width;
int height;
int bpp; //bits per pixel
pointer memory; //where the graphic is stored
}


Then a bunch of functions that might take a parameter of the UDT type 'myimage'.  Basic stuff here, you have used it in other languages.

Code Select Expand


SUB LoadImage(mi as myimage, name as string)
{
...load the file
mi.width = GetWidth(name);
...etc
}

SUB ShowImage(mi as myimage, hwnd as UINT)
{
...
}

SUB SaveImage(mi as myimage, name as string)
{
...
}



So in order to use these functions you have to first define a variable of myimage and pass it to the functions.

Code Select Expand


def image1 as myimage;
LoadImage(image1, "happy.bmp");
ShowImage(image1, win.hwnd);
SaveImage(image1, "sad.bmp");


Simple enough, you are used to using UDT's.  And what you have done above is used OOP in its simplest form.  image1 is an instance of the myimage UDT.  The problems with the above method is that the programmer has to keep track of what function works with what UDT type.  What happens when someone changes the UDT definition without changing the subroutines?  It can get chaotic.

Classes extend the idea of a UDT 'object' by coupling them with functions that work with the data in that structure.  So lets look at a partial  class representation of the above.

Code Select Expand


class myimage
{
declare LoadImage(name as string);
declare SaveImage(name as string);
declare ShowImage(HWND as UINT);
int width;
int height;
int bpp; //bits per pixel
pointer memory; //where the graphic is stored
}

myimage::LoadImage(name as string)
{
...load the file
width = GetWidth(name);
...etc
}


Now when you declare a variable of that class you don't need the external UDT to hold the data.  Instead the compiler knows those particular members are part of the class

Code Select Expand


def image1 as myimage;
image1.LoadImage("happy.bmp");
image1.ShowImage(win.hwnd);
image1.SaveImage("sad.bmp");


What is happening here is the first statement defines a variable of type 'myimage' which is a class.  Internally it is just a structure (UDT) that has all of the member variables + 1 for a table of virtual functions.  If you were to peer into memory it would just look like a structure.

myimage
{
pointer _VTABLE_
int width;
int height;
int bpp; //bits per pixel
pointer memory; //where the graphic is stored
}

And you can use a class variable just like it was a UDT in most cases.

Code Select Expand


def image1 as myimage;
image1.width = 0;


The fun part comes with the member functions.  Lets look at one of them:

Code Select Expand


image1.LoadImage("happy.bmp");


The compiler translates this into a function call that kind of looks like this:

Code Select Expand


myimage@LoadImage(&image1, "happy.bmp");


Think about it.  When you wrote the class method for LoadImage the compiler first came up with unique name so the subroutine wouldn't clash with any other names, and then did something interesting.  It added a parameter at the beginning called the 'this' pointer.

Code Select Expand


myimage::LoadImage(name as string)
{
}


Gets converted to  (in psuedo terms)

Code Select Expand


SUB myimage@LoadImage(myimage *this, name as string)
{
}


The result is a group of subroutines, and the data associated with those subroutines, in one package known simply as an "object". When your code is executing within a method of that object (a subroutine of that class) it has direct access to the variables of the object structure.  For example consider the snippet, copied from above

Code Select Expand


myimage::LoadImage(name as string)
{
...load the file
width = GetWidth(name);
...etc
}


In particular the line

width = GetWidth(name);

"width" is a member variable of the class "myimage".  When the compiler encounters a variable name that your referencing in a class method it first checks the class to see if you have a member of that name.  In this case we do so in essance the compiler is doing this:

Code Select Expand


this->width = GetWidth(name);


'this' is that added parameter the compiler adds to each class subroutine.  It is a pointer whose type is the same as the class and an address of your class variable is passed.  Putting it together with the function call:

image1.LoadImage("happy.bmp");

translates to:

myimage@LoadImage(&image1,"happy.bmp");

------------

myimage::LoadImage(name as string)

translates to

SUB myimage@LoadImage(myimage *this, name as string)

------------

and

this->width = GetWidth(name);

accesses the 'width' member of the class structure passes automatically to the LoadImage method.

Understand?

[Ionic Wind Support Team]

And of course the example files included with the install can give you insight as well.

Plus the posts on the forums.

And if your looking for a book then any general C++ book will give you an idea of what all the OOP stuff is.  Even though Aurora isn't C++ it does follow many of the same methodologies and syntax.

[John S]

Haim,
I will post an updated Aurora Help file later today (I'm on the wrong machine right now).  It will include the c-type string functions.
I am working on the docs for Intrinsic Variables this week and program controls (FOR, While, IF, Select(Switch)/Case...).
OOP and derived variables (structs, arrays...) and classes will be started next week and following.
GUI stuff is going to be after that.

As Paul said, there are a few examples in the forum.  I picked a book at Barnes and Noble for $9.95 on C++ which they publish
"C++ Programming in Easy Steps (In Easy Steps Series)".  It is a good primer and a fast read.  It will help you get started until we get more docs out.

So far Paul can program faster than I can write docs

[Haim]

Thank you all so much.
That was very fast - much appreciated.
I am going to place my order right now!

[Ionic Wind Support Team]

We thank you for your support

Ask questions, play with the examples, break things and we'll show you the way to fix them.

[LarryMc]

Paul said:

//these are equivelents.
*(mytype)p.member = 1;
*p.member = 1;
p->member = 1;

UREKA!!!!!!!!!!!!!!!
A light bulb glows.

[Ionic Wind Support Team]

lol.

OK lets take it further and just discuss basic pointer usage.  A pointer is either typed, meaning the compiler knows what kind of data it points to, or untyped.

An untyped pointer can only be dereferenced if you tell the compiler what type of data it points to.  Lets say we have a function that returns a pointer.

POINTER p;
p = SomeFunction();
*p = 77;  //error since the compiler doesn't know the type.
*(INT)p = 77; //Cool since we are telling the compiler that 'p' points to an integer.

-----------

INT *p;
p = SomeFunction();
*p = 77;  //Cool since the compiler knows that 'p' points to an integer.

The first example is known as a void pointer in C.  Which can also be written as:

void *p;

Which again just tells the compiler that the type of the pointer isn't known at that point in the code.  Void pointers have their use when the data it points to might be different depending on how it is used. 

More later...dinner time.

[LarryMc]

It must be 'dawn' in Abilene 'cause I can see a little glow!!!

The next time that someone tells me:

'If ignorance is a grain of sand then you're the sahara desert.'

I'll be able to snap back......."Oh yeah! "

[donh]

Thanks Professor Paul finaly information I can read and understand.
This is some good stuff to have a section in the documentation.

John hint hint hint

[Ionic Wind Support Team]

And on with the discussion...

Pointers are just a variable whose purpose is to store an address.  An address is a location in your PC's memory and for 32 bit CPU's that address is a 32 bit number. 

A pointer can hold the address of any type of data you wish to reference.  Commonly used to hold the address of some allocated memory since you need to tell the system you are done with the memory at some point.

This may be old hat for some of you, so bear with me.  Allocating and freeing memory is something all programs do, and the terms may be confusing at first. 

INT *p;
p = NEW(INT, 1000);

Lets look at whats going on here.  First we are defining a pointer and telling the compiler it points to data of type INT.  Then we are asking the system for an address of a memory block we can use to store 1000 integers.

Memory isn't being created, it is just being reserved for you.  The system gives you an address at the beginning of a 4000 byte block of memory and marks it as belonging to your program, so no other program can access it.

Now we have an array, dynamically allocated, that we can use just like any other array.  With the one difference that it is just an address so we need to tell the compiler to dereference the pointer before accessing the array.

*p[10] = 100;

Stores the value of 100 into the 11th slot of the array (array indexes are zero based).  The '*' tells the compiler that 'p' is a pointer that contains the address we want to use, otherwise the compiler would use the address of 'p' itself.  That statement could also be expressed as:

*(int)(p + (4 * 10)) = 100;

Following along that is telling the compiler to add 4*10 to that address stored int 'p' and dereference it as an integer, finally storing 100 in that location.  10 is the slot in the array, 4 is the size of an integer.  Which is exactly what the compiler does when it sees *p[10]

After we are done with allocated memory we need to let the system know that it can safely let other processes use that memory.

delete p;

A confusing statement to new users.  You're not actually 'deleting' anything in the strictest sense of the word, you're not deleting the variable 'p', you're telling the compiler to give back the memory whose address is stored in 'p'.   The memory is still there of course, it is just marked as no longer being used by your program.

Code you can play with:

Code Select Expand


global sub main()
{
int *p;
p = new(int, 1000);
for( int x=0;x<1000;x++)
{
*p[x] = x;
//The above is equivelent to:
//*(int)(p + 4 * x) = x;
}
for(x = 0;x< 1000;x++)
{
writeln(using("####, ",*p[x]));
}
delete p;
while getkey() = "";
}


Allocated memory is not limited to simple arrays.  A structure, or UDT as it is called in other languages, is a convenient packaged for holding related data.  Lets say you're building a 3D application and want a point datatype that can hold x,y and z coordinates of a 3D drawining.  Commonly referred to as a vertex

Code Select Expand


struct vertex
{
float x;
float y;
float z;
}


And your drawing has 500 points.

vertex *pShip;
pShip = new(vertex,500);

Then you have a loading subroutine that loads the data from a disk file;

Code Select Expand


for(int x = 0; x < 500; x++)
{
   *pShip[x].x = StrToNum(readln(file1));
   *pShip[x].y = StrToNum(readln(file1));
   *pShip[x].z = StrToNum(readln(file1));
}


Using pointers and allocated memory allows you to have any size data.

[John S]

Great post Paul!

Hey Donh,
I've been focussing on reference docs not a tutorial.  I'll try to get back to the tutorial next week.  The posts Paul just made here will probably wind up in the tutorial.  Of course, you could volunteer to help 

[donh]

John,

Do not take what I said as any critisium it was not ment that way.ÂÃ,  ÂÃ, You are doing a great job on the docs trying to get them done.ÂÃ,  I just thought it might be good to use this as a reference section in the docs not as a tutorial.

I am by no means a writer of any kind or OOP expert.ÂÃ,  I am stll trying to get my head around all of this OOP stuff and pointers.ÂÃ,  If I were to write some kind of tutorial I think it would end up leaveing people more confused and probaly laughing on the floorÂÃ,  .

I have been reading several books about OOP and C++ but they are not all that clear.ÂÃ,  But with what Paul explained it helps make things clearer.
Again thanks for your hard work it is extreamly apriceated.

Don

[John S]

No offense taken, I was just teasing and hoping to get volunteers.    That Barnes & Noble on C++ book I mentioned was pretty good (short read, digestible).   I have a decent grasp of what OOP is about, but understanding concepts and actual programming are two different things.

{ HINT to anyone who has some spare time }
I could use some help with the Aurora Help reference I've been working on.  We need to get as much of this done as soon possible.  Anyone wishing to pick up a library and doc'ing it are welcome (e.g. fileio, console, ...).   If we got a few volunteers, the reference portion could be done in a couple of weeks.   Take the sources I've made available and use as a template.  Also, I have not had time to create a main style sheet (Aurora_Help.CSS) yet that would globally control fonts, margins, etc.  You can email me the new source you create (with instructions/description) and I will get plugged in.   Once the reference is done, we can take some of Paul's musings, etc. and format them and stick them in the reference as added instructional material. 

( I'm trying not to copy the old IBPro docs to avoid controversy, there has been some cut and pasting here and there )


The tutorial I started, is going to help newbies to Aurora, OOP and even programming.  I was targetting my kids who have no programming experience.  It would be a fast and easy read for an experience programmer who is new to Aurora.  I haven't had time to do much with it though between family, work and school.

[LarryMc]

John S. said

I'm trying not to copy the old IBPro docs to avoid controversy, there has been some cut and pasting here and there )

The IBPro docs were pretty similar(in a way) to Fletchie's 'HELPVIEWER' format.

I would like to see a structure (similar to java api)
Category: GUI,FILEIO,etc
   Class:
      Base Class:
      Sub Classes:
      Methods:
         Inherited:
         Non-Overideable:
         Overrideable:
      Constants:
   Functions
   Constants
End Category

each method would have it's own page like in IBPro docs/Fletchie's viewer
   
I was thinking about writing a program to read all the .inc files and extract the info into a database and then display it with a treeview arrangement.
In a database there would be places to capture discussions/exampless.
The program could then generate the web pages for the help system to use.

I'm willing to help but I'm awful slow!!!!!!

[LarryMc]

Question about base classes and subclasses.

CWindow is a base class.

It has an assortment of virtual and non virtual methods and memory variables

CControl is the base class for all controls and is a subclass of CWindow

In addition to CControl's own virtual and non virtual methods does CControl also inherit any/all/some of CWindows methods and variables.

Further,CEdit is a subclass of CControl. what methods/variables does it inherit from (any/all/some) CWindow?

What would it look like in a few lines of code?

[Parker]

Almost. CControl is a derived class of CWindow. Subclassing is what you do when you want to handle a control's messages yourself.

A derived class inherits everything from its parent or base class. All methods and all variables. Virtual methods work with overrides because they are called through an array of function pointers. So even when the CWindow class calls its WndProc method, if you have overridden it, that entry in the function address table (called a vtable) is changed to point to mywindow's WndProc and that one is called.

[LarryMc]

Derived instead of subclasses.  I know subclassed from IBPro.

Seems like some of the methods in Cwindows don't apply to CEdit or CButton!

[Ionic Wind Support Team]

All of the functions (methods) and variables are inherited.  Certain methods will only apply to a window and not a control of course.  But all virtual functions will work when overridden.

Deriving a class is the same as nesting a UDT.  Think of it this way:

Code Select Expand


struct employee
{
int emp_id;
string firstname;
string lastname;
float hourly_rate;
}

struct manager
{
employee emp;
float salaray;
}


//A manager is an employee and all of the members of the employee structure
//can be accesses from a manager variable.

manager m;
m.emp.firstname = "John";
m.emp.lastname = "Doe";


Classes do this better by not having to reference a nested variable name to access a base classes variables.  It is automatic.

Code Select Expand


class employee
{
int emp_id;
string firstname;
string lastname;
float hourly_rate;
}

class manager : employee
{
float salary;
}

manager m;
m.firstname = "john";
m.lastname = "doe";


The compiler knows that manager is a derived from the employee class.   Internally the first example and the second look identical in memory except for the hidden vtable member.  Other than that you can actually use a class inplace of a struct.

Methods (functions belonging to the class) are inherited in the same manner. 

Code Select Expand


class employee
{
declare PrintPayStatement();
int emp_id;
string firstname;
string lastname;
float hourly_rate;
}

class manager : employee
{
float salary;
}

manager m;
m.firstname = "john";
m.lastname = "doe";
m.PrintPayStatement();


PrintPayStatement is a method declared in the base employee class. Since manager is derived from employee the compiler knows how to call a base class method.

Polymorphism, the ability of OOP to reference a derived class when it only has a pointer to the base class, is one of the fundemental principles of object oriented design.  It is something you should read up on when you get the time.

This article: http://www.cplusplus.com/doc/tutorial/polymorphism.html

Gives a general overview but it may be a bit over the head of a beginning OOP programmer.

Lets see....Every varaible has an address, a variable of a structure has an address, a variable of a class has an address.  The address of the first member of a structure is the same as the address of the structure itself.  An important concept to visualize.

Since a derived class, which is sometimes referred to as a 'subclass' not to be confused with subclassing, has the members of it's base class first then even if you only have a pointer typed to the base class the compiler still knows how to call the derived classes overridden methods.  Still hard to visual with that sentance though. 

I'll think of an easier way to describe it and come back to this discussion...

[Parker]

That would be a windows problem (as in windows the OS) where it doesn't respond to the messages correctly for controls - maybe they do some different message handling.

They still exist, they just might not work as expected. But what are you having problems with in particular? If you tell us I think we can point you in the right direction.

[LarryMc]

Paul,
I think that explains it pretty d.. good!!
Even I am starting to get the hang of it.  I have known basic that variables are stowed in memory locations.  I'm just not use to having to take care of it myself(thought wise).

Even on the distributed control systems with multiple processers connected to the same backplane and a common memory area actual address was taken care of for me.  One computer communicated between the memory and the real world input/output cards; one between memory and the data highway to other control nodes; one that processed sequential logic reading/ writing to the memory map; one processed analog control reading/ writing to the memory and one that sort of acted as the bus master traffic cop.

Just a concept I haven't become totally confortable with yet; but it WILL come!

Thanks

[kryton9]

In reading more about OOP, I really like the idea of encapsulation, but it seems to me to really benefit from it, we need to have properties in Aurora with get and set methods?
And a way to send messages when things happen in our own classes to notify when something is set.

Am I missing something in this thinking?

[Ionic Wind Support Team]

Yes you are missing something, and please let me know what you've been reading.

You don't need get/set methods for encapsulation.  The member variables and methods provide the mechanism of encapsulation of data and it's associated functions.  You can write accessor methods for only the variables you want external access to.

And a way to send messages when things happen in our own classes to notify when something is set.

And what purpose would that serve in an Array class?  Or how about a Vector 3 class?  GUI classes provide the notifcation of messages through all of the OnXXX handlers, but not every class would need the overhead of a message processing queue. 

There are no properites in pure OOP languages, but it is common when dealing with COM/ActiveX objects, which are a distant cousin of the C++ class object.  About the only thing they share in common is the layout of the virtual function table.

When dealing with COM and ActiveX then you need properties since you can't have the address of a function/method directly.  And they share a common marshalling mechanism so it makes it simpler in regards to a GUI element to keep the interfaces functionally similar. 

Paul.

[kryton9]

My readings to confusion, here are some to start

This talks about setting and getting and properties.
http://www.c-sharpcorner.com/Language/EncapsulationInCSGAG.asp

Code Select Expand

The first method is using a pair of conventional accessor and mutator methods. Another one method is using a named property. Whatever be the method our aim is to use the data with out any damage or change.


This one talks about sending messages:
http://en.wikipedia.org/wiki/Object-oriented_programming

Each object is capable of receiving messages, processing data, and sending messages to other objects. Each object can be viewed as an independent little machine or actor with a distinct role or responsibility.

http://azagappan.wordpress.com/2006/05/29/what-are-accessorsproperties-whats-the-power-of-encapsulation/

Code Select Expand

In a well designed object orientedÂÃ,  model, an object publicizes what it can do, ie what servicesÂÃ,  it can provide.ÂÃ,  It will hideÂÃ,  the internal details like how its implemented,ÂÃ,  how it performs the service etc.

I am trying to think new, but catch my self making classes and falling back to procedural type thought. So I keep reading to understand, I think I do then i try something and can't make things work like classes talking to each other, or really making the object totally self contained, so trying to figure out how to make reuseable code, not doing to well in it.

I can uses classes and projects to break the work up, but it is not really reuseable as I read on the net that I can make it.

I like the idea of what the third quote states, I have always thought the programs and hardware should be like that. That on OS could adapt on the fly to new hardware by a mechanism of talking to each other. The new hardware tells the OS what it can do, what it offers and tells the OS how to work with it. I think that should be the way objects should be and OOP's goal in its objects and our programs really being resuseable building blocks.

Also if you watch that video that Kale linked to by the man who coined the term object oriented programming, it is very interesting and really puts a new light on OOP as it is, and where it could be. The title of the thread is very good, what Kale wrote: Will Aurora 'start' the computer revolution? http://www.ionicwind.com/forums/index.php?topic=927.0

[Parker]

There are no properites in pure OOP languages

What is the definition of "pure OOP" then? Properties are the same as using get/set methods with private variables, but much cleaner in my opinion. I was under the impression that .NET was more heavily OOP than C++ because C++ allows methods and variables outside of a class.