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.
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.
Quote from: Ionic Wizard on February 18, 2006, 09:52:30 AM
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.
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.
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.
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.
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
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.
def image1 as myimage;
image1.width = 0;
The fun part comes with the member functions. Lets look at one of them:
image1.LoadImage("happy.bmp");
The compiler translates this into a function call that kind of looks like this:
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.
myimage::LoadImage(name as string)
{
}
Gets converted to (in psuedo terms)
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
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:
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?
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.
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 ;)
Thank you all so much.
That was very fast - much appreciated.
I am going to place my order right now!
We thank you for your support ;)
Ask questions, play with the examples, break things and we'll show you the way to fix them.
Paul said:
Quote
//these are equivelents.
*(mytype)p.member = 1;
*p.member = 1;
p->member = 1;
UREKA!!!!!!!!!!!!!!!
A light bulb glows. ;D
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.
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! ;D"
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 ;) ;) ;) ;)
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:
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
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;
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.
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 ;)
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ÂÃ, ;D.
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
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.
John S. said
Quote:( 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!!!!!!
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?
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.
Derived instead of subclasses. I know subclassed from IBPro.
Seems like some of the methods in Cwindows don't apply to CEdit or CButton! ???
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:
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.
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.
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...
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.
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 ;D
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?
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.
Quote
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.
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
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
QuoteEach 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/
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
QuoteThere 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.
.NET isn't a language. It is a collection of runtimes. And is used by many languages. C# being the latest bastardization of the C language. C# for instance doesn't support multiple inheritance, C++ does. Which one do you think as more of a pure OOP language then?
I'll refer this to the wikipedia defintion of OOP
http://en.wikipedia.org/wiki/Object-oriented_programming
Quote
Class â€ââ,¬Â a class defines the abstract characteristics of a thing, including the thing's characteristics (its attributes or properties) and the things it can do (its behaviors or methods) or features).
In this sentance a 'property' is generalized. Using the word 'characteristic'. Truth is there isn't a single accepted definition of how an objects attributes should be defined or used. Just because I prefer a less bloated approach to Aurora doesn't mean it is not a pure OOP language, if used in that manner.
Then again ANY langauge that allows procedural programming could be said to be not a pure OOP language, which would eliminate everything except scripting and interpreter type languages. Since all compiled languages need at least one non-oop based subroutine for the system to call upon execution. Our 'main' subroutine.
Quote
Encapsulation â€ââ,¬Â conceals the exact details of how a particular class works from objects that use its code or send messages to it. So, for example, the Dogs class has a bark() method. The code for the bark() method defines exactly how a bark happens (e.g., by inhaling() and then exhaling(), at a particular pitch and volume). Timmy, Lassie's friend, however, does not need to know exactly how she barks. Encapsulation is achieved by specifying which classes may use the members of an object. The result is that each object exposes to any class a certain interface â€ââ,¬Â those members accessible to that class. For example, an interface can ensure that puppies can only be added to an object of the class Dog by code in that class. Members are often specified as public, protected and private, determining whether they are available to all classes, sub-classes or only the defining class. Some languages go further: Java uses the protected keyword to restrict access also to classes in the same package, C# and VB.NET reserve some members to classes in the same assembly using keywords internal (C#) or Friend (VB.NET), and Eiffel allows one to specify which classes may access any member.
We do have the public, private and protected keywords now. However again encapsulation just specifies that the exact details of how a particular class method does it's job is not important. Each OOP langauge is slightly different in this respect.
My vision for Aurora was not to redefine current definitions of OOP, or to emulate any one particular language. It is to create a language I can work in fluently without having to continually sidestep the implementation of the core syntax. C++ requires a lot of sidestepping even if you try and create a pure object based implementation of an application.
Your vision of an OOP language probably is different than mine, and that is fine. Have you ever tried Oberon?
Paul.
Quote.NET isn't a language. It is a collection of runtimes. And is used by many languages.
Sorry, I meant the CIL language (which does support multiple inheritance, I have no idea why they leave that out of C#). Object oriented assembly language ::)
QuoteThen again ANY langauge that allows procedural programming could be said to be not a pure OOP language, which would eliminate everything except scripting and interpreter type languages. Since all compiled languages need at least one non-oop based subroutine for the system to call upon execution. Our 'main' subroutine.
I've heard this before, I think from someone who likes Java. I've also heard that C++ doesn't really support arrays, but then what is
int i[10];? A vulture? ::)
I just meant that just because it's not in C++ why should that mean it's not a part of a pure OOP language? Yes I think it's cleaner, but I'm not going to ask for properties to be incorporated in Aurora if you think it would increase bloat. I was just wondering.
QuoteMy vision for Aurora was not to redefine current definitions of OOP, or to emulate any one particular language. It is to create a language I can work in fluently without having to continually sidestep the implementation of the core syntax. C++ requires a lot of sidestepping even if you try and create a pure object based implementation of an application.
C++ is much more feature rich than Aurora or really any other language I know of (though some others do provide different features), and I can see replacing it or giving it a different syntax is a huge task, and besides there's really no point to do that especially with a language with a similar syntax like Aurora. I think Aurora is easier to learn and use, and is very suitable for many tasks, but that C++ has a slight edge with professionals, which is caused by things like templates and operators that can be very confusing.
QuoteYour vision of an OOP language probably is different than mine, and that is fine. Have you ever tried Oberon?
Certainly, I like Aurora but I also have my own ideas. Not that I can implement them though, with not having much time ;)
Oberon shares a certain resemblance to Pascal, not surprising since they're both by the same guy. But that's not exactly my favorite language.
Quote
I've heard this before, I think from someone who likes Java. I've also heard that C++ doesn't really support arrays, but then what is int i[10];? A vulture? Roll Eyes
Technically that is C syntax ;).
Quote
Yes I think it's cleaner, but I'm not going to ask for properties to be incorporated in Aurora if you think it would increase bloat. I was just wondering.
One feature does not bloat make. However they do add up over time and before you know it you're dealing with 6MB runtimes, impossibly large environments, and the code produced by users becomes sloppy and larger than it needs to be. trimming the fat starts with a 'just say no' policy.
There is a mythology in programming that because drive space, memory, processor speed, double every 18 months that there is no need to worry about the efficiency and size of code. That kind of thinking has brought us to where we are today. With multi gigabyte operating systems requiring multi GHz PC's just to be able to run notepad.NET ::)
I am one of the ever decreasing holdouts that still beleive quality of code is more important that the quantity of it. It is why after a year we are still in the pre-release stages of Aurora. And why I continually look for ways to improve the speed and size of all of the tools used by Aurora. It is that kind of thinking that led me to create IBasic, and IBasic Pro. Bigger is not always better and sometimes you have to cut corners to improve efficiency. The tagline "Create executables with no runtimes needed" served me well for many years.
You, Parker, represent the new generation of programmers. It is my sincerest hope that you learn from us old guys and not sacrifice quality for the sake of convenience. Don't think that size and speed don't matter because they do, and you can do your part to stop the hemmoraging of bloated code.
10 years ago I could do more with my PC then I can now given the same representative percentage of code size over processor speed. I could have more apps open at once, was more productive, and despite the fact that win 9x forced daily, sometimes hourly reboots, it was an order of magnitude smaller than the upcoming Vista. What does the increase in code size and processor speed really give you? besides nice looking alpha transparent windows, which do nothing at all really.
Quote
C++ has a slight edge with professionals, which is caused by things like templates and operators that can be very confusing.
C++ was a right place, right time language. C programmers flocked to it and the resultant code base to draw on is staggaring. The real edge it has with professionals, like myself, is time. It has been around long enough that there is more reference material available for C++ then any other product in existance. I still have my orignal VC++, on a dozen or so floppy disks ;)
Paul.
Paul, I don't know if you saw my other post earlier before Parker's about the material I read (reply#23)... but anyways here is what my thinking is at the moment:
1. You have an incredible ability to take the current complicated mess out there in the programming world and make it easier. No doubt about that.
2. You wanted to move passed iBasicPro and bring in OOP aspects that you love. Great, we the iBasic sheep are struggling to follow.
Here is where we diverge. I think since you are so versed in C and C++ you are clinging to it like those of us who are stuck with procedural are clinging to our ways.
With all the reading and testing about OOP in various languages I have been doing the last couple of months, there is a golden and rare opportunity for someone with your skills to develop the next revolution, not just be an inbetween step, but a leap.
From what I have read about OOP, I love it. It makes sense, is the future. By turning your back on certain things you see as bloat, you and the rest of us who could benefit from your skills are missing a golden opportunity. Auto Memory Management just a great idea. Realtime interactive development, a great idea. It is the future, it is just when will it be here.
I really think you should re-evaluate Aurora. Make it fully Object Oriented Programming. Instead of going on and on about what that entails, I would say don't be the next c or c++ but be the next smalltalk, but even better. Compiled, cleaner syntax and full support as you are doing for Aurora, console, windows, 2d, 3d, web.
Your talents are immense and now that you got me to taste OOP, I want to push you as I think Parker is trying to do to embrace what you ask us too, but do it the Turley way.
I'm just an annoying hindrance, don't take after me ::)
Well, everyone is annoying at some times, but I don't want to be a major influence anymore - I just wanted to get some of the main compiler features that didn't exist in IBasic in, but I'm not going to go petitioning for operator overloading, multiple inheritance, etc because then why don't I just use C++?
I know some people are devoted to certain languages (many [not all, but many] of the people still with IBasic are this way), but I don't like to be that way - I like to use what I think is easiest and best fit for the job at hand. I've tried many different languages, and there are a select few that I like to use. After learning Java and .NET (or C# rather), I've found that I really don't like it when a language hides things from you, which is mainly pointers in these languages.
I have two current projects, not very active since I don't have a lot of time. One is an IDE for Aurora (written in Aurora), the other is a scripting language (written in C++).
Since I'm young and a very fast learner, I don't know what it's like to struggle with OOP concepts and C++, so while I may think that feature X is better and cleaner, to someone else it might just confuse things more. I think if the aim of Aurora is to have an OOP language that is powerful but easy to learn, it should be led more by the users that need help but are willing to learn.
Kryton,
What is happening is your getting caught up in terminology when what you're asking for is already there.
Quote
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.
They are not talking about messages in the Windows API sense. A method call is sending the object a 'message' in that respect whether it is done through a virtual function table or COM interface.
In the windows sense a message is something different, it is a UINT value that is stored in a queue (FIFO) that is read by a function. 'Sending a message' was always a misnomer in GUI docs as far as I am concerned. You're really storing a message, to be later read by the GetMessage (or PeekMessage) function from that FIFO queue. Nothing is transmitted in the radio sense ;) Internally all Windows apps have a loop that calls GetMessage directly and a SELECT statement that calls a function based on the value of that stored message. Even in Aurora there is a loop, invoked by the WAIT statement that calls GetMessage and then calls DispatchMessage (eventually). DispatchMessage calls WndProc which has a SELECT statement that calls the OnXXX handler in the CWindow based object that the Windows window is associated with.
Quote
Here is where we diverge. I think since you are so versed in C and C++ you are clinging to it like those of us who are stuck with procedural are clinging to our ways.
Not true. My first language that I learned was assembly. Then C, then BASIC, followed by C++. I have also used, to varying degrees, COBOL, FORTRAN, Pascal, PL/I, Rexx, ARexx, PHP, VB and of course dozens of so called 'scripting languages' which is just another fancy term for 'slow interpreter'.
Aurora contains the best of what I have found in those languages while refusing to submit to generalized ideas. It may seem a lot like C++ on the surface, only because that type of syntax is commong in many languages.
When I refer to bloat think about what an internalized 'property' method has to do.
#1 it has to deal with strings. And account for both ANSI and Unicode. Let's say you have a variable, named m_bkcolor that represents the background color of an object. Since we need to deal with Unicode we will need two identical methods, using overloading.
#2 And then you're forced to use a common base class to all classes since implementing properties on individual classes would be more bloat.
CObject::Set(string name, int value)
{
...
}
COBject::Get(string name), int
{
...
}
CObject::Set(wstring name, int value)
{
...
}
COBject::Get(wstring name), int
{
...
}
Now we have to have the data structure to support properties. Lets use hash tables because they are the most efficient, but lists could also be used.
class CObject
{
CIntAssoc m_listProperties;
}
So then we need a way to define properties. Requring us to add another method the the common base class.
CObject::DefineProperty(string name)
{
...
}
And then a method to return an error when a property doesn't exist. And the list goes on and on. When all you really need to do , as an Aurora programmer, is just define two methods and a private variable in your class. We'll go one step further and say we have a 'validity' check on the object as well. Otherwise the private variable is rather pointless.
class MyObject
{
private:
uint m_bkcolor;
int m_bValid;
public:
declare GetBKColor(),uint
{
return m_bkColor;
}
declare SetBKColor(uint clr),uint
{
UINT temp = m_bkColor;
if(m_bValid)
m_bkColor = clr;
return temp;
}
}
Small, efficient, and follows my methodology of reducing code overhead. Why require the derivation of a common base class when it is not always needed? Why add the overhead of literal strings when just a simple method call will do.
If I were to need hundreds of properties that I wanted to access with string names then the CIntAssoc would do nicely.
class MyClass {
CIntAssoc m_prop;
}
... In some method
m_prop.Add("Left", l);
m_prop.Add("Right", r);
m_prop.Add("Width", w);
m_prop.Add("Color", clr);
and then retrieving
l = m_prop.Lookup("Left");
r = m_prop.Lookup("Right");
...
That is what I am talking about Kryton. Using what is already there and available instead of trying to add more overhead to the language just because it may or may not be more convenient.
The Associative Array classes CIntAssoc, CStringAssoc, CPointerAssoc all use hash tables making lookups almost instant.
Paul.
I should note that 'private', 'public' and 'protected' are valid keywords in Beta 1, Rev 1. Sorry about posting code you can't yet run ;)
The associative array classes have been available for a while now though.
I think 'young' is the operative word. I know I do not learn as fast or as well as I did 40 years ago.
I am still stuck in C structure and syntax - I can do that but other stuff comes very slow.
Paul, I see what you are saying. You definitly know more about this stuff than anyone else I know and I appreciate your efforts. I guess I just need to wait for Aurora to be finished, it just seems as it is so functional already, that it is complete and I guess I am getting way ahead of myself and any analysis and comparisons can't truly be made.
Did you get a a chance to watch the Alice video I posted about here? http://www.ionicwind.com/forums/index.php?topic=940.0
When Aurora is complete as you envision it, will we be able to write a program that could allow things programmed as shown in the first video, the one with voice?