This question already has answers here:
C++ math functions can be used without including the directive "math.h" in VS 2013
(2 answers)
Closed 8 years ago.
I have a simple program in which I arrange the elements of an int array in ascending or descending order, and I use the swap() function to move the elements around. I compiled the program without any errors, and it ran like a charm. I only noticed afterwards that I had forgotten to #include the library that swap() is defined in (<algorithm>, or <utility> as of C++11) before I compiled.
Why did it still work? The top of my program looked like this:
#include <iostream>
#include <cstdlib>
using namespace std;
I tried taking out <iostream>, just to see what would happen, and it predictably put out a bunch of 'cout/cin/endl' was not declared in this scope errors, but I was surprised to see that it gave some 'swap' was not declared in this scope errors as well. Does that mean swap() is defined in <iostream>? I don't think it should be, should it?
Anyways, this is probably a big long question for a simple answer, but I'm pretty curious. I'm still learning C and C++, so I don't know a lot of things, and I couldn't find an answer to this particular mystery via the "Almighty" Google Machine, so here I am.
Thanks in advance!
Generally, do NOT rely on the header files that includes other header files.
Always include and only include the header files you need.
For example, if you want to use std::swap(), Google it and you'll see if requires <algorithm> in c++98 and <utility> in c++11, so you should include the file to make sure your code compiles.
Related
This question already has answers here:
Removing '#include <algorithm>' doesn't break the code
(7 answers)
Closed 6 years ago.
It seems when we include <iostream> header, <exception> and <stdexcept> headers are included automatically.
Question is why the reference sites like cppreference and cplusplus.com include <exception> while explaining exception handling?
Is it necessary to include <exception> or <stdexcept>?
You should always include what you use. The C++ standard doesn't state that any particular header has to include another, they are free to do so for convenience. But note that just because that happens to be the case for one compiler, it may not be the case on another (e.g. Visual Studio vs gcc)
You should always follow documentation. When documentation says that in order to use ceratain construct you need to include certain header, the header must be included. Otherwise, tomorrow iostream will stop including the header, and your program will fail to compile or worse - will behave unexpectedly.
This question already has answers here:
When can I use a forward declaration?
(13 answers)
Closed 7 years ago.
So i've just read about forward declarations at various sources (e.g googles c++ style guide) and i am quite confused when i should and when i shouldn't use forward declarations.
One one hand if I always forward declare classes i will never have troubles with circular dependencies and faster compile times.
But on the other hand i will have to use almost exclusively work with pointers to objects which seems quite unsafe considering memory leaks and also unnecessary complicated to work with.
So should i use forward declarations whenever I possibly can or only when its needed to avoid stuff like circular dependencies?
And another question regarding forward declarations. If im working with extern libraries such as GLM (which is a math library) and i need it in many different classes is there a way to forward declare those aswell / does it even make sense to do so?
Examples of what i have to include (GLM):
#include <glm.hpp>
#include <gtc/matrix_transform.hpp>
#include <gtc/type_ptr.hpp>
And for example i will use it like this:
std::vector <glm::vec3> vertices;
Generally forward declarations end up being necessary only if there is some sort of circular dependency, and generally should be avoided.
So the version that says 'only for circular dependencies' is more on the right track.
"Pointers to objects" is not really relevant to the question, as in modern C++ normally raw pointers should be avoided most of the time anyway, using one of the now standard smart pointers instead, or better yet, references. Depending on what you are trying to do, keeping class members out of the class headers using Pimpl or fast pimpl idioms might be a good practice as well.
To last part of your question, what you probably want to do is to include the dependency external library headers that you commonly use in a single header file of your own, and then just include this file in your code modules where required. This can potentially give an advantage in compilation times too, if you have set up to use precompiled headers.
This question already has answers here:
Why should I not #include <bits/stdc++.h>?
(9 answers)
Closed 4 years ago.
I have read from a codeforces blog that if we add #include <bits/stdc++.h> in a C++ program then there is no need to include any other header files. How does #include <bits/stdc++.h> work and is it ok to use it instead of including individual header files?
It is basically a header file that also includes every standard library and STL include file. The only purpose I can see for it would be for testing and education.
Se e.g. GCC 4.8.0 /bits/stdc++.h source.
Using it would include a lot of unnecessary stuff and increases compilation time.
Edit: As Neil says, it's an implementation for precompiled headers. If you set it up for precompilation correctly it could, in fact, speed up compilation time depending on your project. (https://gcc.gnu.org/onlinedocs/gcc/Precompiled-Headers.html)
I would, however, suggest that you take time to learn about each of the sl/stl headers and include them separately instead, and not use "super headers" except for precompilation purposes.
#include <bits/stdc++.h> is an implementation file for a precompiled header.
From a software engineering perspective, it is a good idea to minimize the include. If you use <bits/stdc++.h> it actually includes a lot of files, which your program may not need, thus increase both compile-time and program size unnecessarily. [edit: as pointed out by #Swordfish in the comments that the output program size remains unaffected. But still, it's good practice to include only the libraries you actually need, unless it's some competitive competition ]
But in contests, using this file is a good idea, when you want to reduce the time wasted in doing chores; especially when your rank is time-sensitive.
It works in most online judges, programming contest environments, including ACM-ICPC (Sub-Regionals, Regionals, and World Finals) and many online judges.
The disadvantages of it are that it:
increases the compilation time.
uses an internal non-standard header file of the GNU C++ library, and so will not compile in MSVC, XCode, and many other compilers
That header file is not part of the C++ standard, is therefore non-portable, and should be avoided.
Moreover, even if there were some catch-all header in the standard, you would want to avoid it in lieu of specific headers, since the compiler has to actually read in and parse every included header (including recursively included headers) every single time that translation unit is compiled.
Unfortunately that approach is not portable C++ (so far).
All standard names are in namespace std and moreover you cannot know which names are NOT defined by including and header (in other words it's perfectly legal for an implementation to declare the name std::string directly or indirectly when using #include <vector>).
Despite this however you are required by the language to know and tell the compiler which standard header includes which part of the standard library. This is a source of portability bugs because if you forget for example #include <map> but use std::map it's possible that the program compiles anyway silently and without warnings on a specific version of a specific compiler, and you may get errors only later when porting to another compiler or version.
In my opinion there are no valid technical excuses that explain why this is necessary for the general user: the compiler binary could have all standard namespace built in and this could actually increase the performance even more than precompiled headers (e.g. using perfect hashing for lookups, removing standard headers parsing or loading/demarshalling and so on).
The use of standard headers simplifies the life of who builds compilers or standard libraries and that's all. It's not something to help users.
However this is the way the language is defined and you need to know which header defines which names so plan for some extra neurons to be burnt in pointless configurations to remember that (or try to find and IDE that automatically adds the standard headers you use and removes the ones you don't... a reasonable alternative).
This question already has answers here:
Why would I include iostream and ostream separately? [duplicate]
(2 answers)
Closed 6 years ago.
I saw some programs including <iostream> and <ostream> simultaneously. Why?
Thanks for your kind reply.
<iostream> is not the combination of <istream> and <ostream>. It merely defines std::cin, std::cout and related objects. To actually do anything useful with std::cout, you still need <ostream>. Now, by C++ rules it's possible that some implementations actually do include <ostream> in <iostream>, but you shouldn't rely on this.
Why? Probably because it originally included just ostream and someone figured out it had to use input streams as well. Then they just didn't bother to remove the ostream include.
Or maybe they actually needed the concrete cin/cout/cerr stream objects which are defined in iostream separately to the stuff in istream/ostream, and they didn't realise that iostream pulls in both istream and ostream before defining those objects.
Without asking the author, it's hard to say, but those are at least two viable possibilities.
Someone forgot to remove a header probably. You should always include only what you need in an implementation file but sometimes stuff gets left behind because people are lazy and/or don't know any better.
You should remove the one that is not needed.
I have been making several games with the Allegro API and C++. I have also been putting all my classes in 1 big main.cpp file. I tried many times to make .h and .cpp files, but my big problem is I have trouble with #including at the right place. For example, I want all my classes to access the allegro library without #including allegro.h everywhere. Could someone please explain how to correctly #include things. In .Net, everything seems to come together, but in c++ one thing cannot be used before it is included. Is there also a way to globally include something throughout my entire program?
Thanks
I want all my classes to access the allegro library without #including allegro.h everywhere.
Why? That is how you do it in C++ land.
Could someone please explain how to correctly #include things. In .Net, everything seems to come together, but in c++ one thing cannot be used before it is included
Conceptually, in .NET, it is not much different at all. You still have to place "using " at the top. The difference there is that, in .NET, you could also write this every time if you wanted to:
void Foo( System.Drawing.Drawing2D.BitmapData bData ) { }
A common way to do this is to have a master include file that includes all of the others in the correct order. This works especially well if you use precompiled headers so
in precomp.h
#include <stdio.h>
#include <allegro.h>
.. etc.
in myfile.cpp
#include "precomp.h"
in myfile2.cpp
#include "precomp.h"
and so on.