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<>.
Related
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.
I am trying to move a few tests into the XCTest target of my application in Xcode. The library I am testing functionalities for is large, and I include its header files inside my tests.mm file (my Obj-C++ testing file where all unit test cases are).
For one specific "Size" type, Compiler reports a series of ambiguous clashes with the Size type already defined as part of the SDK for MacOS10.13 (in /usr/include). Here is how the #include set for my testing file looks like:
#import <XCTest/XCTest.h>
#include <ql/quantlib.hpp>. <---- defines Size, which clashes with MacTypes.h definition
#include <Analytics/all.hpp>
#include <boost/timer.hpp>
#include <utility>
#include <typeinfo>
#include <thread>
#include <atomic>
#include <mutex>
#include <random>
#include <condition_variable>
#include <future>
using namespace src::Utilities;
using namespace src::Simulation;
using namespace src::MarketData;
using namespace src::detail;
using namespace std::placeholders;
//...More code down here, but not problematic
is the file which contains the definition for Size. Can someone please help spot where I may have gone wrong, especially that when I run the tests as part of a giant Main() function, it all works fine.
Thanks,
Amine
Update: After some research, I think I found what was going on with this issue: "using namespace xxxx" inside Objective-C++ testing framework instead of fully qualifying the data types with xxxx:: clashes with native Apple API types (Size, Handle, ptr, etc...). Full namespace qualification of C++ data types is required in this case to avoid ambiguity.
I have defined a class Executer splited in Executer.hpp and Executer.cpp.
In Executer.hpp there is the code:
static std::unique_ptr<Executer> mInstance;
static std::once_flag mOnceFlag;
In Executer.cpp there is the code:
std::unique_ptr<Executer> Executer::mInstance;
std::once_flag Executer::mOnceFlag; // without this apparently
// useless line of code, the program using this shared lib
// claims: undefined reference to `Executer::mOnceFlag'
After that I try to let eclipse organize my imports.
What I get is:
//------------------------------- Executer.hpp
#include <memory>
#include <stdexcept>
#include <string>
namespace std {
struct once_flag;
} /* namespace std */
//------------------------------- Executer.cpp
#include "Executer.hpp"
#include <mutex>
What I expect (and also is compiled correctly):
//------------------------------- Executer.hpp
#include <memory>
#include <mutex>
#include <stdexcept>
#include <string>
//------------------------------- Executer.cpp
#include "Executer.hpp"
Why is Eclipse behaving in that way?
Can I configure Eclipse in such a way that I get my way of organizing the includes (I have seen the many options, but I got things worst)
Why is Eclipse behaving in that way?
The type of a static data member is not required to be complete at the point of the data member's declaration. That is, the declaration will compile with the type having been just forward-declared, not defined.
The default settings for "Organize Includes" try to minimize the number of headers that are included in other headers, to speed up compile times, so when a forward declaration of a type is sufficient, it prefers to create one rather than to include the header than defines the type.
Can I configure Eclipse in such a way that I get my way of organizing the includes (I have seen the many options, but I got things worst)
Unchecking Forward declare classes, structs and unions in Preferences | C/C++ | Code Style | Organize Includes should give you the behaviour you desire.
I actually answered my own question, which is what led to this question. All I was doing was trying to instantiate my Hands class in another file. I had many other classes being instantiated no problem. Except with my Hands instance it said that I was missing a type specifier, and said I was missing a ";" when I wasn't.
I was literally copying + pasting code from my Hands.h file to paste in a SO question, when I realized that my Hands.h class was the ONLY class that I was #include-ing from my State.h. (In my State.h I am #include-ing almost all classes). So I looked at every other .h file that I was instantiating from in my State.h, when I realized the only one was Hands.h. So I figured I would try to take out the #include State.h from my Hands.h and see what happens, and my errors go away. I'm just wondering why the hell that would matter if I was #include-ing Hands.h from State.h, and State.h from Hands.h
Hands.h
#include "Aesthetics.h"
#include "GamePlay.h"
#include "Checks.h"
#include "Poker.h"
#include "Deck.h"
#include "DrawCard.h"
//#include "State.h //<--- what I commented out, and it worked
State.h
#include "Hands.h"
#include "Aesthetics.h"
#include "GamePlay.h"
#include "Checks.h"
#include "Poker.h"
#include "Deck.h"
#include "DrawCard.h"
You have two way to handle this issue:
1) Add some preprocessor lines to avoid multiple include of same header:
#ifndef __HANDS_H__
#define __HANDS_H__
// here your code
#endif
and similar for State.h
2) Add a pragma directive on top of your headers:
#pragma once
The second one is not part of the c++ standard but is implemented in many compilers (gcc, vs, llvm).
I hope this can help you.
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.