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.
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<>.
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 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.
I have common code on multiple platforms that relies on a header with certain function names to be #included.
The problem is that the [more or less] same header has different names on each platform. I cannot simply rename the header on any platform as it's a standard #include. What is the recommended way to keep this common?
Macros
#ifdef PLATFORM_A
#include <platformA>
#endif
#ifdef PLATFORM_B
#include <platformB>
#endif
//....
Header Masking
In common code:
#include "common.h"
Platform A's "common.h":
#include <platformA>
Platform B's "common.h":
#include <platformB>
Or something else?
What are the pros/cons associated with each method, and in what instances should I use one over another?
Actually, I'd combine both approaches. Instead of using method A over and over again in your code, making maintenance difficult, you should add one common header for each header which is platform dependent and use it to wrap the platform-specific includes:
common_iostream.hpp:
#ifndef COMMON_IOSTREAM_INC
#define COMMON_IOSTREAM_INC
#ifdef PLATFORM_A
#include <iostream>
#endif
#ifdef PLATFORM_B
#include <iostream.h>
#endif
#endif
That way you have a nice set of common_*.hpp headers and your code is kept clean, plus you don't have it split into different platformA/common.hpp, platformB/common.hpp, etc.
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.