这在多大程度上是一种不好的做法? [循环依赖]

reum 发布于 2019-03-09 c++ 最后更新 2019-03-09 14:37 0 浏览

(首先,对我的英语感到抱歉) 为了避免循环依赖的语法限制,我想知道下面提出的解决方案是否真的是一个解决方案,或者它是否比adventage有更多的缺点(让我们认为这种相互依赖是不可避免的): 原来的情况:

class B;
class A
{
   B needed;
};
class B {};
输出:
B has an incomplete type.
“解”:
template<typename T = class B>
class tricky_A
{
    static_assert(is_same<T, B>::value, "Too tricky!!");
T needed;
};
class B {};
using A = tricky_A<>;
int main()
{
   A a;  // At the instantiation point, B isn't an incomplete type.
}
输出:
No problems.
常见的解决方案是利用指针,但是当你真的不需要它们时,我会看到两个问题: 1)如果你决定保留指向其他本地对象的指针,你应该确定(或你的类的用户应该确定)你的对象的生命比“保留”对象的生命更短。 2)如果你决定处理动态内存,你应该花时间保留和破坏内存,而且它会强制你处理异常处理,以使你的代码异常安全。 *)更长的代码;较小的可读性;更难保养;等等 我应该使用这个“解决方案”还是更好地搜索其他? 编辑:你没事。这不是一个真正的循环依赖,所以,没有什么可问的。这个问题可以关闭。 编辑2:更好的问题here
已邀请:

tin

赞同来自:

你设计的前提是错误的。由于代码中没有循环依赖,因此无需修复(除了在A之前找到B的定义),并且不需要进行额外的工作。 如果您修复测试用例以包含真正的循环依赖关系,您将发现您的解决方案无法解决问题。所以基本上你有更多的代码更复杂,仍然是同样的问题。 还要注意,处理循环依赖的正确方法是打破它。一旦循环依赖性消失,管理它的需求也消失了。很少有好的设计包含真正的循环依赖。

aad

赞同来自:

我认为使用指针(我同意@Andy Prowl RE:智能指针)是首选解决方案。关于你关于更长代码,更小的可读性,更难维护的观点 - 你的“棘手”解决方案虽然聪明,但却违反了所有这些租户 - 它更长,更难阅读,更难维护。中级C++开发人员的入门应该知道如何处理指针和智能指针,但是很难期望他们理解你提出的模板解决方案。 我也没有在你的例子中看到循环依赖;我假设B也依赖于A。 处理这种设计时要记住的重要事项是:

  • 分隔标题和正文很有帮助
  • 请按以下顺序执行#includes:正文#includes,正向参考#includes,最后(如有必要),标题#includes