Linking two objectmodules OR Using 'Project' in VC++6.0 compiler?

[JoBe]

Hello ladies and gents,

Ive been reading about when you have a very large program, that it is advisable to divide this into several modules. Ive tried this out with an example of two separate modules that where given as examples and managed to get two .cpp modules into the Source files of the workspace of one of those.

Examples:

#include <iostream>

using namespace std;

extern int n;
void f(int i), g();

int main()
{
	cout<<"Previous n = "<< n <<" (module 1)\n";

	f(8);
	g();

	cout<<"Press any key to continue!\n";

	return 0;
}

#include <iostream>

using namespace std;

int n = 100;
static int m = 7;

void f(int i)
{
	n += i + m;
}

void g()
{
	cout<<"After raising it with 8 + 7 (in module 2):\n";
	cout<<"n = "<< n <<endl;
}

I'm using VC++6.0 as compiler on XP Pro if you need to know.

I did it following this path: Project --> Add Project --> Files --> Added the necessary . cpp file!

Now, the question is, is this what is called linking?

The reason I ask is because in the book, after they talk about the 'linker', they talk about the following:

It's also possible in this compiler (the author also used VC++6.00 compiler) to make use of a 'Project' in wich the two named files would be incorporated (C1 module1.cpp module2.cpp). These executable files wich are created by executing this command 'Project' would have the name module1.exe. If we start the program by entering this name (don't have a clue where this would be entered ?? ) then the output would be the following:

Previous: n = 100 (module 1)
After raising it with 8 + 7 (in module 2):
n = 115

What is the difference between using the 'linker' and this so called 'Project' :?:

[Dave Sinkula]

A "compiler" is generally a couple of different tools sandwiched together. There may be a preprocessor, the compiler proper, a linker and maybe some others. The preprocessor, for example, may process #defines and #includes and strip out comments. Then this raw code is fed to the compiler proper which processes it (generally) into an object file. The object files within the project are then linked together into an executable. IDEs generally hide the fact that a makefile is used to handle the building of the project's target(s).

So even if you only have one source file, it is likely compiled into an obj and then linked into an exe. With multiple source files each is compiled into an obj and then all are linked into an exe. (I'm being rather platform specific here for the sake of simplicity in this example.)

One advantage of these separate steps is that if you have say 50 modules and go to change only one, then only one obj needs to be recompiled and then all 50 get linked. But you don't need to recompile the other 49.

Also, object files may be packaged into a library instead of an executable. Then the linker can pick from the library any routines used in source modules.

[JoBe]

Thanks for the explanation Dave :!:

>The object files within the project are then linked together into an executable.

So, explained in my own words, the 'project' is actually just all the object files(.cpp) wich are then linked together into the execute file (.exe) :?:

Still am clueless in why they explained that 'project' bit then :confused:

>IDEs generally hide the fact that a makefile is used to handle the building of the project's target(s).

Euh, what are IDE's :?:

> Also, object files may be packaged into a library instead of an executable. Then the linker can pick from the library any routines used in source modules.

Is this what also happens when a class becomes to big or there are to many classes, it get's divided like this:
Interface

class vkv
{
     ....
};

Implementation

# include "vkv.h"  // h equals headerfile
# include ...

Application

# include <iostream>
# include "vkv.h"

using namespace std;

int main()
{
       ...
}

[Dave Sinkula]

>The object files within the project are then linked together into an executable.

So, explained in my own words, the 'project' is actually just all the object files(.cpp) wich are then linked together into the execute file (.exe) :?:

I might say source files (.cpp), which are compiled into object files (.obj) and then linked together into the execute file (.exe) .

Still am clueless in why they explained that 'project' bit then :confused:

I don't quite understand either.

>IDEs generally hide the fact that a makefile is used to handle the building of the project's target(s).

Euh, what are IDE's :?:

Integrated development environments: the neat little graphical stuff that keeps you from the land of makefile hell.

> Also, object files may be packaged into a library instead of an executable. Then the linker can pick from the library any routines used in source modules.

Is this what also happens when a class becomes to big or there are to many classes, it get's divided like this:

I'd say think of the standard library. There may be thousands of functions in there, but if you're only using two, only those two need be put in your executable.

[JoBe]

>I might say source files (.cpp), which are compiled into object files (.obj) and then linked together into the execute file (.exe) .

Yep, got it :!:

> I don't quite understand either.

Well, then it'll stay a mistery for the time being ;)

> ...: the neat little graphical stuff that keeps you from the land of makefile hell.

Thanks for the link :!: Thing is, I previously added that link of Wikipedia (wich you gave then aswell) to my favorites, don't know why I didn't use it to look it up myself :rolleyes:

>I'd say think of the standard library. There may be thousands of functions in there, but if you're only using two, only those two need be put in your executable.

So, if I understand you correctly, I could detract those functions from the standard library wich are used in my program, am I correct that these then should be written as #include "..... .h" :?:

[Dave Sinkula]

So, if I understand you correctly, I could detract those functions from the standard library wich are used in my program, am I correct that these then should be written as #include "..... .h" :?:

If I understand you correctly, no. The functions in the standard library are just that - in a library, not in a header.[*] You include the standard headers to make sure that your use of them is correct.

[*]Except of course the STL stuff. Or any other template stuff.

[JoBe]

Ok, I think I get the picture, thanks Dave ;)