Due to the implementation of a template class in a header file, I have to include the other includes used in the implementation of the class in the header file.
Because of that, each time I include my template class that bring all other the inclusions and so on.
This could bring to an eccessive spread of inclusion, or even unnecessary for the context.
So what's the best way to deal with this issue?
Edit: Since I've not explictely mentioned it, I'm not talking about cases where forward declaration could solve it like in a normal .h/.cpp separation, but when you have to include the header, and since you don't have the cpp, you are force to use it in .h
Edit 2: Let's say my template class has a function with a dependency with a third class library. Each class using my template class now has the same depency, or can access to that header which both I could not want to. Does it exists a way to avoid that?
Use forward declaration where ever appropriate instead of #include.
Header file should #include only the needed and rest should go in source file.
Related
This question already has answers here:
Resolve build errors due to circular dependency amongst classes
(12 answers)
Closed 9 years ago.
Do you have any good advice on how to avoid circular dependencies of header files, please?
Of course, from the beginning, I try to design the project as transparent as possible. However, as more and more features and classes are added, and the project gets less transparent, circular dependencies start happening.
Are there any general, verified, and working rules? Thanks.
If you have circular dependency then you doing something wrong.
As for example:
foo.h
-----
class foo {
public:
bar b;
};
bar.h
-----
class bar {
public:
foo f;
};
Is illegal you probably want:
foo.h
-----
class bar; // forward declaration
class foo {
...
bar *b;
...
};
bar.h
-----
class foo; // forward declaration
class bar {
...
foo *f;
...
};
And this is ok.
General rules:
Make sure each header can be included on its own.
If you can use forward declarations use them!
Use forward declarations where possible.
Move any header includes out of a header file and into the corresponding cpp file if they are only needed by the cpp file. Easiest way to enforce this is to make the #include "myclass.h" the first include in myclass.cpp.
Introducing interfaces at the point of interaction between separate classes can help reduce dependencies.
Some best practices I follow to avoid circular dependencies are,
Stick to OOAD principles. Don't include a header file, unless the class included is in composition relationship with the current class. Use forward declaration instead.
Design abstract classes to act as interfaces for two classes. Make the interaction of the classes through that interface.
A general approach is to factor out the commonalities into a third header file which is then referenced by the two original header files.
See also Circular Dependency Best Practice
depending on your preprocessor capabilities:
#pragma once
or
#ifndef MY_HEADER_H
#define MY_HEADER_H
your header file
#endif
If you find it very boring to design header files maybe makeheaders from Hwaci (designers of SQLite and fossil DVCS) could be of interest for you.
What you're aiming at is a layered approach. You can define layers where modules can depend on lower layer modules but the inverse should be done with observers. Now you can still define how fine-grained your layers should be and whether you accept circular dependency within layers, but in this case I would use this.
In general header files should forwardly declare rather than include other headers wherever possible.
Also ensure you stick to one class per header.
Then you almost certainly will not go wrong.
The worst coupling usually comes from bloated template code. Because you have to include the definition inside the header, it often leads to all kinds headers having to be included, and then the class that uses the template includes the template header, including a load of other stuff.
For this reason, I would generally say: be careful with templates! Ideally a template should not have to include anything in its implementation code.
Altough Artyom provided best answer this tutorial is also great and provides some extenstions http://www.cplusplus.com/forum/articles/10627/
Currently the template functions are inside the .cpp file, however these templates need to be defined in the header. However, when I move them in to the header, the templates have no access to the static methods inside the .cpp file. What changes do I need for this to work?
This is just a utility header and cpp, nothing to do with classes.
I would just go ahead and put declarations of all needed functions in a header file (and remove the static from their definitions). If you put them in namespace FunctionName_impl_detail or something like that, you're safe from name collisions. If you put comments near the declarations discouraging using them directly, you probably don't need to "hide" or "protect" them. But if you want to mostly prevent other code from using them, you can make them private, static members of some class which friends the template functions.
You should define the static method in the header.
Template classes have to be defined entirely in the header file because the compiler basically creates a new class for each template instantiation, so it has to have access to the full method implementation at compilation time.
I have different classes all arranged in a hierarchy.
To reduce the amount of code, I started creating template functions. The base class will use the template functions and some of the derived classes will also use the same functions. Where am I suppose to put all of these templates so I don't get undefined reference issues like I have been? Should I put all the definitions in a header file and then just include that header files in the .cpp part of the class that call the functions. will that work? As of right now, all of my classes(class.cpp, class.h) compile fine, but everything blows up during the linking. I tried to put all the templates in a namespace and then include that namespace in the implementation of all my classes but that doesn't seem to work. My question is, how would you go about making a separate entity that just holds templated functions that any class can use on it's data members?
The definitions of template functions and template classes belong in header files, not .cpp files.
This is because the compiler essentially has to generate a brand new function for each set of template parameters that's used in the file that #includes the header. If the template function were defined in a .cpp file, then all of the appropriate versions of these functions would have to be generated without knowing what the calling code looks like, and that's basically impossible. (You do get duplicate definitions of template functions this way, but the linker removes those and makes sure there's only one copy if each template instantiation in the final binary.)
I see a lot of people confused by this thing... templates are not types.
They become types when instantiated.
For this reason members of templates must stay in the same data unit you are going to use them.
If you template is generic and you want to use it in all your code, just put everything in header files.
Now, if you don't like (and i would understand that) that you show declarations and definitions and implementation all in the same file, you can split templates in two different files.
For example, "list.h" with your declaration and "list.inc" with your implementation.
To make it work, you have to include both.
This question already has answers here:
Resolve build errors due to circular dependency amongst classes
(12 answers)
Closed 9 years ago.
Do you have any good advice on how to avoid circular dependencies of header files, please?
Of course, from the beginning, I try to design the project as transparent as possible. However, as more and more features and classes are added, and the project gets less transparent, circular dependencies start happening.
Are there any general, verified, and working rules? Thanks.
If you have circular dependency then you doing something wrong.
As for example:
foo.h
-----
class foo {
public:
bar b;
};
bar.h
-----
class bar {
public:
foo f;
};
Is illegal you probably want:
foo.h
-----
class bar; // forward declaration
class foo {
...
bar *b;
...
};
bar.h
-----
class foo; // forward declaration
class bar {
...
foo *f;
...
};
And this is ok.
General rules:
Make sure each header can be included on its own.
If you can use forward declarations use them!
Use forward declarations where possible.
Move any header includes out of a header file and into the corresponding cpp file if they are only needed by the cpp file. Easiest way to enforce this is to make the #include "myclass.h" the first include in myclass.cpp.
Introducing interfaces at the point of interaction between separate classes can help reduce dependencies.
Some best practices I follow to avoid circular dependencies are,
Stick to OOAD principles. Don't include a header file, unless the class included is in composition relationship with the current class. Use forward declaration instead.
Design abstract classes to act as interfaces for two classes. Make the interaction of the classes through that interface.
A general approach is to factor out the commonalities into a third header file which is then referenced by the two original header files.
See also Circular Dependency Best Practice
depending on your preprocessor capabilities:
#pragma once
or
#ifndef MY_HEADER_H
#define MY_HEADER_H
your header file
#endif
If you find it very boring to design header files maybe makeheaders from Hwaci (designers of SQLite and fossil DVCS) could be of interest for you.
What you're aiming at is a layered approach. You can define layers where modules can depend on lower layer modules but the inverse should be done with observers. Now you can still define how fine-grained your layers should be and whether you accept circular dependency within layers, but in this case I would use this.
In general header files should forwardly declare rather than include other headers wherever possible.
Also ensure you stick to one class per header.
Then you almost certainly will not go wrong.
The worst coupling usually comes from bloated template code. Because you have to include the definition inside the header, it often leads to all kinds headers having to be included, and then the class that uses the template includes the template header, including a load of other stuff.
For this reason, I would generally say: be careful with templates! Ideally a template should not have to include anything in its implementation code.
Altough Artyom provided best answer this tutorial is also great and provides some extenstions http://www.cplusplus.com/forum/articles/10627/
I am completely confused as to the proper way to layout a C++ project.
I had all my classes in separate .cpp files, with their definitions in .h files. I then had one "header.h" which contained all the class headers, external dependencies and a few other things. But I wasn't able to use class names in the header files, where I needed to declare a pointer to one.
Can someone please explain the proper object-orientated layout for a C++ project.
You can fix the problem "wasn't able to use class names in the header files, where I needed to declare a pointer to one" by using forward class declarations, like:
class myClass;
However, having every class include a header.h that then includes every class is overkill. Instead, you should have each class specifically include only the classes and external dependencies that it actually needs.