In java we can import all class from a package using '*' like - java.lang.*.
While coding in C++ we imports multiple library like this -
#include<cstdio>
#include<iostream>
.....
Is there any shortcut/way in C++ to include all these library using a single statement/line?
Thanks
No, there is no method to specify more than one file in a #include preprocessor directive.
Many people get around this dilemma by creating a monster include file that has multiple #include statements:
monster_include.h
#ifndef MONSTER_H
#define MONSTER_H
#include <iostream>
#include <string>
#endif
The disadvantage is that if any of these include files are changed, including ones not used by the source file, the source file will still be rebuilt.
I recommend creating an empty stencil header file and an empty stencil source file, then adding #include as required. The stencil can be copied then filled in as appropriate. This will save more typing time than use the megalithic include file.
You can use this library:
#include<bits/stdc++.h>
This library includes every library you need. Using this, you can delete (or comment) all the others library declarations.
See more here: How does #include bits/stdc++.h work in C++?
There's nothing available for c++ like in your java sample.
Roll your own header to include all stuff you need.
E.g.
AllProjectHeaders.h
#ifndef ALLPROJECT_HEADERS
#define ALLPROJECT_HEADERS
#include<cstdio>
#include<iostream>
// ...
#endif
You might also want to take a look at precompiled headers, it should reduce the number of includes in the source files if there is something that you include everywhere.
Related
ALWAYS when I start a new class (EX: main.cpp) I need to
#include <iostream>
#include <string>
#include <math.h>
There is a way to make it automatically ? I mean every time when I create a new class they will already be included ?
A cpp file is not a class, it's a source file. A cpp file may include a class, or multiple classes, or no classes. Similar, a header filer is not a librarie, it's just a header file.
Add your includes to a header (.h file), and then your cpp file only has to include that single header to include all those common includes. Visual Studio even has something called a precompiled header, which is exactly meant as such a header with common includes, except that it's precompiled (which means, using that will compile faster than using a regular header). Afaik, you'll still have to include that single header yourself, tho, so you won't get around writing at least one #include ...
My solution is more a workaround than a "real" solution but : You need these lines at least once in your program.
So I'd create a headers_container.hpp file containing stuff my whole program needs, like these #include.
For example :
headers_container.hpp :
#include <iostream>
#include <string>
#include <math.h>
// Some stuff my whole program needs...
in your *.cpp files :
#include "headers_container.cpp"
// Your compiler knows iostream, std::strings and math now
Make sure the path to headers_container.hpp is correct (if the .hpp is not in the same folder as your .cpp
Using this method, you can add one #include in headers_container.hpp and it will update all the .cpp files.
Moreover you can write a small script to generate files (I did the script you can find here : https://gitlab.com/-/snippets/2033889 )
Enjoy your way in programming ! :)
I got a comprehension issue about precompiled headers, and the usage of the #include directive.
So I got my "stdafx.h" here and include there for example vector, iostream and string. The associated "stdafx.cpp" only includes the "stdafx.h", that's clear.
So if I design my own header file that uses for example "code" that's in vector or iostream, I have to include the header file because the compiler doesn't know the declarations at that time. So why are some posts here (include stdafx.h in header or source file?) saying, it's not good to include the "stdafx.h" in other header files even if this file includes the needed declarations of e.g. vectors? So basically it wouldn't matter to include directly a vector or the precompiled header file, both do the same thing.
I know of course, that I don't have to include a header file in another header file if the associated source file includes the needed header file, because the declarations are known at that time. Well, that only works if the header file is included somewhere.
So my question is: Should I avoid including the precompiled header file in any source file and why? And I am a bit confused, because I'm reading contradictory expressions on the web that I shouldn't include anything in header files anyway, or is it O.K. to include in header files?
So what's right now?
This will be a bit of a blanket statement with intent. The typical setup for PCH in a Visual Studio project follows this general design, and is worth reviewing. That said:
Design your header files as if there is no PCH master-header.
Never build include-order dependencies in your headers that you expect the including source files will fulfill prior to your headers.
The PCH master-header notwithstanding (I'll get to that in a moment), always include your custom headers before standard headers in your source files. This makes your custom header is more likely to be properly defined and not reliant on the including source file's previous inclusion of some standard header file.
Always set up appropriate include guards or pragmas to avoid multiple inclusion. They're critical for this to work correctly.
The PCH master-header is not to be included in your header files. When designing your headers, do so with the intent that everything needed (and only that which is needed) by the header to compile is included. If an including source file needs additional includes for its implementation, it can pull them in as needed after your header.
The following is an example of how I would setup a project that uses multiple standard headers in both the .h and .cpp files.
myobject.h
#ifndef MYAPP_MYOBJECT_H
#define MYAPP_MYOBJECT_H
// we're using std::map and std::string here, so..
#include <map>
#include <string>
class MyObject
{
// some code
private:
std::map<std::string, unsigned int> mymap;
};
#endif
Note the above header should compile in whatever .cpp it is included, with or without PCH being used. On to the source file...
myobject.cpp
// apart from myobject.h, we also need some other standard stuff...
#include "myobject.h"
#include <iostream>
#include <fstream>
#include <algorithm>
#include <numeric>
// code, etc...
Note myobject.h does not expect you to include something it relies on. It isn't using <iostream> or <algorithm>, etc. in the header; we're using it here.
That is a typical setup with no PCH. Now we add the PCH master
Adding the PCH Master Header
So how do we set up the PCH master-header to turbo-charge this thing? For the sake of this answer, I'm only dealing with pulling in standard headers and 3rd-party library headers that will not undergo change with the project development. You're not going to be editing <map> or <iostream> (and if you are, get your head examined). Anyway...
See this answer for how a PCH is typically configured in Visual Studio. It shows how one file (usually stdafx.cpp) is responsible for generating the PCH, the rest of your source files then use said-PCH by including stdafx.h.
Decide what goes in the PCH. As a general rule, that is how your PCH should be configured. Put non-volatile stuff in there, and leave the rest for the regular source includes. We're using a number of system headers, and those are going to be our choices for our PCH master.
Ensure each source file participating in the PCH turbo-mode is including the PCH master-header first, as described in the linked answer from (1).
So, first, the PCH master header:
stdafx.h
#ifndef MYAPP_STDAFX_H
#define MYAPP_STDAFX_H
// MS has other stuff here. keep what is needed
#include <algorithm>
#include <numeric>
#include <iostream>
#include <fstream>
#include <map>
#include <string>
#endif
Finally, the source files configured to use this then do this. The minimal change needed is:
UPDATED: myobject.cpp
#include "stdafx.h" // <=== only addition
#include "myobject.h"
#include <iostream>
#include <fstream>
#include <algorithm>
#include <numeric>
// code, etc...
Note I said minimal. In reality, none of those standard headers need appear in the .cpp anymore, as the PCH master is pulling them in. In other words, you can do this:
UPDATED: myobject.cpp
#include "stdafx.h"
#include "myobject.h"
// code, etc...
Whether you choose to or not is up to you. I prefer to keep them. Yes, it can lengthen the preprocessor phase for the source file as it pulls in the headers, runs into the include-guards, and throws everything away until the final #endif. If your platform supports #pragma once (and VS does) that becomes a near no-op.
But make no mistake: The most important part of all of this is the header myobject.h was not changed at all, and does not include, or know about, the PCH master header. It shouldn't have to, and should not be built so it has to.
Precompiled headers are a method to shorten the build time. The idea is that the compiler could "precompile" declarations and definitions in the header and not have to parse them again.
With the speed of todays computers, the precompilation is only significant for huge projects. These are projects with a minimum of over 50k lines of code. The definition of "signification" is usually tens of minutes to build.
There are many issues surrounding Microsoft's stdafx.h. In my experience, the effort and time spent with discovering and resolving the issues, makes this feature more of a hassle for smaller project sizes. I have my build set up so most of the time, I am compiling only a few files; the files that don't change are not compiled. Thus, I don't see any huge impact or benefit to the precompiled header.
When using the precompiled header feature, every .cpp file must begin by including the stdafx.h header. If it does not, a compiler error results. So there is no point in putting the include in some header file. That header file cannot be included unless the stdafx.h has already been included first.
I have added one framework in my project, where to get the callbacks of framework I need to implement c++ code,for which I have added c++ classes which are .mm from .cpp
as per suggestions given in this link
I also came across few posts of StackOverflow, where I found either I have to go for C++ or Objective C source type(as suggestion of few members).
I am looking to compile c++ code along with Objective C classes,but I am getting file not found error (compile time) for #include <cstdlib> and #include <string>
Please let me know any one worked around it.or faced same Issue.
Thanks In Advance!!!
I think problem is that your's .h-file, where you have added C++ includes is included in other .m-files, not just in .mm.
There is several ways to solve this problem:
Use C++ includes only in .mm files. (don't use them in .h)
Change all files, that import yours header to .mm
Include them in
#ifdef __cplusplus
#endif
block. Also use this block for methods where C++ classes mentioned.
For example:
#ifdef __cplusplus
#include <string>
using namespace std;
#endif
#interface SomeClass
#ifdef __cplusplus
- (void) setName:(const string&) name;
#endif
#end
Also there is way to avoid #ifdef #endif block by using extensions and categories:
declare C++'s instance variables only in extensions.
create categories with additional .h-file for methods and properties, that use C++'s types.
Recently, I encountered such approach of managing headers. Could not find much info on its problems on internet, so decided to ask here.
Imagine you have a program where you have main.c, and also other sources and headers like: person.c, person.h, settings.c, settings.h, maindialog.c, maindialog.h, othersource.c, othersource.h
sometimes settings.c might need person.c and main maindialog.c.
Sometimes some other source might need to include other source files.
Typically one would do inside settings.c:
//settings.c
#include "person.h"
#include "maindialog.h"
But, I encountered approach where one has global.h and inside it:
//global.h
//all headers we need
#include "person.h"
#include "maindialog.h"
#include "settings.h"
#include "otherdialog.h"
Now, from each other source file you only have to include "global.h"
and you are done, you get functionality from respective source files.
Does this approach with one global.h header has some real problems?
This is to please both pedantic purists and lazy minimalists. If all sub-headers are done the correct way there is no functional harm including them via global.h, only possible compile time increase.
Subheader would be somewhat like
#ifndef unique_token
#define unique_token
#pragma once
// the useful payload
#endif
If there are common headers that all the source files need, (like config.h) you can do so. (but use it like precompiled headers...)
But by including unnecessary headers, you actually increasing the compilation time. so if you have a really big project and for every source file you including all the headers, compilation time can be very long...
I suggest not include headers unless you must.
Even if you use type, but only for pointer or reference (especially in headers), prefer to use fwd declaration instead of include.
I understand what a header guard is but I never saw how it is used in bigger projects. I am currently writing an OpenGL abstraction layer and I mostly need to include the same files.
So my first naive approach was to do something like this:
#ifndef GUARD_H
#define GUARD_H
#include <glm/glm.hpp>
#include <glm/gtc/matrix_transform.hpp>
#include <glm/gtc/type_ptr.hpp>
#include <GL/glfw3.h>
#include <glload/gl_core.h>
#include <glload/gll.h>
#endif // GUARD_H
So I can just do #include "guard.h". But I realized that this is not a really good solution because what if I want to add a simple include?
Yes I probably could write all my includes in this file but I am also not sure if this is a good idea either.
How would you recommend me to structure my header guards? Can you recommend me any resources?
Update 1: small example
test.h
#ifndef TEST_H
#define TEST_H
#include <glm/glm.hpp>
class test{
};
#endif
test1.h
#ifndef TEST1_H
#define TEST1_H
#include <glm/glm.hpp>
class test1{
};
#endif
now I included glm in my test class. but what if I want to do something like this.
#include "test.h"
#include "test1.h"
int main(){
//...
}
Don't I include #include <glm/glm.hpp> 2 times in main?
It's not a good idea to put all your includes in one files, except if you always include all those file.
You should only include the strict minimum of required headers in your own headers and include the rest directly in your .cpp source files.
Each of your headers should have a unique header guard without conflict with any other library, so take a very good care of the naming scheme.
You may also consider using the non-standard #pragma once directive, if you're not writing portable code.
You could take a look at this paper about the best practice for designing header files
To answer your edit :
No you don't include <glm/glm.hpp> twice, because it has itself a header guard. But you should include it only if you actually need glm.hpp inside your header, otherwise you should include it later. Note that you can often avoid the include by forward-declaring what you need, that could speed-up the compilation and avoid circular dependency, but that's another issue.
Simple. Header guards in every single header.
The way you've done it is unsafe : What if one day someone (not necessarily you, though even this is unsure) includes directly one of the headers you listed (though these are mostly external libs it seems, but it could evolve to include one of yours...), and this header doesn't have include guards ? Might as well exclude this possible issue ASAP !
To structure your headers, you should prefer to include what is strictly needed rather than everything in one global header.
Edit answer : No you won't include it twice. After the first include, every extra occurrence of the header guarded file will simply be ignored.