Does adding additional headers make programs slower? - c++

For instance would the following two programs have the save execution time?
#include <iostream>
int main()
{
int a,b;
std::cin >> a >> b;
std::cout << a+b;
return 0;
}
and
#include <ctime>
#include <cstdio>
#include <cstdlib>
#include <cstring>
#include <cassert>
#include <time.h>
#include <algorithm>
#include <iostream>
#include <vector>
int main()
{
int a,b;
std::cin >> a >> b;
std::cout << a+b;
return 0;
}
If so is it a good practice to always include a bunch of header files? How can one test how long it takes to execute a program? Using predefined input.

Does adding additional headers make programs slower?
No. Of course, someone will show up now with some corner case to refute this. But no, extra headers don't make C or C++ programs slower in general.
If so is it a good practice to always include a bunch of header files?
Don't include "a bunch." Include the ones you use. To include extra headers increases compilation time, and if the headers are from your own project, can result in recompiling many objects in your project whenever you touch any header.
How can one test how long it takes to execute a program?
With a stopwatch. Or time(). Or rdtsc. Or QueryPerformanceCounter(). Lots of ways.

For instance would the following two programs have the same execution time?
Yes. Including additional header files doesn't affect the execution time of the program.
Header files are processed at compile time. So they (usually) don't slow down your code.
There could be corner cases, that inclusion of particular headers might pickup a different implementation of some algorithm, that is inherently slower than a different one picked up without that header.
If so is it a good practice to always include a bunch of header files?
No. You should include the header file for every type you are using, no more no less.
How can one test how long it takes to execute a program? Using predefined input.
There are several possibilities to do that. You can run your program in a profiling tool, or simply measure time yourself (in a script or such).

Does adding additional headers make programs slower?
For instance, would the following two programs have the same execution time?
Adding additional headers won't affect the runtime of your program. It will affect the compile time however because the compiler now has to include these additional headers in your program.
If so is it a good practice to always include a bunch of header files?
It is best practice to only include the header files that you will be using in your project. Also, be careful not to include the C version of a header and the C++ version of a header, you may run into issues.
How can one test how long it takes to execute a program? Using predefined input.
I'd recommend checking out the ctime library: http://www.cplusplus.com/reference/ctime/
Remember that execution time is specific to your machine.

I think it will make the program slow because when ever you call a function like cout or cin compiler will find it in header files declared by programmer
More number of header files require more time to find the function definition
Also if including extra header files doesn't increase compilation time then ide(Integrated development environment) should have omit the header file including system
Hope that make sense

Related

C++ modules to speed up template functions

In general, using function templates makes the compilation significantly longer.
A friend suggested that I check the modules (C++20) for optimization.
I don't think it will affect compilation speed at all.
I have no idea how to test this, so I'm asking here.
Will the following code somehow magically optimize the build process?
The definition will still have to be created and compiled, so it won't make any difference?
math.ixx:
module;
#include <typeinfo>
export module math;
import <iostream>;
export
template<typename T>
T square(T x) {
std::cout << typeid(T).name() << std::endl;
return x * x;
}
main.cpp
import math;
void main() {
square(int());
square(double());
}
The code example is too trivial for modules to be of any real use. One file which includes a second file, and nothing includes anything else is not a compilation problem. It's like trying to benchmark how fast adding two integer literals is and then making a statement about the quality of C++'s addition operator.
From a performance perspective, modules solves the following problem: they keep the cost of recompiling a single file from being equal to the cost of recompiling every file that first file includes regardless of whether the included files changed.
If you #include <vector> in a simple program, your source file now contains thousands of lines of code. If you change that source file, the compiler will have to recompile thousands of lines of code which did not change. If you have 1000 files that each include <vector>, you now have 1000 identical copies of <vector> which the compiler must compile every time you compile all of those files.
This is the sort of thing that modules prevent. If you import a module for a library, you changing your source file will not necessitate recompiling those included headers. If you import dozens of modules across hundreds or thousands of files, this adds up pretty quickly.
Pre-modules, making a small change to a widely included header prompts a full recompilation of your entire project. In a fully-modularized codebase, there will be a lot of files that get recompiled. But what doesn't happen is that you recompile stuff that didn't rely on the change. You may have changed a widely used header, but you didn't change the C++ standard library. So if you included it via modules, then <vector> and such won't get recompiled.
This is where modules saves performance.

