I have in the file main.c my main program. I wish to create another file, which contains a function which I can then use in my main.c file, using #include. How do I do this: 1. What name and extention does the second file have? 2. Does the second file have a main()? I would think not. 3. Does the second file need to be in the same directory as stdio.h and all of those, or can it be anywhere? 4. How do I indicate in the content of the second file which function(s) I wish to be accessible to files which include it? 5. Do I compile the second file with the same command as I generally use? 6. How do I include the second file in main.c? I assume these are straightforward questions to anyone who has experience with working with library routines. As always, thank you for your help.

Actually creating you own includes files is pretty simple. I do it alot, with many functions that I have found that I use over. Anyway, the file extension doesn't matter, just as long as it is in the normal format just like any other extension. Ex. functions.h, functions.bts, it doesn't really matter. No, the file would only contain the functions and any variable declarations such as that, but it should not contain a main() function, otherwise the compiler will come up with an error, something like Multiple Declaration of Main. Well, no it doesn't have to be. If it isn't in the main include directory (the directory with stdio.h, and all the other ones) then you will have to use #include "file.file" to include the file, assuming the file is in the same directory as the source code file, if it isn't include the path (Ex. #include "c:/myincludes/file.file"), changing file.file to the appropriate name of course. If you do put the file in the main include directory you can include it just like you would any other include file. Hmm, you really can't publicize or privitize anything. It really just depends on what functions you put into the file. I don't really understand this question. To use the functions in the file, you just include the file like any other file. That should do it, have fun coding. - Copren Technologies -

I won't repeat the answers already posted, but I will explain roughly how this works, in my typical painfully-long-winded style... Headers can be used to #include precompiled library code (either static lib files right into your project at compile-time, or DLLs at runtime), or raw source code. You are interested in the latter, though technically raw source code is not actually being referred to, because all source gets compiled (to object files, such as with .o extensions) before use anyway. If one considers that compilation is only an initial step, where each source file (typically with a .c or .cpp extension) gets copiled into a separate "unit" (object file), this is easier to visualise. Afterwards, it's up to the linker to bring all the pieces together (hence the term "linking"). The linker doesn't care whether the compiled stuff comes from your project directory or other directories (specified in the linker's "lib" directory listing). Of course, for compiled .o files in the project directory, you don't have to specify the name of each file to search for compiled functions, but one does if the .lib is in the \lib directory, although most modern compilers/linkers predefine the most common .lib files required. Unfortunately, convenience features (anything out of sight) often make things harder to understand when something needs to be modified. Anytime we make a source file with anything other than main() in it (and there must be only one for a given executable), we are making a separate precompiled object file. That object file is usually intended to be statically linked (joined with) the main() code, though it can also become part of a library (grouping of objects), whether static (.lib) or dynamic (.dll). Headers may just #include some macros and yet more headers, but commonly they contain the definitions for functions, that are compiled into object file(s) somewhere. Consider this: #include < stdio.h > In many modern IDEs (compiler+linker+editor), this is magic. In fact, the location of where the compiled code resides has already been specified for the linker (the \lib directory), as well as the appropriate library, such as libc.lib or whatever (often this is refered to through indirect means). The use of angle brakets around the specified header, means "look for the file in the specified search paths", which typically includes both the project directory, and the "include" directory (another pre-specified thing). Alternative "lib" and "include" directories to search may be added (in the makefile, project file, or directly on the command line), but for functions we just plop into extra source files, we need only do this: #include "MyHeader.h" The quotes simply mean don't bother looking all over the place, just where specified, which when no path is specified, means in the project directory with everything else. Right then, here's an example at last ;). All files are in the same project dir: //in MyProj.c #include < stdio.h > #include "MyHeader.h" int main() { int i = MyFunc(6); printf("value is %d", i); return 0; } /////////////////////////////// //contents of MyHeader.h #ifndef _MYHEADER_H_ //inclusion guard #define _MYHEADER_H_ int MyFunc(int iVal); //prototype #endif//_MYHEADER_H_ ////////////////////////////// //contents of MySource.c #include "MyHeader.h" //actual code for func... int MyFunc(int iVal) { return iVal*33; //whatever } The compiler will compile MyProj.c and MySource.c separately, and create compiled object files, with names such as MyProj.o and MySource.o (though the naming may vary with compiler, or if the command line is used). MyProj.c needed to #include MyHeader.h in order to know how MyFunc is used. MySource.c also had to #include the header, but only because a prototype is supposed to come before a definition in C/C++. An #include is literally where an entire file's contents is pasted into the source file (an in-memory copy of it), so wherever '#include "MyHeader.h"' is in any file, the compiler actually sees 'int MyFunc(int iVal);'. At this point, each compiled source file knows virtually nothing about the other. Traditionally in C, this is a means of "isolating" or "containing" chunks of code. The linker is sometimes forgotten, but it does a lot of work. It will scour the object files in the project directory, as well as specified libs in the \lib directory, and put all the code together into an executable. It knows how to find MyFunc that main() uses, because MyHeader was #included, which explained exactly how the functioned looked (was declared). The linker found the actual compiled function in MySource.o, because MyFunc had been declared exactly the same in MySource.c (by #including MyHeader.h). This works similarly in C++ with .cpp files, or whatever extension is used. Next time you see the infamous linker error "Unresolved external symbol 'blah_blah_blah' ", it might make more sense. The linker is saying, "I could not find 'blah_blah_blah' in any of the object files in your project directory, or in any of the libraries you told me to look in." I won't cover a frequent cause, name mangling, because that would extend this already incredibly-long-tome even further ;) Cheers

Let's have another approach to understand, what happens, when making a simple c-program work. I am talking plain C in UNIX. Let's assume you use the typical example "helloworld.c". you run the compiler : cc helloworld.c The compiler does more than one thing: 1) check, if there are lines beginning with # which are submitted to the "precompiler" The precompiler extends the source code according to #include files and other (macro)-statements beginning with '#' 2) now the resulting (extended) c-code is submitted to cc1, the first part of the compiler. The first part converts the C code into a cryptic tree structure. 3) Next the tree structure is submitted to cc2, which creates assembler code (machine dependent) from the "tree language" 4) the assembler translates the still readable assembler code into machine language, which is still relocatable and "kind of generic". This is actually the "object code" In bigger projects all or some of the object codes are combined into "libraries". 5) The linker is invoked. The linker converts the relocatable object code into absolute object code and resolves all references in trying to find the corresponding objects in libraries in the "default path" or in the path given as a parameter when the compiler was called. The output is (hopefully) an executable with the name "a.out" or whatever you specified in the compiler command. The format of this executable is: a magic number a header containg the length of the different sections in the file and the machine code, which can just be loaded into the memory and executed. Next is the section of initialized data followed by non-initialized data and (depending on the choice of stripping) the table of symbols and their addresses. If you have bigger projects you typically use "Make files", which contain all kinds of dependencies between different sources and libraries. They control (based on timestamps) which parts of the project have to be recompiled and which ones oare still OK to be reused.