Hello
I am building up my own functions in fun.h and fun.cpp.
Is there a way to group them so that I can use them in different projects?
Details, links, basics explanation are appreciated.
Thanks
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You can compile it as a static library, then in your projects you just need to #include your fun.h file and link the library, libfun.a or whatever you call it.
If you put the header in your dev include folder and the library in the dev lib folder you can treat it the same as any of the other libraries.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
That is true ... but this question is likely coming from someone who is new to development. So it is unlikely (s)he has a large library of functions to compile.
Obviously, when the library of functions gets big (or you wish to distribute the library but not the source), then you should go to making them part of a library.
How slow is a slow compile? It is very likely the library of functions is small - otherwise, it is likely that this set of functions (or somethign similar) has already been developed - and the person would be using those.
rr
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2004-07-16
You can link the compiled object file (.o) or create a static library, or a DLL.
However, creating a static library from a single source is wasteful. The linker will have to link all the code, even functions that are not used. If you create the library from multiple files with single functions in each file (or group functions that have dependencies upon eachother), then only the code that is actually referenced by your application (directly or indirectly) will be linked.
You can moste easily create a static libarary from the template. File|New|Project...|Static library. Add your sources and build.
By convention in GNU libraries are named lib<name>.a. And then linked with -l<name>. You can also use the full path and name to link if you wish. This is necessary if you do not add the path with a -L option, or via Project|Project options|Directories..., or the library is not in your project path.
Clifford.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
ok, I must admit all this is not very clear for me,
what is static library, what do you mean link, dll, compile object .o ... the differences,
any introductory ready? link
all I have is a print.h and print.cpp but I want to understand the different concipts suitable for various size projects.
thanks
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2004-07-18
Building a C or C++ program requires a number of stages:
1) pre-processing
The C pre-processor deals with all the lines beginning with # (#include, #define etc.), and performing text replacements for macros. Although the pre-processor is quetly invoked automatically when the C compiler is run, in GCC it is in fact a separate program (cpp.exe). It is sometimes (if rarely) useful to run it separately.
2) compilation
This is the translation of your source code to machine executable code. Compilation deals with the pre-processor output rather than the original text, whichis why errors in macros can cause such problems. compilation also deals with only single compilation units (.c or .cpp files), which is why you need all thoes header files, so the compilar knows how to interface with code external to the compilation unit. Compilation generates .o files (object code). This contains the code, and symbol table information required for linking and debugging. references in the source to external code and data appear in the object code as "unresolved references". It is the job of the linker to resolve these.
3) Linking
The linker takes all the .o files that were created from compilation plus library code (which I'll discuss next), and builds them into a single entity, (the executable). The linker replaces all the "unresolved references" with direct references to code being linked. Any remaining unresolved references result in a linker error. Again it is common to have the linker invoked automatically by the compiler, and indeed Dev-C++ projects work in that way (calling the linker through the compiler). However the linker, like the pre-processor is a separate program (ld.exe). It is more common to run the linker independently that it is the pre-processor.
Static Libraries
Libraries (or archives in GNU parlance, hence the .a extension), are collections of .o files in a single file. The linker can extract and use these .o files. This is why I suggested that it is important to fragment libraries into multiple compilation units, otherwise teh whole library will be linked. The linker will use only those object code modules required ot resolve all references in the application.
Dynamic Link Libraries
A DLL is similar to a static library, except that it is linked at runtime by the OS. This means that the executable can be smaller, and a single DLL shared amongst several programs. The whole of the WIN32 API for example is implemented as a set of DLLs. Also MinGW uses MSVCRT.DLL (Microsoft's C runtime) for its C library (printf(), strcpy(), fopen() etc.). To build a program using a DLL you also require an import library. This is a static library link stub that satisfiesd the linker, and adds code to load the DLL at run-time.
When you use the project facility in Dev-C++, you can add multiple source files, and it will compile and link them for you. You can also add .o files, and it will simply link them. Adding a library allows your projet to use code within the library. The standard libraries, libstdc++.a and libmsvcrt.a are linked automatically for you when necessary, although in MinGW libmsvcrt.a is just an import library for MSVCRT.DLL; other GCC compilers usually link libc.a, a static C library.
Dev-C++ has project templated for both DLL and static libraries. DLLs require a bit of Windows programming knowledge, but static libraries are a no-brainer. Creating a static library is much like creating an executable, only the linker stage is replaced by a librarian (or archive) stage, which assembles the object code into an archive. The program that does this is ar.exe.
Clifford
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello
I am building up my own functions in fun.h and fun.cpp.
Is there a way to group them so that I can use them in different projects?
Details, links, basics explanation are appreciated.
Thanks
You can compile it as a static library, then in your projects you just need to #include your fun.h file and link the library, libfun.a or whatever you call it.
If you put the header in your dev include folder and the library in the dev lib folder you can treat it the same as any of the other libraries.
You would include your header file fun.h in any files that needed the functions declared in it.
You would then add fun.cpp as one of the files in your project.
Or you would use a precompiled version of fun.cpp lying around (as in a library) and link it as needed.
rr
If it's a lot of code, adding the .cpp file to each project can slow things down when you do a 'rebuild all'.
That is true ... but this question is likely coming from someone who is new to development. So it is unlikely (s)he has a large library of functions to compile.
Obviously, when the library of functions gets big (or you wish to distribute the library but not the source), then you should go to making them part of a library.
How slow is a slow compile? It is very likely the library of functions is small - otherwise, it is likely that this set of functions (or somethign similar) has already been developed - and the person would be using those.
rr
You can link the compiled object file (.o) or create a static library, or a DLL.
However, creating a static library from a single source is wasteful. The linker will have to link all the code, even functions that are not used. If you create the library from multiple files with single functions in each file (or group functions that have dependencies upon eachother), then only the code that is actually referenced by your application (directly or indirectly) will be linked.
You can moste easily create a static libarary from the template. File|New|Project...|Static library. Add your sources and build.
By convention in GNU libraries are named lib<name>.a. And then linked with -l<name>. You can also use the full path and name to link if you wish. This is necessary if you do not add the path with a -L option, or via Project|Project options|Directories..., or the library is not in your project path.
Clifford.
ok, I must admit all this is not very clear for me,
what is static library, what do you mean link, dll, compile object .o ... the differences,
any introductory ready? link
all I have is a print.h and print.cpp but I want to understand the different concipts suitable for various size projects.
thanks
Building a C or C++ program requires a number of stages:
1) pre-processing
The C pre-processor deals with all the lines beginning with # (#include, #define etc.), and performing text replacements for macros. Although the pre-processor is quetly invoked automatically when the C compiler is run, in GCC it is in fact a separate program (cpp.exe). It is sometimes (if rarely) useful to run it separately.
2) compilation
This is the translation of your source code to machine executable code. Compilation deals with the pre-processor output rather than the original text, whichis why errors in macros can cause such problems. compilation also deals with only single compilation units (.c or .cpp files), which is why you need all thoes header files, so the compilar knows how to interface with code external to the compilation unit. Compilation generates .o files (object code). This contains the code, and symbol table information required for linking and debugging. references in the source to external code and data appear in the object code as "unresolved references". It is the job of the linker to resolve these.
3) Linking
The linker takes all the .o files that were created from compilation plus library code (which I'll discuss next), and builds them into a single entity, (the executable). The linker replaces all the "unresolved references" with direct references to code being linked. Any remaining unresolved references result in a linker error. Again it is common to have the linker invoked automatically by the compiler, and indeed Dev-C++ projects work in that way (calling the linker through the compiler). However the linker, like the pre-processor is a separate program (ld.exe). It is more common to run the linker independently that it is the pre-processor.
Static Libraries
Libraries (or archives in GNU parlance, hence the .a extension), are collections of .o files in a single file. The linker can extract and use these .o files. This is why I suggested that it is important to fragment libraries into multiple compilation units, otherwise teh whole library will be linked. The linker will use only those object code modules required ot resolve all references in the application.
Dynamic Link Libraries
A DLL is similar to a static library, except that it is linked at runtime by the OS. This means that the executable can be smaller, and a single DLL shared amongst several programs. The whole of the WIN32 API for example is implemented as a set of DLLs. Also MinGW uses MSVCRT.DLL (Microsoft's C runtime) for its C library (printf(), strcpy(), fopen() etc.). To build a program using a DLL you also require an import library. This is a static library link stub that satisfiesd the linker, and adds code to load the DLL at run-time.
When you use the project facility in Dev-C++, you can add multiple source files, and it will compile and link them for you. You can also add .o files, and it will simply link them. Adding a library allows your projet to use code within the library. The standard libraries, libstdc++.a and libmsvcrt.a are linked automatically for you when necessary, although in MinGW libmsvcrt.a is just an import library for MSVCRT.DLL; other GCC compilers usually link libc.a, a static C library.
Dev-C++ has project templated for both DLL and static libraries. DLLs require a bit of Windows programming knowledge, but static libraries are a no-brainer. Creating a static library is much like creating an executable, only the linker stage is replaced by a librarian (or archive) stage, which assembles the object code into an archive. The program that does this is ar.exe.
Clifford
Woh, Clifford. *Pats on the back*
Kip