Return Styles: Pseud0ch, Terminal, Valhalla, NES, Geocities, Blue Moon.

Pages: 1-

C/C++ question

Name: Anonymous 2010-04-19 12:47

So I'm just expanding into C++, previously I programmed only in Java. What I'm wondering about is how the separation of a program in source files and headers works in C. In Java every source file represents a class, but in C and C++ I understand that that is not necessarily the case.

I know (or, well, I think) header files are just a bunch of code that you #include as a sort of shorthand for copy-pasting it. But how do actual .c or .cpp source files work? How do the source files in a codebase all hook together?

Name: Anonymous 2010-04-19 12:58

For the headers, you're right.
For the cpp source files, the are compiled in .o files, which are linked together...

Name: Anonymous 2010-04-19 13:02

So if I declare a function in one source file, I can access it from any other? Also, is there any reason to split a program into several files other than just not wanting to have huge 10000 line files of source code?

Name: Anonymous 2010-04-19 13:14

No, you have to _declare_ the fuction in all the source files, but only _define_ it in one...

int f(int, char); --> declaration
int f(int i, char c){return i;} -->definition

and for example, anonymous/private namespaces can be useful...

Name: Anonymous 2010-04-19 13:15

(because the compiler have to know the prototype of the function to call it)

Name: Anonymous 2010-04-19 13:18

>>3
Yes.
Lets say you work on a game. You would want to separate the engines because you may want to use it in another project. You could ofcourse copy/paste the functions into every Project, but If you want to update a certain function you'll have to scan through all the source files and update that function.

So instead have a library of functions somewhere which you access from different projects and can update with minimal fuss.

Name: Anonymous 2010-04-19 13:25

>>6
WORK ON MY ANUS

Name: Anonymous 2010-04-19 17:08

>>1
1. Pre-process source files. The preprocessor is run. It interprets all the preprocessor directives, anything that starts with #. #ifdefs and so on, like including the text verbatim of any files #included. Yes, this is as retarded as it sounds.

2. Compile the preprocessed source files. Each .c or .cpp file is compiled to native code. Functions which are used but nowhere declared are assumed to be in error. Functions which are declared but not defined are assumed to be defined elsewhere, so the compiler just puts enough information in the compiled file for the linker to find the right definition.

3. Link the object files and libraries. The linker takes all the .o files given and stitches them together into an executable (or library). For calls to functions defined in other files or libraries, the linker replaces the placeholders with actual calls, now that it knows where those functions are defined.

Name: Anonymous 2010-11-14 0:51


Don't change these.
Name: Email:
Entire Thread Thread List