开发者

Complex circular dependency

开发者 https://www.devze.com 2023-02-18 16:31 出处:网络
what is the the best practice of solving circular dependency in C++? I could use the forward declaration, but then I get the pointer to incomplete class type is not allowed error. Does that mean that

what is the the best practice of solving circular dependency in C++?

I could use the forward declaration, but then I get the pointer to incomplete class type is not allowed error. Does that mean that two classes that uses each others pointer cannot be dependent?

Also, I thought about forward declaring each class and then including every header of the solutio开发者_如何学Cn in the main.cpp, so it's all in one place. Would you recommend it?

A snippet from the whole project is below, so you can refer to it if the issue is better explained on an example I'm familiar with, but it would do just to be theoretical. Thanks

Complex circular dependency


You just need to use forward declaration correctly:

  1. Put all code in cpp files
  2. Put just class declaration in header file
  3. In header file:
    1. Use forward declaration if you only use a pointer or a reference.
    2. Otherwise you to include header file. (Do Not add unrequired includes)
  4. In cpp file
    1. include all header files you require.

Note: Add include guards.

Its hard to actually do it without the actual declarations. The diagram is nice but does not have enough information. A picture may be worth a thousand words, but a precisely defined language can convey more exact information very compactly (unlike English and its inconsistencies).


One thought is to introduce interfaces and remove the circular dependencies. So you would have an IEffect that Effect, Player, and EffectContainer depend on. Possibly, if Player depends on certain behavior of Effect and EffectContainer depends on a different set of behavior, I would consider introducing two interfaces, effectively following the Interface Segregation Principle. This would also follow along with the Dependency Inversion Principle.


Generally this is implemented by having every header file pre-declare the classes that it needs before its #include. Additionally, no code should be put in the header files. So you end up with:

class Effect;
class Player;
class GameStack;

#include <vector>
// more includes

class EffectContainer { ... }

and the equivalent in each place. Then in your .cpp files you actually #include the headers for the other classes. This will work if your objects don't have a circular dependency on the memory layout of the other classes. Meaning that the methods and members can only refer to the other classes by reference or by pointer (but not by value). This can get a little squirrelly if you have things like

 class EffectContainer {
   std::Vector<Effect> effects;
 }

 class Effect {
   boost::shared_ptr<EffectContainer> parent;
 }

as the template expansion sometimes requires full types and not merely pre-declared types. One way many libraries avoid this issue is with a pointer to private impl pattern (often referred to as a PIMPL pattern), where every class is defined as:

class FooImpl;
class Foo {
  FooImpl* impl;
}

then the FooImpl is defined entirely in the .cpp file and your circularity issues can be ducked. This design is also valuable because it maintains binary compatibility across releases of your library. It does get a bit verbose, but nobody said C++ was a succinct language.

0

精彩评论

暂无评论...
验证码 换一张
取 消

关注公众号