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:
scoped_ptr or unique_ptr. If the pointer is merely a reference to an object, then it could be necessary to use an Observer pattern so that it's "unset" whenever the referenced object is destroyed. –
Wharfinger auto_ptr which is better when you don't want to be dependent on boost or C++0x). But I rather wanted to show general idea rather live code. It may even be std::vector<foo> which would work if foo has forward declaration. –
Kathrynkathryne auto_ptr, it's worse. scrap off the code of scoped_ptr from boost if you need to, but auto_ptr brings too many surprises (on copy / assign). –
Wharfinger scoped_ptr most of the time (of course you should be aware of its move semantics that is very nice when you know how to use it). –
Kathrynkathryne scoped_ptr out of boost (or even reimplement it yourself, it's quite easy... just beware of exceptions ^^) and you'll have a noncopyable smart pointer. –
Wharfinger auto_ptr it was fine and it is sill fine. And in some cases it is very good to define move policy like returning auto_ptr from function. It was deprecated in flavor of unique_ptr only because C++0x ans rvalue reference which does not exists in C++98 and allows to do things safer. Also please note, the standard had not accepted scoped_ptr in it. –
Kathrynkathryne auto_ptr because of its screwed concept of "copy", which is usually surprising... I know that we "needed" it somewhat for returning pointers from factory, but whenever a copy is not necessary, or not wanted. scoped_ptr is better in this regard, for C++03; it's also completely unnecessary once you get a unique_ptr :) –
Wharfinger #include "myclass.h" the first include in myclass.cpp.Some best practices I follow to avoid circular dependencies are,
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/
© 2022 - 2024 — McMap. All rights reserved.