I am new to programming with C++. So I am trying to inspect other's code to learn. I started inspecting a new prototype which has a function named myFcn. Its comment lines describe it requires mk.h, mk.lib and mk.dll files to be compiled. The project was successfully built. But when I go over the calling line of myFcn and press F12 (go to definition), the declaration prototype of myFcn appears and hitting again F12 does not bring me the body of the myFcn. I guess the function definition is in the mk.lib or mk.dll files. How can I find the body of the function?
EDIT 1:
If I had several dll and lib files, could I recognize the file that myFcn was compiled in?
It seems that the function you are trying to use is compiled in the library which you use.
The purpose of this system is to let people use your functions without the need for them to edit them or understand their source code. This means that the author of the library has written the function, and compiled it into a library (.dll, .lib and .h).
By including the .h file in your project, and linking the .lib at compilation and the .dll at runtime, you can use this function without the need to ever see more than the header file.
If you wish to understand the code of this function, go to their website, and see if they provide the full source code.
Edit based on edit of question: As far as I know there is no direct way to see which header file links to which library. It is possible to view which functions are in a certain library. On Linux this is the 'nm' command for .a files (gcc libraries). For Windows some methods are described here: How to view DLL functions?.
The function body is likely to be compiled, if then you can't see the source code of it.
Related
I am working on a project and I need to make a class which I will share using a static library. So far I wrote the implementation inside a .cpp file and shared only de .h and .lib files. If I use those inside another project and I try to debug something that uses my class I am able to see the full implementation written in the .cpp file. Is there any way I could hide the implementation?
If I use those inside another project and I try to debug something that uses my class I am able to see the full implementation written in the .cpp file. Is there any way I could hide the implementation?
You can only see the implementation in .cpp because:
.lib has debug information not stripped.
.cpp file happens to be in a location mentioned in the debug information (i.e. there is no copy of .cpp inside .lib).
If you remove any of the above conditions you won't be able to see the source in the debugger.
You can use the pimpl idiom to hide the implementation.By switching to pimpl idiom, you can change your implementation anytime without affecting the way your client uses library.
But to your question, if you are distributing your header and library file only, then others won't be able to see your implementation. The library has embedded info about your source files in your machine. That's why you are able to debug like that.
I want to ask something that might sound stupid but I dont know how to get over it.
I wrote a C++ program with some header files and 2 cpp files, one of which includes main.In the header files there are the definitions of some classes I created that have some inline functions and some functions that I declared in the classes and defined in one of the cpp files (not the one with main).
The program compiled and run fine but I wanted to change a few details in some of the inline functions of the classes. I did those changes and the program compiled and ran BUT it was using the previous version of the header files and not the new one.
I have tried creating a new project using the new files but even then the program will actually use their old version.
I am using Dec-C++5.11 in windows 10.
Solved. Looks like I needed to change the file name. Thank you very much!!
Some build systems will only perform "incremental" builds, so if you change a source file then that source file is recompiled, but unless you rebuild the whole project your original header content may still be used. This is even more so the case if you are using precompiled headers, and it may also affect inline functions in that their content has already been "inlined" into source files for whom a rebuild is not being triggered.
Changing the header's filename will work around this "cache" in many cases, but the correct (and far more user-friendly) approach is to ensure that you instruct your IDE to rebuild the entire project from scratch. In Dev-C++, that option is called "Rebuild All". I would generally recommend this option whenever you alter a header file.
(If you were using GNU Makefiles, you would perform make clean before your next make all).
I have a embedded controller code handed over, it has a bunch on .c files and some headers and a lot of associated files for the embedded processor, its a motorola MC9S12DT256 and it uses a not-so-good compiler - Cosmic. i used Visual studio(just a txt editor) for modifying the code and it changes the hex file being burned to the processor.
I got it earlier this week and spent most of my time on it and it worked ok for minor changes (where changin a value in the code and compiling again made the necessary changes) Now i have to make some major changes. The code calls certain functions which are not to be found any where in the all of the .hpp/.h/.cpp i got. there are no associated dlls as well. I tried to find some basic link and put it in a .sln and still most data is not recognized (as in i cant go to declaration of defn).
So my question is - how to get to the function definiton to where it is called when VS blanks out. Find all references also does no help
Thanks
PM
They may be compiler intrinsics (functions provided by the compiler rather then in a library). But it is not clear how you have determined that they do not exist in a static library or why you think you should be able to see a definition (as opposed to a declaration).
When using Visual Studio as an embedded project IDE, you should create the project as a "makefile project" (even if you don't actually have a makefile), and you need to add all the necessary header paths for your embedded code and the Cosmic compiler standard header folder as include files to the project - VS scans the header files for declarations for Intellisense code completion and browser navigation.
Recently I discovered a problem on the midas and I fixed it, the problem now is that I want to use MidasLib not the midas.dll and with the source code I'm only able to build the DLL.
The source is C++ and I have very few knowledge with it. I know the MidasLib.pas uses internally midas.obj, so I need to create it to statically link the midas to my application. How to do it on C++ Builder? (XE)
When you compile C++ code, the compiler creates an .OBJ file for each .CPP/.C file you have and saves them somewhere on your computer. What happens in most cases is that one would run a linker on all of those .OBJ files to join them into a single EXE or DLL, but in your case you don't need those results. Your C++ Builder is, like most programming IDEs, automatically doing both the compilation and linking.
If you just want the .OBJ, you need to find where in your project folder C++ Builder is placing its .OBJ files (called its "intermediate output", typically, as it is the intermediate step between compilation and linking). So you must have a source file called midas.cpp or midas.c that produces a corresponding output file called midas.obj.
I have a project that uses a DLL that I have created. Everything works wonderfully, but I am now extending the library in the DLL to optimize some older functions.
What I was wondering is if I just modify the library to where only the main function body changes and nothing else can I just rebuild the DLL and replace it with the old one or is it because the function body changed I need to rebuild any projects that used this DLL.
The main reason I asked is because all of these projects have me referencing the .lib file and to be honest I am not sure what is exactly in a .lib file of a DLL project.
Any advice would be greatly appreciated.
Thanks
If you're just changing the functions to optimize them, without changing the function signatures, then you can just build your library and deploy it (replacing the old library).
However, if you need to change the function signatures then you can do one of (at least) two things:
Modify the code that's using your library to use the new function signatures.
If #1 is not an option, then consider leaving the old function and deprecating it. Applications with make use of your latest version will have to avoid using the deprecated methods.
You can read more about .lib/.dll here: http://www.screenio.com/tips/dll.htm
If you only change function bodies, and those functions are not template functions, and you compile the dll with the same compile options, as you did back then, you should be fine.
You might have to take care that both the dll and your executable use the same version of the Microsoft C++ Runtime Library. The version of it, that will be loaded, can be overriden by manifest files.
The .lib file lets you write code that uses your DLL as though it was a static library. Essentially it contains the declarations of all the functions in your DLL. It is generated whenever you build the DLL, but if you don't add (or remove, but you should never remove once you've deployed) a function, or change the signature of a function, then it won't change. You will also have a header file to tell the compiler what functions are in your DLL and this you will change by hand when you add a function or change the signature of a function.
If your only change is a bugfix (or perf improvement or whatever) to the actual code inside a function, you can get away with deploying only the updated DLL. For other changes you must deploy the lib and the DLL. If you've changed the signature of a function you'll have to deploy the new .h, change the calling code to call with the revised parameters, and then get the calling code recompiled. If you just added something you can get away with not rebuilding the calling code.