inc and src, projects
what do i have to do, in a project, so that once the files are added to the project, they recognize each other?
I can get the code to only work if its all part of one source, I have tried old school #includes, #include, #import, etc.
I have 1 source file that I want it to be nothing but source for my plug, I want another source to be able to use it, but neither source in the same project knows about each other, what am I missing?
#include is a directive, but please please please don't start including source files. It's horrible practice.
Once you make a project, you should add all the files to the project. Then if you have a subroutine you want recognized by another module, you have to do two things:
-Make it a GLOBAL SUB in the first module, just like you do with main.
global sub something( ),int
{
return 4;
}
-Put a declare in the other modules (this is where you use headers and #include)
extern int something( );
// That only works for intrinsics (not even typedefs, because of yacc)
declare extern something( ),int;
// That works always.
Ok, so if I am understanding this right, I should only have 1 src file, the rest should be inc files, in those inc files, I make subs global.
What about my declare imports?
Here is what I am trying to do, its probably something simple I am overlooking. My Aurora3Impact needs to become a global class object, every #define, every struct, property, method, everything in that file, needs to become available to the other files in the project.
What I can't seem to grasp mentally yet, is how to have 1 src with my global sub main(), then another file that is a global class. I will have well over 2000 lines of code in the global class, that contains everything I need for the engine. I don't want that to muck up my file that has the global sub main() and all its methods / properties, or anything else.
Hopefully I am making sense, and its easy to do. There is just no examples on projects yet, only single applications that have a single src file with all the code in that 1 file.
edit: hmm the more I think about it, the less that makes sense, I want to reduce code on pages vs add more. what you stated means that I have my definitions in one file, and empty constructors in another, I just want to put the constructors in one file, and call them in the other.
ConstructorFile.inc contains:
#use, #define, struct, member variables, etc.
Source.src contains:
global sub main()
{
something();
}
You kind of have it figured out. Include files should only have defintions, constants, structures, type defines, etc. Just like a C header file.
A project consists of one or more source files (.src) all of which can include .inc files as needed. Add each file to the project.
The linker needs to know what functions you want marked for global linkage, so other source(object) files can see it. That is done with the 'global' keyword. In C all functions are global by default. In Aurora all functions are local by default, except object methods which are always global.
//file1.src
global sub MySub(int a),int
{
return a+2;
}
//file2.src
declare extern MySub(int a),int;
global sub main()
{
print MySub(2);
}
When you compile the project there will be an object file created for every source file. The linker takes those object files and resolves references to external functions, inserting the correct address as needed. A function that is not marked as 'global' doesn't get an entry in the object files global function table and is only callable in the file which it is defined.
You shoudl structure your include files to eliminate duplicate references to the same file. This is a common practice in other languages as well.
//myinclude.inc
#ifndef MYINCLUDE_INCLUDED
#define MYINCLUDE_INCLUDED
...constants and such here
#endif
Which prevents the compiler from defining the same constants twice if you happen to have nested includes. Such as the windows header files.
If you have the source archive you have the best example of projects I can give you. Unzip the archive, open say "console.awp" and the compiler will complain about the project being moved from it's original directory, answer "yes" to update the project.
Each project file contains one or more global functions. The libraries include file is actually located in your installations 'bin' directory and is included on every compile. This is how Aurora is able to use the built in libraries without having to force you to use #include "console.inc" for example.
Don't place your own include files in the BIN directory or you'll run into problems since any .inc file there will be read for every program you compile. It is just for the official libraries.
Aurora doesn't need extern/global resolution if the include file contains a reference to and external function and you happen to include it in the defining source file, the one where the function was written. The compiler is smart enough to know what to do.
Anyway I hope that is enough information to hold you over ;) Since you've never used my previous language I can understand the stumbling blocks your facing.
Paul.
Thanks Ionic, I'll chew on this some tonight, I did purchase the source from you, just didn't know where to place it, other than its own folder. I'll take a look at the project you suggested and see if I can hammer on it over saturday to understand it. Once you get the basics down, this compiler is pretty straight forward, just needs a little more automation for the project, IE, you create a new project, then you create a new src or inc, it should automatically be added to the project. Just IMO.
Thanks for all the pointers, I'll get over these hoops at some point. Atleast I have my base engine wrapper written, and works.
edit: YAY!! I got it working the way I want it to work, thank goodness for that. I'll post results in shared code later. I have tons more to write first.
I'll share the project to integrate in 3Impact as a 3d game engine with Aurora after I get it done with a few tech demos. Right now, I just have the engine initialization complete, and finally got the project to compile and run with the majority of the code in my INC file. All I have in my src file is the engine constructs.
Ok, just wasted about 4 hours trying to get something to work and am not getting it.
I understand include files should only have defintions, constants, structures, type defines, etc
and #include is a directive, but please please please don't start including source files. It's horrible practice.
these are some things from Paul and Parker on this thread.
and include files should not be in a project?
So very confusing?
Where do I put my classes if I don't want them in the main source file, but somewhere else?
And then how can I use that in my source1 file without it being in the includes?
Let's use:
src1.src is the main program source file where global sub main() is
I want to use a class to instantiate a new object in this file.
I don't want class1 being defined in the src1.src
class1.xÂÃ, not sure where this will go, but it is where the class is declared and defined
inc1.inc this will have constants and structs used in the main source program
and functions (subs).
Class definitions go in include files. Class implimentations go in the source files.
Quote from: Paul Turley on May 12, 2006, 08:14:53 PMA project consists of one or more source files (.src) all of which can include .inc files as needed. Add each file to the project.
How do you add files to a project?
No problem, found it! ;D
I'm stil having problems trying to get custom coded classes to be recognised in my main source file. :( I've got it ordered like this:
Desktop.inc
#define SM_CXSCREEN 0
#define SM_CYSCREEN 1
declare import, GetSystemMetrics(int nIndex), int;
class CDesktop
{
int Width;
int Height;
VECTOR2 Resolution;
declare GetWidth(), int;
declare GetHeight(), int;
declare GetResolution(), VECTOR2;
}
CDesktop::GetWidth(), int
{
Width = GetSystemMetrics(SM_CXSCREEN);
return Width;
}
CDesktop::GetHeight(), int
{
Height = GetSystemMetrics(SM_CYSCREEN);
return Height;
}
CDesktop::GetResolution(), VECTOR2
{
GetWidth();
GetHeight();
Resolution.x = Width;
Resolution.y = Height;
return Resolution;
}
Main.src
global sub main()
{
CDesktop Desktop;
print("Desktop Width: " + str$(Desktop.GetWidth()));
print("Desktop Height: " + str$(Desktop.GetHeight()));
While (GetKey() = "")
{
}
}
What am i doing wrong? ???
In main.src there is no #include directive.
Quote from: peaslee on August 10, 2006, 02:23:59 PM
In main.src there is no #include directive.
You sure? from reading the posts above using the include statement is bad? ???
Pretty sureÂÃ, ;)
You have to say
#include "Desktop.inc"
to add the code at that point or there is no way for the system to obtain the class definitions and methods. This assumes the file Desktop.inc is in your include folder.
Quote from: peaslee on August 10, 2006, 02:35:27 PM
Pretty sure ;)
You have to say
#include "Desktop.inc"
to add the code at that point or there is no way for the system to obtain the class definitions and methods. This assumes the file Desktop.inc is in your include folder.
Using this command does work and everything compiles fine. The 'Desktop.inc' file is in the same dir as my 'main.src' file. Both files are added to the project. :)
Don't add include files to the project. Just #include them.
Quote from: Paul Turley on August 10, 2006, 04:57:49 PM
Don't add include files to the project.ÂÃ, Just #include them.
That's right, but they can be open in the IDE which will remember that when you next start Aurora. I often work on the include file and then try compiling the main routine again.
Just getting back to this only because I am actually starting to use it in Aurora.
Mainly your project will have tons of include files and very little src files?
All class info goes into include and you use #include directive to bring them into a src.
So why have more than 1 source? Example?
IS there a small project running around that uses 2 different source files in 1 project and also uses includes?
I want to make sure I am architecturing things correctly, I though src files were similar to modules in that what is in one source can be seen in another source, if it has a public object, only the #includes are local to each source, yes yes confused I get .. yes...
I am currently working on a game with 1 include and multiple src files. It was originally written in C and I am converting
it to Aurora. I suspect I am doing it wrong - but most of my thinking is wrong.
Quote from: Paul Turley on July 30, 2006, 05:55:51 PM
Class definitions go in include files. Class implimentations go in the source files.
Im sure there must be an explanation for this but i can't see why you would need two files to code a single class (with definitions)?
For example i'm working on a random number generator and so i created these file:
CRandom.inc //class definition
CRandom.src //class implimentation
Main.src //main loop (console) to test
Once i have done this, i have to make sure 'CRandom.inc' is #include'd into 'CRandom.src' then make sure 'CRandom.src' is included into 'Main.src'? This seems the long way round?
I've now decided to arrange it like this:
CRandom.inc //class definition and implimentation
Main.src //main loop (console) to test
and 'CRandom.inc' is #include'd into 'Main.src'.
Simpler? or am i missing the point?
Projects are meant for large programs. If your only making a demo or something less than 1000 lines, then sure keep it all in one file as it doesn't matter.
But think about reusable code for a moment. Let's say you have a matix algebra class, and you want to use that class all over the place. Having the definition in an include file means you only have to #include "matrix.inc" in any source file that your using that class in.
Or think about a static class library. guil.lib has hundreds of source files and one "gui.inc" include file. You can use CWindow from the Aurora GUI library because gui.inc is included automatically for you on every build.
And the final reason for using projects is resources. You can't add a resource to a single file mode program. They are only supported by projects.
Trust me, I know what I am talking about here ;)
Sounds great, just one problem, still confused about Aurora.
main.src <== has my global main
class1.inc <== class definitions
objects.src <== #includes class1.inc and has struct's in it
now in my main, do I simply do
main
{
myObj objType; //<<=== exists in class1, so since in objects as include, is available to main since src is available to all project object?
}
Am I making any sense?
Quote from: Paul Turley on August 11, 2006, 08:34:06 AM
Projects are meant for large programs. If your only making a demo or something less than 1000 lines, then sure keep it all in one file as it doesn't matter.
But think about reusable code for a moment. Let's say you have a matix algebra class, and you want to use that class all over the place. Having the definition in an include file means you only have to #include "matrix.inc" in any source file that your using that class in.
Or think about a static class library. guil.lib has hundreds of source files and one "gui.inc" include file. You can use CWindow from the Aurora GUI library because gui.inc is included automatically for you on every build.
And the final reason for using projects is resources. You can't add a resource to a single file mode program. They are only supported by projects.
Trust me, I know what I am talking about here ;)
I do trust you. ;) You seem very knowledgeable and someone from which i can learn a great deal, so i must apologise for the noob questions, but i need to totally understand because this is something that i've never really understood about C++. I want to get things right and move forward in my programming ability because i intend on writing some big programs (games). :D
So when you say you have the definition (of a reuseable class) in an include file, i assume that's all there is in there? Then you use another source file to actually implement the class and define the methods? So how does just including the include file in your source make the included file know where it's class definition is? ???
http://www.ionicwind.com/forums/index.php?topic=754.15
Sort of went over the basics of all of this stuff in examples. The items about source files and includes starts at reply #17 and on. Hope it helps.
Quote from: kryton9 on August 11, 2006, 10:18:11 AM
http://www.ionicwind.com/forums/index.php?topic=754.15
Sort of went over the basics of all of this stuff in examples. The items about source files and includes starts at reply #17 and on. Hope it helps.
Aha! nice link. I think i get it. I wasn't putting the class declaration into the src file, only the method definitions. I've got it all working now. :)
Great!
Quote from: Kale on August 11, 2006, 10:02:54 AM
I do trust you. ;) You seem very knowledgeable and someone from which i can learn a great deal, so i must apologise for the noob questions, but i need to totally understand because this is something that i've never really understood about C++. I want to get things right and move forward in my programming ability because i intend on writing some big programs (games). :D
So when you say you have the definition (of a reuseable class) in an include file, i assume that's all there is in there? Then you use another source file to actually implement the class and define the methods? So how does just including the include file in your source make the included file know where it's class definition is? ???
It doesn't need to know. That is the job of the linker.
When you compile a source file it gets assembled into an object file. An object file containes the machine code of your code, and references to functions/methods not contained in that object file.
Let's say that you have a class called "BigClass" and that class has a method called "Foobar". You create an include file that has the class definition.
//bigclass.inc
class BigClass
{
declare Foobar(),int;
}
And a source file that has the implimentation
//bigclass.src
BigClass::Foobar(),int
{
return 1;
}
And two source file that want to use the BigClass method Foobar
//somefile.src
#include "bigclass.inc"
SUB GetFoobar(),int
{
Bigclass c;
return c.Foobar();
}
//somefile2.src
#include "bigclass.inc"
SUB MultFoobar(),int
{
Bigclass.c;
return c.Foobar() * 2;
}
When you compile the project the first thing that happens is the source gets assembled into object files.
bigclass.o
somefile.o
somefile2.o
Then the linker gets called and looks through each object file for unresolved references to methods/functions. It finds two unresolved references to Bigclass::Foobar and finds the address to that method in 'bigclass.o'. Since the linker now knows where the function is it fills in the spots in the other object files before creating the final executable.
If you were to remove the "bigclass.src" file from the project the compiler would still create the two somefile object files but your compilation would fail with the linker reporting
"Unresolved External Bigclass@Foobar"
Meaning that after it looked through all of the libraries, object files, and imported DLL functions it could not find that method.
Hope that helps,
Paul.
KICK ARSE!!!!
I got my class to work and my distance to object to work, and my targeting to work, and ... HOLY CRAP THIS IS COOL
sorry, overwhelmed, I made 1 change to my little application and now I got tracking done
Great example Paul, but i notice that you didn't have the class declaration in the src file. If i do that i get errors telling me that theres an unknown class.
Here's my example that works:
Desktop.inc:
class CDesktop
{
int Width;
int Height;
VECTOR2 Resolution;
declare GetWidth(), int;
declare GetHeight(), int;
declare GetResolution(), VECTOR2;
}
Desktop.src:
#define SM_CXSCREEN 0
#define SM_CYSCREEN 1
declare import, GetSystemMetrics(int nIndex), int;
class CDesktop
{
int Width;
int Height;
VECTOR2 Resolution;
declare GetWidth(), int;
declare GetHeight(), int;
declare GetResolution(), VECTOR2;
}
CDesktop::GetWidth(), int
{
Width = GetSystemMetrics(SM_CXSCREEN);
return Width;
}
CDesktop::GetHeight(), int
{
Height = GetSystemMetrics(SM_CYSCREEN);
return Height;
}
CDesktop::GetResolution(), VECTOR2
{
GetWidth();
GetHeight();
Resolution.x = Width;
Resolution.y = Height;
return Resolution;
}
Main.src:
#include "Desktop.inc"
global sub main()
{
CDesktop Desktop;
print("Desktop Width: " + str$(Desktop.GetWidth()));
print("Desktop Height: " + str$(Desktop.GetHeight()));
While (GetKey() = "")
{
}
}
This all works fine, but notice that the code:
class CDesktop
{
int Width;
int Height;
VECTOR2 Resolution;
declare GetWidth(), int;
declare GetHeight(), int;
declare GetResolution(), VECTOR2;
}
Appears twice. Once in the include and once in the source file. If i take it out of the source file the compilation fails. Is this correct?
You got something screwy going on then, make sure the sources are in your project, this only works for projects.
My project ONLY has the source files in it, and the src files include the #include to the inc that holds the definitions.
I'll post it up even though I am really not ready with it yet, some features not in it that will be hopefully up over the weekend, give me a little bit to update the project on the web link for the mech thingy.
edit:
Ok take a look at the blast a mech game project, its very rough, alot on paper not in it at the moment but wanted to post what I had done for this discussion.
In the desktop.src implementation file just include "desktop.inc" and you won't need it twice then. ;)
Quote from: Paul Turley on August 11, 2006, 04:59:59 PM
In the desktop.src implementation file just include "desktop.inc" and you won't need it twice then. ;)
So '#include "desktop.inc"' goes at the top of 'Desktop.src' and 'Main.src'?
Yes, it goes at the top of every SRC that calls one of the functions in the SRC the INC refers to.