I'm asking about the best practice widely used in C++ projects. I need to have my own types in the project. It's a collection of couple of typedefs.
Is including header file containing the types good practice in C++ or is it better to use namespaces. If so, why? What are the pros and cons of the two ways?
Right now it looks like this:
types.h:
#ifndef TYPES_H
#define TYPES_H
#include <list>
// forward declaration
class Class;
typedef int TInt;
// ...
typedef std::list<Class> class_list;
#endif
class.h:
#ifndef CLASS_H
#define CLASS_H
#include "types.h"
class Class
{
public:
// ...
TInt getMethod();
private:
// ...
};
How would it look like with namespaces?
The two concepts are orthogonal; comparing them the way you ask makes no sense.
Unless you only use these types in a single file, you have to place them in a header so you can easily bring in their definitions when you need them. Then, within that header, you can include your namespace:
#ifndef TYPES_H
#define TYPES_H
#include <list>
namespace MyNamespace {
// forward declaration
class Class;
typedef int TInt;
// ...
typedef std::list<Class> class_list;
}
#endif
Then later you can do, for instance, MyNamespace::TInt rather than int after you #include "Types.h"
From a dependency point of view, naming all types in a single header is likely to be a maintenance nightmare. It's understandable for the typedef because you want a unique definition, but there is no reason to forward declare the class here.
// types.h
namespace myproject
{
typedef int TInt;
} // namespace myproject
There is no point in forward declaring the Class symbol: you pollute your own namespace. Let each file decide independently if they need the symbol or not and forward declare it on their own.
It's not pretty to declare ClassList either: it should only be available to those who need it. You could create a specific header for forward declaration of Class related stuff:
// class_fwd.h
namespace myproject
{
class Class;
typedef std::list<Class> ClassList;
} // namespace myproject
// class.h
#include "myproject/class_fwd.h"
namespace myproject
{
class Class {};
} // namespace myproject
Erm ... I think including the header file is fine. I'm not sure how namespaces attack this same problem at all ...
The main thing with any "best practice" like this is BE CONSISTENT.
Related
I am currently working on a project where we have a shared set of headers. Now we want add some private fields without having to put those declarations directly in the shared headers.
Someone brought up the following:
namespace something {
class Foo {
public:
Foo();
void doFoo();
private:
#if __has_include("foo_private.hpp")
#include "foo_private.hpp"
#endif
};
}
Inside the _private.hpp headers we would then place the private fields for that class. When there are only default datatypes (int, bool, etc) this works fine(ish). But as soon as you put an include inside the _private.hpp file, for example #include everything breaks.
It is giving the following error expected unqualified-id before ‘namespace’ which as I understand is quite logical, since you're trying to define a namespace inside of a class.
Example _private.hpp file
#ifndef DUMMY_PRIVATE_TEMPLATE_INCLUDES_FOO_PRIVATE_HPP
#define DUMMY_PRIVATE_TEMPLATE_INCLUDES_FOO_PRIVATE_HPP
#include <string>
int mySecretNumber;
std::string mySecretString;
#endif
Now my question is, is there any way to trick the preprocessor, or somehow get the same results with a different solution?
namespace something {
class Foo {
public:
Foo();
void doFoo();
private:
#if __has_include("foo_private.hpp")
#include "foo_private.hpp"
#endif
};
}
If that code is including a file that looks like this:
#ifndef DUMMY_PRIVATE_TEMPLATE_INCLUDES_FOO_PRIVATE_HPP
#define DUMMY_PRIVATE_TEMPLATE_INCLUDES_FOO_PRIVATE_HPP
#include <string>
int mySecretNumber;
std::string mySecretString;
#endif
Then you end up with this (though in reality, the #includes themselves would resolve to the contents of <string>, etc.):
namespace something {
class Foo {
public:
Foo();
void doFoo();
private:
#ifndef DUMMY_PRIVATE_TEMPLATE_INCLUDES_FOO_PRIVATE_HPP
#define DUMMY_PRIVATE_TEMPLATE_INCLUDES_FOO_PRIVATE_HPP
#include <string>
int mySecretNumber;
std::string mySecretString;
#endif
};
}
Perhaps that shows your issue? You're including "string" in the middle of your class, but it needs to be included at the global namespace scope of your file.
Instead, include string at the top of the outer header, don't use include guards in the private header, and only put the body of the code you want pasted into your class into that private header. For that reason, you might not call it a ".hpp" file but something else to make it clear it's not a normal header.
Additionally, the __has_include feature seems dubious, because if your private header is missing you probably do not want it to compile to an empty class.
Worse, if you compile some translation unit that finds the header, and then compile another translation unit that does not find the private header, you will end up with two different definitions of your class, violating the One Definition Rule -- which is undefined behavior, no diagnostic required. Really nasty stuff (assuming your builds succeeds at all.)
I'm not a big fan of this kind of hiding, as it will make it hard for editors to properly show your code, to colorize and index your private header, or otherwise work with the code in a normal way. You might consider looking at the PIMPL idiom for hiding the implementation of a class in its .cpp file, so users of the header do not have to see it at all.
I have a struct Tree that is defined inside Class Parser. I have methods defined in Parser that take Tree as input.
void Parser::InputTree(const Tree& input) {
//uses data from Tree
}
Everything seemed to be working fine. But then I needed to use Tree outside the class. So I decided to define struct Tree in a separate header. I included this header in the header file for Parser. While I see no errors in the header file of Parser, the source file shows errors on my Eclipse. Says member declaration not found pointing to method InputTree.
My question is, first off is this the right strategy to define a struct in a separate header? Second, what am I doing wrong? Third, I have some enum types also that I want to use across classes. Where do I define it?
Right structure:
parser.h
#ifndef _PARSER_H_
#define _PARSER_H_
#include "tree.h"
class Parser {
void InputTree(const Tree& input);
};
#endif /*_PARSER_H_*/
parser.cpp
#include "parser.h"
void Parser::InputTree(const Tree& input){
// use data from Tree
}
tree.h
#ifndef _TREE_H_
#define _TREE_H_
struct Tree {
//nodes
};
#endif /*_TREE_H_*/
Including parser.h includes tree.h and hence, struct Tree is available in the main compilation unit.
A simple rule of the thumb I usually follow, is if a custom datatype (i.e. struct, enum, etc.) is used only within a class, I end up defining this datatype within the definition of the class.
But if the same type is required to be used across 2 or more classes (without any parent-child relationship), I end up defining the type either within another header file and usually within a namespace (when the types or related in some fashion).
And yes you could use multiple such namespaces within multiple header files (to group related types), if you feel the need to distinguish them, but I've just show a simpler example using a single namespace:
/* MyNamespace.h */
#ifndef MY_NAMESPACE_H
#define MY_NAMESPACE_H
namespace MyNamespace {
struct Tree {
int a;
char b;
};
enum SomeEnum {
VALUE_0 = 0,
VALUE_1 = 1,
VALUE_2 = 2
};
}
#endif
/* Parser.h */
#ifndef PARSER_H
#define PARSER_H
#include "MyNamespace.h"
class Parser
{
public:
void InputTree(const MyNamespace::Tree& input);
};
#endif
/* Parser.cpp */
#include "Parser.h"
void Parser::InputTree(const MyNamespace::Tree& input)
{
}
Yes, it is a correct strategy to define the struct in a separate header file.
What you are doing wrong is hard to say without more input - but it probably has to do with includes, include-guards or namespace mismatches.
And finally, you should declare the enums in another header file, with proper include guards.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
reincluding header in implementation
What I am wondering is that it is common practice to not use using namespace xxx in a header file as not to pollute the global namespace.
How does this go for #includes?
If I have foo.h and foo.cpp.:
//Foo.h
#ifndef FOO_H_
#define FOO_H_
#include <string>
class Foo
{
public:
Foo(std::string * a, std::string * b);
virtual ~Foo();
};
#endif /* FOO_H_ */
//Foo.cpp
#include <string>
#include <Foo.h>
Foo::Foo(std::string * a, std::string * b)
{
// TODO Auto-generated constructor stub
}
Foo::~Foo()
{
// TODO Auto-generated destructor stub
}
Would I really need to #include <string> in both files? Would including it only in the .h or .cpp suffice? (I know both will work, but what is advisable?)
edit, a bit more background information regarding my question.
If I would be using certain classes in my header file (either as variables or method arguments) I would forward declare them in the header file and only include the header file itself in the source file. But this will not work for most STL libs because you can't forward declare class-templates?
... because you can't forward declare class-templates?
class templates can be forward declared - like non template classes:
// forward declaration
template <typename T>
class C;
However, as #AlexandreC stated in comments, for std::string it would be quite complicated, because std::string is typedef from template <typename,typename,typename> basic_string;.
I write it would be complicated, if it would be allowed. And it is not allowed, see:
http://www.gotw.ca/gotw/034.htm
https://stackoverflow.com/a/10290176/1463922
According to the C++11 standard, 17.6.4.2.1:
The behavior of a C++ program is undefined if it adds declarations or
definitions to namespace std or to a namespace within namespace std
unless otherwise specified.
So, no choice but include <string> in header file for std::string.
For your main question - I would include in source and header files, unless I was pretty sure it would be always included in header file and never removed...
I'm writing something in C++. I have 2 classes which I want to contain one into the other as in the folowing (these are just the header files):
//Timing.h
#ifndef _Timing_h
#define _Timing_h
#include "Agent.h"
class Timing{
private:
typedef struct Message{
Agent* _agent; //i get here a compilation problem
double _id;
} Message;
typedef struct MessageArr{
} MessageArr;
public:
Timing();
~Timing();
};
#endif
//Agent.h
#ifndef _Agent_h
#define _Agent_h
#include <string>
#include "Timing.h"
using namespace std;
class Agent{
public:
Agent(string agentName);
void SetNextAgent(Agent* nextAgent);
Agent* GetNextAgent();
void SendMessage(Agent* toAgent, double id);
void RecieveMessage(double val);
~Agent();
private:
string _agentName;
double _pID;
double _mID;
Agent* _nextAgent;
};
#endif
The compilation error is in the Timing.h file inside the definition of the struct:
expected ';' before '*' token
What am I doing wrong?
Try not to include "Agent.h" in Timing.h but include a forward reference instead:
#ifndef _Timing_h
#define _Timing_h
class Agent;
class Timing{
private:
typedef struct Message{
Agent* _agent; //I get here a compilation problem
double _id;
}Message;
typedef struct MessageArr{
}MessageArr;
public:
Timing();
~Timing();
};
#endif
You can include Agent.h in the timing.cpp file.
This way you remove the circular reference and you reduce the coupling between the classes.
Since you don't use the class Timing in your class Agent, you can remove this include as well (but this might be a copy mistake from your shortened example).
Basically - whenever you need either the size of an object or some of it's functionality, you must include its header file. If you don't need it (e.g. if you use only pointers to this object or references), you should not. This reduces compile time (especially for large projects)
For the 1 instance problem - check your favorite design patterns book (e.g. the GoF). The singleton pattern might be what you need.
Rule of thumb.
Do not include other header files from your header files if you don't need to.
Pre-Compiled header file stuff being a notable exception.
If your class only depends on a pointer or a reference you do not need the header file:
Use forward declaration in this situation.
In the source file include only the header files you need to make it work
Include them from most specific to least specific.
This will prevent the problem of hiding a dependency.
Other notes:
Do not use Underscore followed by a capitol letter.
This is reserved for the implementation. see
As in #define _Timing_h
Also note it is traditional that macros are all upper case.
Do not put using namespace X; in a header file
If you do this you pollute the namespace for everybody that uses your header file.
This is a real easy way to PO other developers who now have to re-factor their code to make sure it does not use any of a bunch of new classes/functions/templates that are suddenly being resolved against that was not there before.
So try this:
Timing.h
#ifndef TIMING_H
#define TIMING_H
class Agent;
class Timing{
// STUFF
};
#endif
Agent.h
#ifndef AGENT_H
#define AGENT_H
#include <string>
class Agent{
// STUFF
};
#endif
Timing.cpp
#include "Timing.h"
#include "Agent.h"
// STUFF
Agent.h
#include "Agent.h"
using std::string; // Bring as little as possable into the the global namespace.
// prefer to prefix all cases with std::
// STUFF.
You can't have circular includes.
Stop including "Timing.h" from "Agent.h", since it's not needed there.
Also, you don't need to have the "Agent.h" included in "Timing.h" either, just use a forward reference:
class Agent;
This makes it possible to have pointers to something called Agent.
You need to add the forward declaration of Agent in Timing.h
// Timing.h
#ifndef _Timing_h
#define _Timing_h
class Agent; // fwd declaration.
class Timing{
private:
typedef struct Message{
Agent* _agent; // without fwd decln Agent type is unknown here.
// rest all same.
EDIT:
As suggested by others, you should not be including Agent.h in Timing.h
//portl.cpp
namespace FAWN {
namespace Sys{
class PortListner {
....
Connecter::ConPtr _cur_con; - the main problem is here
...
//con.cpp
namespace FAWN {
namespace Sys {
class Connecter {
.....
public:
typedef boost::shared_ptr<Connecter> ConPtr;
...
Moreover, portl.cpp file is included into some other "main" sourse file. And this "other-main" file includes con.cpp too. So if I include con.cpp to portl.cpp - I define Connecter twice (in portl and in main). If I do not include it, compilator doesn't know what Connecter::ConPtr (or FAWN::sys::Connecter::ConPtr) means and try to use it as defenition of method.
Put the class Connecter (which you should probably rename to Connector) into a header file (.h instead of .cpp) and add include guards into the file. That is, at the beginning of your con.h file, add lines
#ifndef CON_H_INCLUDED
#define CON_H_INCLUDED
and at the very end, add the line
#endif
This way, even if you #include con.h twice, the second time it will not get read because the symbol CON_H_INCLUDED has been defined on the first time so the #ifndef-#endif pair hides the content.
This is the common way in C++: put class declarations in .h files that get #included in .cpp files that then actually define the functions.
Here is how it should look:
#ifndef PORTAL_H
#define PORTAL_H
#include "con.h"
//portl.h
namespace FAWN {
namespace Sys{
class PortListner {
....
//might need to specify Connector's namespace fully here
FAWN::Sys::Connecter::ConPtr _cur_con;
...
};
}
#endif //PORTAL_H
//con.h
#ifndef CON_H
#define CON_H
namespace FAWN {
namespace Sys {
class Connecter {
.....
public:
typedef boost::shared_ptr<Connecter> ConPtr;
};
}
#endif //CON_H