Let say we have a large code base and we are doing development in C++. Do we have to recompile everytime in order to test the code?
If yes then it is going to take ages to do development.
What's the solution to this problem?
Yes, you'll definitely need to compile C++ code if you want to test it. C++ code can't be executed without being compiled.
However, if you organize your project smartly, compilation could take only a few seconds, or maybe up to a minute, even if there are thousand (or even more) of files.
By default, your build system will run an incremental build, except if you explicitly request a "rebuild" or did a "clean" previously. It will then invoke the compiler/linker accordingly and make sure it compiles/links only what needs to be (if a cpp file did not change, no need to compile it, this is all based on file timestamps, if the "object" file (generated) is older than the cpp file (source), the build system knows it's up-to-date and won't generate it again. If you use Visual Studio and/or CMake or whatever IDE, build system, they all support that!
Additionally, you can follow some guidelines to make this even faster:
Firstly, organize your project in modules (libraries), ideally with dynamic link. Then when a file from a library is changed, only this library needs to be compiled (other libraries or programs using the modified library won't have to be compiled again).
When you'll modify only an implementation file (cpp file), only this file + link of the module using it will be needed.
When you'll modify an header file (h file), all cpp files including it will need to be recompiled, so you must be careful to optimize your includes. Prefer forward declaration (see why here)to includes whenever it's possible (else, your header becomes a dependency of all cpp files using the other header file including yours...as a cascade, modifying this header file will end up requiring compilation of tones of cpp files). Don't include files you don't need (because it will fire a new useless build when the header file changes). Possibly use precompiled headers to speedup compilation.
Note: As commented, there are apparently some tools that can interpret C++ without compiling it...but that's not what C++ was designed for at the first time. And I doubt they will be fast as compiled code at runtime....so you'll probably save 20sec of incremental build time and then loose minutes at runtime....
Related
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).
Is there a possibility (most likely by using gcc / g++ itself?) to determine which code lines of all files included by a single compilation are actually used?
I use much third-party includes and would like to strip them to the actually used code to speed up compilation.
Maybe g++ can output this by some combination of it's many options?
The best advice I can offer is to break apart huge include files into smaller pieces. This allows developers to include only the files they need to resolve symbols.
My favorite example is windows.h. The mega include file declares the entire Windows API, whether you need them or not. If you only want the APIs for processing files, you get the APIs for dialg boxes as well.
Some shops like the monster include files because they only have to include the one file in their sources. One draw back is that every source file now depends on mega include file. If I change one of the include files, the entire system will be rebuilt instead of a few modules that depend on the header file that I changed.
In my projects, only a couple of files are compiled at a time; usually less than 5. This makes the average turnaround time (modify then build) very fast. The entire system is rebuilt overnight by a server or by developers. There is no need to rebuild source files that have not changed.
So split up your modules, so you are not rebuilding your system every time.
I have a c++ project with many files. When I build the project making even small changes to the code, It recompiles a large no of files. This is increasing the compile time of the project. So I need suggestion about the ways I can improve the structure of the project or any other optimisations possible which will help in reducing the compile time of the project.
Also there are a couple of files which are getting recompiled even when I make no changes to the project. Somehow make doesn't detect that those files need not be recompiled or may be I am missing something.
I am using Codelite on linux(Ubuntu) for my project. The language is C++.
The link provided above will give you a detailed explanation. Just to put it in a lighter way I am adding a few more things.
If you change something in a CPP file only that file will get recompiled. If it is a header file then it will be a different story. If you have a header file included across multiple modules and when you make changes to that header file, all the associated CPP files will get compiled and again that is the way it should be. So you need to be careful while writing the code if you really care about this aspect. At a later stage it will be difficult to manage such things.
Regarding the compilation of some files even if you don't change anything may happen when
1] we tell the compiler to do so.
2] some CPP or header files are generated or modified automatically while run your build
3] there is a change in file time stamp
4] there is a change in folder name/structure
Last but not least, also try changing the code lite build target.
These are the possibilities I know. There will be more [definitely :)]...
I recently switched to Visual Studio 2010 and for Intellisense not to take half a minute to show up when using boost libraries, Microsoft's suggestion seems to use precompiled headers.
Except that I never used them before (except when forced to by Ugly ATL Wizards (TM)), so I searched around to figure out how they work.
Basically, the Big Centralized stdafx.h approach seems plain wrong. I never want to include (even cheaply) a whole bunch of header files in all my sources. Since I don't use windows libraries (I make C++/CLI higher level wrappers, then use .NET for talking to the outside world), I don't have "a whole truckload of non-changing enormous headers". Just boost and standard library headers scattered around.
There is an interesting approach to this problem, but I can't quite figure out how to make this work. It seems that each source file must be compiled twice (please correct me if I'm wrong): once with /Yc and once with /Yu. This adds burden on the developper which must manually tweak the build system.
I was hoping to find some "automatically generate one precompiled header for each source file" trick, or at least some "best practices", but most people seem happy with including the world into stdafx.h.
What are the options available to me to use precompiled headers on a per source file basis ? I don't really care about build times (as long as they don't skyrocket), I just want intellisense to work fast.
For starters, you are reading the article wrong. Every file is NOT compiled twice. The file stdafx.cpp gets compiled once with /Yc (c, for create) before anything else and then every other file in your project gets compiled once with /Yu (u, for use) and imports the result of the previously created saved state from stdafx.cpp.
Secondly, the article is 7 years old and is talking about VC++ 6, so you should start off distrusting it. But even assuming the information in it still applies to VC++ 2008 or 2010, it seems like bad advice. The approach it recommends using /pragma hdrstop is solution looking for a problem. If you have headers that contain things you don't want in every file, then they simply shouldn't go in your pre-compiled header.
Your problem basically seems to be that Intellisense is slow for Boost in VS2010? I don't have a direct solution for this problem, but could Visual Assist X be an option for you? I have used it in various versions of Visual Studio now and with great pleasure. Not a direct solution, but it might work for you.
Precompiled headers aren't too bad if you use them properly.
Don't use them as a replacement for proper and precise #includes, but as a way to speed things up. Achieve this by making the precompiled header do nothing in release builds, only speeding stuff up in debug.
You are wrong, each file is only compiled once. You have one .cpp file that is compiled with /Yc and the rest are compiled with /Yu. The file with /Yc, which is stdafx.cpp by default, contains one line, #include "myMainHeader.h" (changed the name from the default) All other .cpp files must start with #include "myMainHeader.h" When your /Yc file is compiled, the entire internal state of the compiler is saved. That file is loaded when each of your other files is compiled. That is why you must start with including the PCH, so that the /Yu option doesn't change the result of compilation, only the time. Xcode does not make this requirement and will use a PCH regardless of if your .cpp file starts with the right include directive. I have used libraries that relied on this and could not be built without PCH.
I'm a beginner starting to use Microsoft Visual C++ Express 2010 for Windows Programming. I've created a new C++ application using native code, not managed or MFC. I had Visual Studio create for me the basic windows code to create one window with simple menus (chat.cpp). I modified this file and I was able to compile correctly and see my changes take effect.
Now I've added one more source file to the solution (intro.cpp) which I include in my header and call from within chat.cpp. This seems to work just fine, but with one problem. The compiler doesn't seem to be applying my code changes occasionally: I make various edits, recompile, and the "old" code seems to be running. Then, after a while, after I make only a tiny modification, the compiler seems to "catch up" and it runs the new code including all the previous changes I had made.
Is there some kind of cache? Do I need to tell the compiler which files to compile and which ones to just link from object files? Did I make a mistake when I added the file to the solution?
Does intro.cpp have a header file? is that in your solution too?
It's hard for me to imagine that this area of such a mature IDE has a bug here, so I would examine your file list first. Make sure that the Solution Explorer shows all the files you have added and are editing. This is the list that VS uses to determine rebuild is needed.
EDIT: I admit it's not clear to me from your description why it would fail right now. However, typically header files do not include code, it works the other way around (except for class template header files, such as the STL headers). There is some discussion about pros and cons here. The most compelling argument to me in favour of code including headers rather than vice versa is that the header file contains the interface, while the code file contains the implementation.
I would try restructuring your code to a more traditional structure where intro.cpp includes intro.h and any others it needs, and the same with chat.cpp. Then your compilation units are intro.cpp and chat.cpp, and they depend on the associated header files, so provided they are properly listed in the SOlution Explorer, all should work. You can clean up the build dependencies to avoid dups and reduce build time once you have it working as you wish.