编译器模板实现会引入循环依赖吗？答案

【问题标题】：Do Compiler Template Implementations Introduce Circular Dependencies?编译器模板实现会引入循环依赖吗？
【发布时间】：2013-02-05 21:25:25
【问题描述】：

我正在使用 C++ 开发 API，并尝试/真的/努力不使用 RTTI（运行时类型信息）来实现一些依赖注入功能。

我相信我可以做到这一点，但是通过使用模板——但这让我想知道：

当模板被“扩展”并由编译器实现时，当模板类在框架库中实现时，它们是否实际上引入了循环依赖（编译时或运行时），以及该模板的客户端类在上层库中？

感谢您的帮助！

#include <string>

/************************************************************/
// Implemented in Framework.lib
namespace Framework 
{
    template<typename ShapeTemplateType>
    class Utility
    {           
        void Do()
        {
            ShapeTemplateType x;
            (void) x;
        }
    };
} // End namespace Framework 

/************************************************************/
// Implemented in Application.lib
namespace Application
{
    class StateObject
    {
        int i;
    };

    class Facade
    {
        Framework::Utility<StateObject> state;
    };
} // End Namespace Application


/********************************************************************/
// Implemented in Client
int main(int args, char* argv[])
{
    Application::Facade facade;

    //Derived d;
    return 0;
}

【问题讨论】：

看起来不像。你有什么错误吗？
这段代码应该做什么？
您的模板“在 Framework.lib 中实现”是什么意思？ templates 往往是（除了一些花哨的舞蹈）是一个纯粹的头文件结构。它们以什么方式在特定的库中“实现”？
@Yakk 下面的答案之一谈到了编译单元，这就是我的意思。
Framework.lib 几乎肯定不是编译单元的名称。有编译单元链接到libs，但libs 不是编译单元。

标签： c++ templates generics c++11 circular-dependency

【解决方案1】：

模板的代码在实例化它的编译单元中生成。在您的示例中，生成的机器代码将位于Application.lib。

【讨论】：

只是为了确保我清楚，根据您的回答，即使没有层的物理分离，并且只有一个生成的编译单元，生成的编译单元中的代码也将依赖于调用代码，反之亦然，对吗？尽管在生成的编译单元中，仍然存在循环依赖...
也许你会这么说，但这有什么关系呢？通常，编译单元是您必须担心循环依赖的级别。一个编译单元中的任何内容都不值得关注，因为它不会导致任何问题。
我在生成循环依赖时遇到问题，最终导致堆栈溢出。带有新的可变参数模板支持的 MS Nov 2012 C++ 编译器存在一个错误，我花了一段时间才将其缩小到编译器问题。谢谢！

【解决方案2】：

您的意思是循环模板依赖，例如：

template<class T>
using A = B<T>;

template<class T>
using B = A<T>;

int main()
{
    A<int>;
}

这在 A 的声明中失败，因为 B 不可用，如果你 fwd 声明它，它会抱怨它不完整。

我认为模板中不可能存在循环依赖，因为用于进行实例化的每个模板参数都必须有一个完整的类型。鉴于此，模板实例化链因此必须是非循环的。

【讨论】：