Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
I don't seem to understand the need of *.lib files. Let's say I have 3 *.c files:
module1.c
module2.c
module3.c
myheaders.c
In each .c file we have 2 functions. Now if I call function x in module3.c from module1.c, module1.c knows about function x by looking in myheaders.c.
So if I compile this in VS I get a shiny little portable *.exe with no *.lib file attached, so why and when does one need *.lib files?
*.lib files are for other programmers who want to use your functions in their own programs.
*.exe files are for end users who just want to run your program.
Libraries can be made from groups of related functions that have been tested. They allow you to reuse code without having to go through the compilation stage each time.
Dynamic or Shared libraries allow you to upgrade parts of your executable without recompiling the executable or altering it.
In larger projects, validation of a program is a large portion of the schedule. Libraries that have already been tested will shorten the schedule and make everybody happy.
Let's say I wrote a compiler. I implement some IO functions (in English - cout) to work on windows. If you write code, and want to compile it with my compiler, you don't want to wait on each compilation for my implementation of cout to compile. More than that, you don't care about the HOW, so you don't need the source code (witch will take up some memory). So, instead of recompiling code, you get a *.lib file with the functionality, compiled once by me, no heavy source code to take along.
When you sell someone a program you wrote to use with other programs, you (usually) don't want to give him the source code - just the functionality.
If two languages share the same standard's for functions (or if the linker knows about different standards) I could write some code in one language, compile it to a *.lib, then use it with the different language. That doesn't look useful until you download some third party code written in a language you are not using.
The header files doesn't contain the function, they only contain there prototypes so the compiler know how to call them. In the case of predefined functions, they are precompiler seperatly as .lib file which refers to (library) so to call them you will need that .lib file and the header so the compiler know how to call them. when you compile using VS or any compiler, there is another process called the linking which links these files as a single executble.
Because library can be use in a lot of programs.
Your header file is necessary only for your prof
Good Question.
*.exe stands for executable. This executable could be used to run the program from End user or developer.
*.lib could be used when someone wants to use functions from your code.
There are two types of linking libraries. Static linking and Dynamic linking. follow this question to understand the difference between both of them.
Static linking vs dynamic linking
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I have created a small library with a few functions. It has a .h file and a .c file. Let us say it's a 'hello world'. I want to put it on my Github to make it publicly available for everyone to clone and use my functions in their C or C++ code. There are two ways I see it:
Put out the header and the functions code and tell everyone to #include "library" in their programs.
Put out the header (for information) and the object file .o and tell everyone to link it during compilation themselves.
How should I go about it? What is the preferred way or a standard in creating C/C++ libraries?
EDIT:
Follow up question: is there a way I can prepare an installation file in my repository such that the user installs my library and can later include it as #include <library> without the need of putting my files in his working directory?
I will ignore the question about "preferred" since that delves into matters of opinion. Covering some pros and cons, though, is less controversial. Please do not assume that this list is exhaustive.
1) Put out the header and the functions code and tell everyone to #include "library" in their programs.
Since this is not a header-only library, it would not be enough to simply #include the header file. Others would need to #include the header file and compile your source file as part of their projects. In any event, this is not what is usually meant by "static library". However, it could be adequate for a "library" small enough to warrant only a single source file.
2) Put out the header (for information) and the object file .o and tell everyone to link it during compilation themselves.
Both parts of this approach are problematic. First, the header would not be merely for information; others would need to #include it so that their compilers are aware of your API. Second, object files (.o) can be compiler-specific, so this approach would be useful only for those using the exact same build environment as you. That probably narrows down the field enough to make this approach of negligible use. Still, use your own judgement.
Since we're out of your ideas, let's move on to some others.
3) Compile your code as a static library (.a on Linux, .lib on Windows), then distribute the header file and the library file. Others would #include the header file in their code and link against your library.
The caveat here is that the library is platform-specific. This is less restrictive than compiler-specific, but it still might mean multiple releases on your part for different platforms. There is also some onus on others to copy the library file to an appropriate directory. Newer programmers might not know which directories could be appropriate.
4) Put out the header file, the source code, and a makefile that will enable others to compile and install your library for themselves. Then they would #include the header file in their code and link against your library.
This is the least restrictive approach for your end users, but it does require a good makefile from you to be successful. That takes you into a programming world outside C and C++ (separate languages, by the way).
For other projects, a potential downside to the makefile approach is the possibility that an end user does not have a (supported) compiler installed. Fortunately, static library developers may assume their end users have compilers. :)
Note that the point of Git is to share source code. If you consider Github to be your primary distribution method, then you should look at options that involve distributing the source code. On the flip side, you desire a pre-compiled option, you should consider something other than Github to be your primary distribution method.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 3 years ago.
Improve this question
I want to learn the source code of floor() in c Function library, so I use the Vs quick lookup definition function to find in VS, and then
I find that _Check_return_ _ACRTIMP double __cdecl floor(_In_ double _X); statement。
I don't know what to do next.enter image description here
Because there seems to be only a macro definition, no function definition。
Is it that I should not use the IDE to view the source code, I am a newbie。
In general, for C, no.
C code can be shipped in pre-compiled form, when you get:
A header file (mylibrary.h) that provides declarations of contents of a particular module of code.
A library (mylibrary.lib, mylibrary.dll, mylibrary.so and so on, depending on the exact type of library and the platform), this contains the code and data that are needed for the module.
These two files are enough; the compiler reads the header when you #include it in your code, and the linker "glues in" the necessary code and data from the library.
Note that there is no source code available.
The floor() function is part of the C runtime library and shipped with the compiler implementation; I'm not sure whether Microsoft provides the source for theirs. Of course there are open source implementations, here is the code from the "musl" implementation of the C standard library, for instance.
Most library functions are visible to your project just as prototypes, as they have been already compiled into a static (or dynamic) library. As far as functionality is concerned, the compiler could ship without those sources, as they are not necessary to compile your program. It's pretty much the same e.g. for OS APIs: you invoke them all the time, but you don't have the Windows sources.
On the other hand, Visual C++ traditionally shipped with the sources of (most of) its C runtime to aid debugging; they are usually found somewhere under your VC++ installation directory.
edit better indications in this answer; thanks #Martin R for digging it out
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
Allow me to preface this question by letting you know that I have no formal CS education and have been self-learning C++.
I would like to understand what the different ways of including third party libraries in a project are.
How to identify how a project is to be included if there is an interesting library on github?
I've read about concepts of dynamic and static linking in a windows context however I am still somewhat not clear about them.
Libraries contain implementations of functions, regardless of being static or dynamic. A library contains m function implementations, of which a subset n < m is exposed to the user. In C++, for these n functions the library normally offers a header file provided to you for inclusion, a list of so-called function prototypes. Depending on what header you include, and what function you have used in your project, the linker memorizes the prototypes of such external functions and demands you to link the appropriate library against your executable to satisfy the unresolved prototype symbol.
Function implementations of static libraries are welded at compile time into your executable. Function implementations of dynamic libraries remain exactly in their location, there's just a stub welded into your executable that will transfer control over to the dynamic library upon a call to it.
Briefly, you just need to do following steps to include/referece a C++ library:
Add the heade file (*.h or *.hpp) directory to your project's include paths.
#include the xxx.h in your source code files, to call the functions/methods/interfaces.
Add libaray:
For static lib (*.lib on Windows or *.a on Linux), add the lib to your project's library paths.
For dynamic lib: just make sure the *.dll (or *.so) are in the same directory of your project output (like *.exe or your lib), for running or to publish/deploy.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I've lost my head just a little trying to reason the most effective means of compiling a c++ project. I stick to more managed languages like Java so the CMake file is a bit obtuse to me.
My main problem is what do I compile as a library and what do I just compile together? I have a main function in my program with various over classes in different files with headers. What is the most normal way of handling these files together? Should I compile the main function separate from the classes then link them or should they be a shared library even though it is a bit small for a library?
Mainly I am looking just for general guidelines of what should be compiled together, what should simply be linked, and someone to more clearly explain the norms/best practices of how this all works.
I understand that the compiler needs to convert the Header and Source files to object files and then combines them together as a binary. I am just confused at what should go into the binary.
If you need the code for only one executable you can just link all object files together. Libraries are useful if you need the same functions/object files in different executables.
Of course the bigger a project gets you could also use sub projects which output libraries and then link the main project files and the sub project libraries together.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I am currently working on a Raspberry Pi project that uses the OpenCV library, among others. The OpenCV library is quite large, and the build process for it is decently extensive. I found a script which downloads and installs the latest version of OpenCV, and following some suggestions from this question, I was able to build the library, and begin using the functions within OpenCV.
Considering the actual build process for OpenCV took considerably longer than building our project would, is it acceptable to just build the library once, as opposed to building the library each time we build our project?
While I realize this is probably personal preference, I am wondering how others handle situations similar to this.
As you probably already know, code that does not change does not need to be recompiled. This is true for executables and libraries alike.
A library is supposed to provide you addictional functionality in a neat, pre-packaged form. The difference between additional code you add to your project and a library is that the code included in a library is supposed to be in a stable state, so that once built the user will be able to use its features without any maintenance hassle; the APIs will be available and they will always work. You will be able to discard any implementation files, and just work with the header files - which provide you with the API within your code - and the library files, which contain the compiled implementation.
You are pretty much pre-compiling part of your program; a part that will also be able to be used in other projects, again without recompiling.
Note that C++ itself is an example of this: an implementation of the C++ standard library (for example libc++) is already included with your compiler, so that you are able to use the standard C++ headers without the need to recompile C++ whole every time you try a "Hello World!" program.
You can even extract libraries out of parts of your project that you feel are already completed and stable: this can allow you to reduce the time required to compile your project even though it becomes bigger. These reasons are part of why modularity is so strongly encouraged when programming.
TL; DR: Recompiling a library only once is not only acceptable, is most probably what you want to do.
It is normal to compile once and then only link the library. For that reason the compilers can detect whether there are changes in source files.