Is there any expression possible for the syntax to include multiple headers at once, with no need to write the "#include"-expression for each file new?
Like, for example:
#include <stdio.h>, <stdlib.h>, <curses.h>, <string.h> /* Dummy-Expression 1. */
OR
#include <stdio.h> <stdlib.h> <curses.h> <string.h> /* Dummy-Expression 2. */
Question is for C AND C++.
No, there is no way to do this. You have to type out (or copy) each #include to its own line, like this:
#include <stdio.h>
#include <stdlib.h>
#include <curses.h>
#include <string.h>
This applies to both C and C++.
Some of the other answers discuss creating another header file that includes each of these, but I'm not going to discuss doing that. It in general is a bad idea and causes issues like namespace pollution and the need to recompile when you change that header file.
No, there is not.
Write an #include directive for each inclusion operation you wish to perform.
You could, however, have a "utility" header that does nothing but include many other headers that you use frequently. Then you just include that one utility header. Whether this is a good idea or not, is a matter of opinion.
If you go down that route, don't be tempted to start relying on internal implementation headers.
It can be done with a help of auxillary header including header:
#define HEADERS (<stdio.h>)(<stdlib.h>)(<curses.h>)(<string.h>)
#include "Headers.inl"
Where Headers.inl performs include for each item in HEADERS sequence:
// Headers.inl
#include <boost/preprocessor/seq.hpp>
#if(0 < BOOST_PP_SEQ_SIZE(HEADERS))
#include BOOST_PP_SEQ_ELEM(0, HEADERS)
#endif
#if(1 < BOOST_PP_SEQ_SIZE(HEADERS))
#include BOOST_PP_SEQ_ELEM(1, HEADERS)
#endif
#if(2 < BOOST_PP_SEQ_SIZE(HEADERS))
#include BOOST_PP_SEQ_ELEM(2, HEADERS)
#endif
#if(3 < BOOST_PP_SEQ_SIZE(HEADERS))
#include BOOST_PP_SEQ_ELEM(3, HEADERS)
#endif
…
It can probably be simplified by letting boost preprocessor handle the all the repetition with BOOST_PP_SEQ_POP_FRONT and recursive include of itself.
You can make a header file with all the common includes and include that in your files:
File common.h:
#include <stdio.h>
#include <stdlib.h>
#include <curses.h>
#include <string.h>
and in your file you can include that file instead:
#include <common.h>
There's no syntax for that. But if you really want something like that, then just create a new header that contains nothing but multiple #include statements for the headers you want and then #include "combo-header.h" whenever needed.
I'd discourage this though. Better to only include what you use explicitly where you use it - for several reasons; compile time and namespace pollution being the top ones.
Yes, you can use #include<bits/stdc++.h>
This header file includes all the standard header files. The only problem is, it would include a lot of unnecessary files which you don't require for a program, and also, since it includes a lot of header files your compilation time will increase.
If there are some particular headers you use quite often in a program then you can make a header file of your own and include the required files in the one you created.
Related
This question is pretty weird.
Say I have a file, called idiot.cpp, and it begins with:
#include <boost/property_tree/ptree.hpp>
#include <boost/property_tree/xml_parser.hpp>
#include <string>
#include <set>
#include <exception>
#include <iostream>
#include "idiot.h"
and I have a header file, idiot.h. First of all, in idiot.h, do I also have to insert
#include <boost/property_tree/ptree.hpp>
#include <boost/property_tree/xml_parser.hpp>
#include <string>
#include <set>
#include <exception>
#include <iostream>
or do I not?
Second, if I have another source file, say, "bonito.cpp," that uses idiot.h, should I just #include "idiot.h", or should I paste in the code snippet again?
If not, is there any way to shorten this so I don't end up including around 20 headers per file? (hypothetically)
Sorry if this is a pretty dumb question, but I don't use many headers too often.
idiot.cpp does not need to include anything included indirectly by idiot.h to be able to compile.
The more interesting case: bonito.cpp #includes idiot.h and idiot.h includes x.h. If idiot.h only uses the content of x.h for private or anonymous namespace code - and bonito.cpp wants to use something from x.h too, then bonito.cpp should include x.h directly (redundantly).
The justification is simple: idiot.h can't remove something from the public/protected interface without risking breaking client code, so if that happens then the clients have to expect to deal with it - possibly including an extra header too. BUT, the maintainer of idiot.h and idiot.cpp should be free to change private or anonymous namespace content within idiot.h without risking breaking client code, including which headers are included to support that private code.
So, the inclusion is redundant at the time it's done, but that's done in the expectation that it might stop being redundant as idiot.h evolves.
This best-practice model is not automatically enforced - you have to understand the way this should work and actively code to that model.
Example
If idiot.h contains...
#include <string>
#include <vector>
...
class X {
void add(const std::string&);
private:
std::vector<std::string> v_;
};
...then bonito.cpp can reasonably use std::string without including <string>, but should include <vector> itself if it needs std::vector<>.
What is the best location for a file include in C++? For example:
/*Foo.h*/
#include <string> //Should I place this between the #ifndef #endif?
#include "FooBar.h"
using namespace std;
#ifndef Foo_class
#define Foo_class
class Foo
{
/*XXX*/
}
#endif
/*FooBar.h*/
#ifndef FooBar_class
#define FooBar_class
class FooBar
{
/*XXX*/
}
#endif
/*Foo.cpp*/
#include "Foo.h"
/*XXX*/
/*FooBar.cpp*/
#include "FooBar.h"
/*XXX*/
Should I place the include between the define so that it only gets included when needed? Does it have impact to the system when you don't do that?
Generally, system header files do have protection against erroneous over-including, so this really doesn't matter.
#ifndef Foo_class
#define Foo_class
This pair should always be the first pair of lines of any .h file.
If you are including other .h files or library files which are include guarded, it may not matter, but a good habit nonetheless.
Another good habit, avoid using namespace std; in headers.
Library header files already contain their own #ifdef's so everything is resolved if included in multiple files. So it doesnt matter where you put it.
The best place is at the top.
Only do things different from other people when there is a technical reason to do so.
In this case:
- There is no technical difference between the two, as other answers have pointed out.
- All code I've encountered puts the include guards at the top. Although sometimes they are after the copyright notice, the guards are never after other #includes.
Therefore: put it at the top.
In most cases, it makes no real difference, as long as the inner included file has include guards. Put it where you think makes the most sense!
However, there is a reason for the convention of putting it inside the #ifndef GUARD and that is, when files take a long time load (e.g. they are on a heavily loaded network drive, or on a slow disk), in a large project, the same header file may be included many times in the same project
Let's say we have a "common.h":
#include <iostream>
#include "lesser_common.h"
#include "not_so_common.h"
#ifndef COMMON_H
#define COMMON_H
... stuff goes here ...
#endif
in main.c, we have
#include <iostream>
#incldue "common.h"
#include "myheader1.h"
#include "myheader2.h"
#include "myheader3.h"
Where myheader{1,2,3}.h also include common.h.
Now in theory, the preprocessor will have to read through all of common.h four times, and iostream 5 times. If we move the include guard out, so that when common.h is included, it doesn't include other files, at least we save the three reads of iostream. For a large project, with a huge number of files that include a large number of other files [particularly if you subscribe to the principle of "you shouldn't have to include some other file before using this one"], this can add up to quite a bit of file-reading. It shouldn't be your main choice of how/where you arrange files, but keeping it in mind a little bit is a good idea.
Having said that, most preprocessors are "clever", and understand if the file has include guards at top and bottom the first time around, it doesn't need to read the header the next time.
Also, not including files into your header files unless it's acutally needed is a very good idea - same applies for source files, of course.
I'm working on a C++ project.
I had a class with its function, then I realized some of those functions weren't related to that class but were just math functions so I decided to move them on to a namespace.
My first question is, what is the appropriate file extension for a c++ namespace?
I have a constants.h file where I plan on saving global constants, for example PI.
Right now:
#include <math.h>
const double PI = M_PI;
I have the namespace I talked about before, right now is called: specificMath.h
#include <stdlib.h>
#include "constants.h"
... more code
I have a gaussian.cpp:
#include "gaussian.h"
#include "specificMath.h"
#include <iostream>
... more code
This file includes a main function that right now does nothing, I just can't get the whole project to compile without a main...
I have a gaussian.h where I'm not including anything, is that wrong?
A third class, which has no attributes, just methods (again, is this wrong? or not pretty?). truncatedFunctions.cpp
#include "specificMath.h"
#include <stdlib.h>
#include "truncatedFunctions.h"
#include "gaussian.h"
using namespace specificMath;
And its truncatedFunctions.h where, again, I'm not including anything.
And a fourth class where I include
#include "margin.h" //Its header, where I'm not including anything
#include "gaussian.h"
#include "specificMath.h"
using namespace specificMath;
When I "make" it, it seems to compile fine, but when it gets to the linking part I get A LOT of errors saying that things on my margin.cpp class were first defined in truncatedFunctions.cpp
I am going crazy. I have no idea why this is happening, or how to solve it. I would really appreciate if somebody could help me out, and please, any extra piece of advice would be great since I am really trying to learn as much as I can with this project. Thanks!
When I "make" it, it seems to compile fine, but when it gets to the linking part I get A LOT of errors saying that things on my margin.cpp class were first defined in truncatedFunctions.cpp
Did you define your functions in your specificMath.h? You should only declare those functions.
For example, if your specificMath.h contains function definitions like
#ifndef COOL_STUFF_NSPC
#define COOL_STUFF_NSPC
#include <iostream>
namespace coolstuff{
void print(void){std::cout << "I'm declared in a header file." << std::endl;
}
#endif
and you are using including this file in several others, the linker is going crazy. Including means copying. And so you've got yourself coolstuff::print defined several times. The better way (and the only possible way when using self-written functions in many files) is splitting your code into a header and implementation as you did in gaussian.
// coolstuff.namepace.h
#ifndef COOL_STUFF_NSPC
#define COOL_STUFF_NSPC
namespace coolstuff{
void print(void);
}
#endif
When you include coolstuff.namespace.h it will only declare functions. And you can declare the same function several times.
// coolstuff.namespace.cpp
#include <iostream>
#include "cs.h"
void coolstuff::print(void){
std::cout << "Hello world!" << std::endl;
}
The .cpp file contains the implementation of your functions. Now your linker won't get irritated because there is only one implementation of coolstuff::print and not n (where n is the number of #include "cs.namespace.h" you used) ones.
My first question is, what is the appropriate file extension for a c++ namespace?
There is no standard namespace extension. Use .h/.cpp for header/implementation and a self-defined prefix, something like 'nmspc' or 'nsc'. It's up to you.
It's hard to tell whether you've done anything wrong in your code (because you didn't show any of it), but the first thing to try is to "clean" your build and rebuild all your code. If the compiler (don't know what you're using) for some reason didn't compile all your modified modules, then it's not surprising that the linker is having trouble.
My first question is, what is the appropriate file extension for a c++ namespace?
In C++, header files are usually .h or .hpp. It doesn't matter to the compiler.
#include "gaussian.h"
#include "specificMath.h"
#include <iostream>
In general, it's a good idea to #include stuff from the standard library first, followed by your own things.
I have a gaussian.h where I'm not including anything, is that wrong?
No. If you don't need to include anything, don't include anything.
First, use include guards for the headers.
#ifndef MYHEADER_H
#define MYHEADER_H
//header contents
#endif
This will prevent the same header from being included twice in the same translation unit.
Second, don't define uncosnt stuff in the headers:
double x = 0;
this will cause all translation units to export that symbol.
Declare the variable extern in your header and provide a definition for it in an implementation file.
I'm using a custom library in a c++ project, witch includes several std headers, but when i include the corresponding header in the main file, it's like i included all the headers in the custom one.
To be clear:
custom header file:
#ifndef CUSTOM_H
#define CUSTOM_H
#include <vector>
//stuff
#endif
Main.cpp:
#include <iostream>
#include "custom.h"
//here, let suppose that i do next:
vector<int> vec;
return 0;
there's no compile error, like the vector header is included, i want to avoid that, any suggestion
If custom.h's use of std::vector is an implementation detail (and not exposed in the signatures of things you define in the header), consider moving the #include <vector> to the corresponding custom.cpp file instead.
If you can't move the include out of custom.h because, say, you pass a vector in or out of a method, then it truly is part of your interface and clients of your header will need to know about it.
It is possible, but this shouldn't be done without consideration because it gives meaning to the order in which you include files, that is, you will or won't be able to compile depending on what order your #includes are in. It is generally desirable to avoid that situation.
To accomplish that, remove #include <vector> from the .h and add it to Main.cpp above where you include the custom header file. If you #include it below that, it will complain about types being undefined. Also in every file that uses the custom header file, they will have to #include <vector> first.
The problem is nearly unavoidable. If your header file needs to include another for any reason whatsoever, there's no way to "uninclude" it later.
There's one technique that can minimize the problem, the pimpl idiom or opaque pointer. By moving the implementation of a class into a private source file, you eliminate the dependencies that caused you to include the header in the first place.
If I have multiple class and I want to have them all come under the same namespace and in my project I just want to have one include and that will give me all of the classes how would I go about doing this? I have played around with this but keep hitting a dead end.
Thanks in advance.
If you want only one include, namespaces have nothing to do with this.
You can create a file that only contains #include statements.
Something like this:
//classes file
#include "classA"
#include "classB"
#include "classC"
And the include all of them with only one include
#include "classes"
A real example can be found in the STL.
Take vector for instance:
#ifndef _GLIBCXX_VECTOR
#define _GLIBCXX_VECTOR 1
#pragma GCC system_header
#include <bits/stl_algobase.h>
#include <bits/allocator.h>
#include <bits/stl_construct.h>
#include <bits/stl_uninitialized.h>
#include <bits/stl_vector.h>
#include <bits/stl_bvector.h>
#ifndef _GLIBCXX_EXPORT_TEMPLATE
# include <bits/vector.tcc>
#endif
#ifdef _GLIBCXX_DEBUG
# include <debug/vector>
#endif
#endif /* _GLIBCXX_VECTOR */
You get all of this by just doing #include <vector>
Namespaces and header files are unrelated. If you want to provide a single header file for inclusion you can either go with Tom's advice of adding a 'include-all' header or you can pack all your headers into a single file (this might be a bad idea unless the codebase is really stable, as a change in a single element will force recompiling everything). Anyway you can use different namespaces within the same header:
#ifndef HEADER_GUARD_H_
#define HEADER_GUARD_H_
namespace A {
class TheA {};
}
namespace B {
class TheB {};
}
namespace A { // you can even reopen the namespace
class AnotherA {};
}
#endif
Note that the difference is the packaging: whether you need to ship one or more files... in Tom's answer the preprocessor will generate a file similar to the manually generated header before passing the contents to the compiler.