c++ class without header

Ok, so I don't have a problem, but a question:
When using c++, you can transfer class to another file and include it without creating header, like this:
foo.cpp :
#include <iostream>
using namespace std;
class foo
{
public:
string str;
foo(string inStr)
{
str = inStr;
}
void print()
{
cout<<str<<endl;
}
};
main.cpp :
#include "foo.cpp"
using namespace std;
int main()
{
foo Foo("That's a string");
Foo.print();
return 0;
}
So the question is: is this method any worse than using header files? It's much easier and much more clean, but is it any slower, any more bug-inducing etc?
I've searched for this topic for a long time now but I haven't seen a single topic on the internet considering this even an option...
So the question is: is this method any worse than using header files?
You might consider reviewing the central idea of what the "C++ translation unit" is.
In your example, what the preprocessor does is as if it inserts a copy of foo.cpp into an internal copy of main.cpp. The preprocessor does this, not the compiler.
So ... the compiler never sees your code when they were separate files. It is this single, concatenated, 'translation unit' that is submitted to the compiler. There is no magic in .hh nor .cc, except that they fulfill your peer's (or boss's) expectations.
Now think about your question ... the translation unit is neither of your source files, nor any of your system include files, but it is one stream of text, one thing, put together by the preprocessor. So how would it be better or worse?
It's much easier and much more clean,
It can be. I often take this 'different' approach in my 'private' coding efforts.
When I did a quick eval of using gmpxx.h (mpz_class) in factorial, I did indeed take just these kinds of shortcuts, and did not need a .hpp file to properly create my compilation unit. FYI - The factorial of 12345, is more than 45,000 bytes. It is pointless to read the chars, too.
A 'more formal' effort (job, cooperation, etc), I always use header's, and separate compilation, and the building a library of functions useful to the app as part of how things should be done. Especially if I might share this code or contribute to a companies archives. There are too many good reasons for me to describe why I recommend you learn these issues.
but is it any slower, any more bug-inducing etc?
I think not. I think not. There is one compilation unit, and concatenating the parts has to be right, but I think is no more difficult.
I've searched for this topic for a long time now but I haven't seen a single
topic on the internet considering this even an option...
I'm not sure I've ever seen it discussed either. I have acquired the information. The separate compilations and library development are generally perceived to save development time. (Time is money, right?)
Also, a library, and header files, are how you package your success for others to use, how you can improve your value to a team.
There's no semantic difference between naming your files .cpp or .hpp (or .c / .h).
People will be surprised by the #include "foo.cpp", the compiler doesn't care
You've still created a "header file", but you've given it the ".cpp" extension. File extensions are for the programmer, the compiler doesn't care.
From the compiler's point of view, there is no difference between your example and
foo.h :
#include <iostream>
using namespace std;
class foo
{
//...
};
main.cpp :
#include "foo.h"
using namespace std;
int main()
{
// ...
}
A "header file" is just a file that you include at the beginning i.e. the head of another file (technically, headers don't need to be at the beginning and sometimes are not but typically they are, hence the name).
You've simply created a header file named foo.cpp.
Naming header files with extension that is conventionally used for source files is not a good idea. Some IDE's and other tools may erroneously assume that your header is a source file, and therefore attempt to compile as if it were such, wasting resources if nothing else.
Not to mention the confusion it may cause in your colleagues. Source files may have definitions that the C++ standard allows to be defined exactly once (see one definition rule, odr) because source files are not included in other files. If you name your header as if it were a source file, someone might assume that they can have odr definitions there when they can't.
If you ever build some larger project, the two main differences will become clear to you:
If you deliver your code as a library to others, you have to give them all your code - all your IP - instead of only the headers of the exposed classes plus a compiled library.
If you change one letter in any file, you will need to recompile everything. Once compile times for a larger project hits minutes, you will lose a lot of productivity.
Otherwise, of course it works, and the result is the same.

Why use namespace if iostream is imported

I am beginner at C++, and I have recently been introduced to namespaces like std. However, if functions like cout and endl are defined in the iostream header file, why include the std namespace at all? Or are these functions actually defined in the std namespace? If that is the case, then why include the iostream file?
Namespaces and #include directives are different things:
When you include a header (like iostream) you are telling the preprocessor to treat the contents of the file as if those contents had appeared in the source program at the point where the include appears.
Why use includes instead of just throwing the code right there?
From:
http://www.cplusplus.com/forum/articles/10627/
(1) It speeds up compile time. As your program grows, so does your
code, and if everything is in a single file, then everything must be
fully recompiled every time you make any little change. This might not
seem like a big deal for small programs (and it isn't), but when you
have a reasonable size project, compile times can take several minutes
to compile the entire program. Can you imagine having to wait that
long between every minor change?
Compile / wait 8 minutes / "oh crap, forgot a semicolon" / compile /
wait 8 minutes / debug / compile / wait 8 minutes / etc
(2) It keeps your code more organized. If you seperate concepts into
specific files, it's easier to find the code you are looking for when
you want to make modifications (or just look at it to remember how to
use it and/or how it works).
(3) It allows you to separate interface from implementation. If you
don't understand what that means, don't worry, we'll see it in action
throughout this article.
Namespace on the other hand allows you to group classes and functions under a scope. They provide a way to avoid name collisions between those entities without the inconvenience of handling nested classes.
A C++ file can have a namespace within it, and different C++ files can have the same namespace inside of them.
// Header1.h
namespace SomeScope
{
extern int x;
}
// Header2.h
namespace SomeScope
{
extern int y;
}
// Some CPP file
#include "Header1.h" // access to x
SomeScope::x = 5;
#include "Header2.h" // access to y
SomeScope::y = 6;
I hope this helps. Namespaces just act like a place to store various identifiers to avoid name-clashing. SomeScope::x is an entirely different x identifier than AnotherScope::x.

Does it matter whether I use standard library preprocessor includes in my header file vs. the corresponding implementation file?

If I have a project with
main .cpp
Knife .h and .cpp
Cucumber .h and .cpp
and I want to use Knife's members in Cucumber, does it matter whether I use the following:
#include "Knife.h"
#include <iostream>
using namespace std;
in Cucumber.h or Cucumber.cpp (assume that Cucumber.cpp already has an include for Cucumber.h)?
My recommendation is to minimize the number of files included in the header files.
So, if I have the choice, I prefer to include in the source file.
When you modify a header file, all the files that include this header file must be recompiled.
So, if cucumber.h includes knife.h, and main.cpp includes cucumber.h, and you modify knife.h, all the files will be recompiled (cucumber.cpp, knife.cpp and main.cpp).
If cucumber.cpp includes knife.h and main.cpp includes cucumber.h, and you modify knife.h, only cucumber.cpp and knife.cppwill be recompiled, so your compilation time is reduced.
If you need to use knife in cucumber you can proceed like this:
// Cucumber.hpp
#ifndef CUCUMBER_HPP
#define CUCUMBER_HPP
class Knife;
class Cucumber
{
public :
///...
private :
Knife* myKnife
}
#endif
//Cucumber.cpp
#include "Cucumber.hpp"
#include "Knife.hpp
// .. your code here
This "trick" is called "forward declaration". That is a well-known trick of C++ developers, who want to minimize compilation time.
yes, you should put it in the .cpp file.
you will have faster builds, fewer dependencies, and fewer artifacts and noise -- in the case of iostream, GCC declares:
// For construction of filebuffers for cout, cin, cerr, clog et. al.
static ios_base::Init __ioinit;
within namespace std. that declaration is going to produce a ton of (redundant) static data which must be constructed at startup, if Knife.h is included by many files. so there are a lot of wins, the only loss is that you must explicitly include the files you actually need -- every place you need them (which is also a very good thing in some regards).
The advice I've seen advocated was to only include the minimum necessary for a given source file, and to keep as many includes out of headers as possible. It potentially reduces the dependencies when it comes time to compile.
Another thing to note is your namespace usage. You definitely want to be careful about having that sort of thing in a header. It could change namespace usage in files you didn't plan on.
As a general rule, try to add your includes into the implementation file rather than the header for the following reasons:
Reduces potential unnecessary inclusion and keeps it to only where needed.
Reduces compile time (quite significantly in some cases I've seen.) Avoids over exposing implementation details.
Reduces risk of circular dependencies appearing.
Avoids locking users of your headers into having to indirectly include files that they may not want / need to.
If you reference a class by pointer or reference only in your header then it's not necessary to include the appropriate header; a class declaration will suffice.
Probably there are quite a few other reasons - the above are probably the most important / obvious ones.

#include anywhere

Is the #include <file> meant to be used for headers only or is it simply a mechanical "inject this code here" that can be used anywhere in the code?
What if I use it in the middle of a cpp function to just "inject" code from a single source? will this work or will compilers scream about this?
It is a mechanical inject the code here device. You can include a text file containing Goethe's Faust if you wish to. You can put it anywhere, even in the middle of a function (of course, #include needs a fresh line!).
However, it's strong convention to only use #include for header files. There may be reasons where I wouldn't object on it, for example pulling in machine-generated code or merging all translation units in a single file.
Not only does it work anywhere, but it can lead to some interesting techniques. Here's an example that generates an enumeration and a corresponding string table that are guaranteed to be in sync.
Animals.h:
ANIMAL(Anteater)
ANIMAL(Baboon)
...
ANIMAL(Zebra)
AnimalLibrary.h:
#define ANIMAL(name) name,
enum Animals {
#include "Animals.h"
AnimalCount
};
#undef ANIMAL
extern char * AnimalTable[AnimalCount];
AnimalLibrary.cpp:
#include "AnimalLibrary.h"
#define ANIMAL(name) #name,
char * AnimalTable[AnimalCount] = {
#include "Animals.h"
};
main.cpp:
#include "AnimalLibrary.h"
int main()
{
cout << AnimalTable[Baboon];
return 0;
}
Be sure not to put the usual include guards in any file that will be included multiple times!
Gotta agree with William Pursell though that this technique will have people scratching their heads.
Compilers will not complain, but everyone who has to maintain the code will.
It will work - more or less its semantic meaning is: place code in that file here
EDIT: For abusing usages of #include I can just recommend the following:
#include "/dev/console"
This allows for everything: a one-liner that can do everything, an error, its just a matter of compilation...
Should work, it's processed by your preprocessor, your compiler won't even see it.
#include and other preprocessor directives like #define or #import, can appear anywhere in the source, but will only apply to the code after that inclusion. It is meant to include the referenced code into the source file that calls it.
This MSDN page explains it quite well. http://msdn.microsoft.com/en-us/library/36k2cdd4(v=VS.71).aspx
include is handled by the preprocessor and is a mechanism to inject code. There are no restrictions on the file being included or where this #include is placed in your code (thought it should be in its own line). As long as the file specified can be found by the preprocessor it will import its contents into the current file.
Conventionally you do this for header files. I've seen this being done with cpp files during template instantiation (with proper #ifdef so you don't include it multiple times causing multiple symbol definition error).
If you have a long constant, you can do this for other file types as well. (Though there are better ways of handling long string constants)