src inc and projects

[J B Wood (Zumwalt)]

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?

[Parker]

#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.

Code Select Expand

global sub something( ),int
{
    return 4;
}
-Put a declare in the other modules (this is where you use headers and #include)

Code Select Expand

extern int something( );
// That only works for intrinsics (not even typedefs, because of yacc)
declare extern something( ),int;
// That works always.

[J B Wood (Zumwalt)]

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();
}

[Ionic Wind Support Team]

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.

[J B Wood (Zumwalt)]

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.

[kryton9]

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).

[Ionic Wind Support Team]

Class definitions go in include files.  Class implimentations go in the source files.

[Kale]

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.

How do you add files to a project?

[Kale]

No problem, found it!

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

Code Select Expand


#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

Code Select Expand


global sub main()
{
CDesktop Desktop;

print("Desktop Width: " + str$(Desktop.GetWidth()));
print("Desktop Height: " + str$(Desktop.GetHeight()));
While (GetKey() = "")
{

}
}


What am i doing wrong?

[Bruce Peaslee]

In main.src there is no #include directive.

[Kale]

In main.src there is no #include directive.

You sure? from reading the posts above using the include statement is bad?

[Bruce Peaslee]

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.

[Kale]

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.

[Ionic Wind Support Team]

Don't add include files to the project.  Just #include them.

[Bruce Peaslee]

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.

[J B Wood (Zumwalt)]

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...

[Rock Ridge Farm (Larry)]

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.

[Kale]

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?

[Ionic Wind Support Team]

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

[J B Wood (Zumwalt)]

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?

[Kale]

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).

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?

[kryton9]

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.

[Kale]

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.

[kryton9]

Great!

[Ionic Wind Support Team]

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).

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.