没有托管堆是否可以进行 DI？
Is DI possible without a managed heap?
通过依赖注入，class' 依赖由调用者实例化并传入，通常作为构造函数参数。这在具有托管堆的语言中效果很好，因为无需担心依赖项生命周期的结束。但是其他类型的语言呢？
比如在传统的malloc和free环境下，分配内存的方法一般也应该释放。我不确定如何使用 DI 来完成。
或者使用需要引用计数的内存方案，例如COM，我不确定调用者何时会在依赖项上调用 Release，或者接收注入的对象是否应该调用 Release 两次。
是否可以在没有托管堆的情况下使用 DI？如果是这样，哪些代码模式可以很好地确保资源被正确释放？
对我来说，DI 和垃圾收集是无关的。你只需要组织内存管理。从尝试在任何地方使用静态对象开始。如果您的 DI 图是静态的（即它在应用程序工作期间没有改变），这将起作用。
如果您的 DI 图在不断发展或者其结构是在应用程序启动期间决定的，则需要有关您如何执行此操作的更多信息。我不确定适合每种情况的通用解决方案是否可行。修改 DI 图的实体应负责清理。在其他情况下，与在 C++ 中完成的方式完全相同。例如，您可以将 DI 代理对象放入一个静态容器中，该容器将在应用程序工作结束时被销毁（如果所有内容都组织得当的话）。
在 C/C++ 中，需要以这种或那种方式进行内存管理，以管理容器、连接和无数其他事物。我不明白为什么 DI 很特别。垃圾收集解决了它所用的所有内容的内存管理（仍然有其自身的缺点）。
But what about other types of languages? Is it possible to use DI without a managed heap?
拥有托管堆不是 DI 的先决条件。 例如 C++ 不是托管语言，但有针对它的 DI 框架，其功能与 DI 框架相当Java 或 C# 等托管语言。
Daniele Pallastrelli 的精彩演讲 Going native with less coupling - Dependency Injection in C++ explains in detail the benefits of DI over two other decoupling techniques (factories and service locators). It also presents a C++ DI framework called Wallaroo 并解释了其内部结构。
另一个 C++ DI 框架，基于与 Wallaroo 不同的方法 [Boost].DI。我强烈推荐阅读介绍章节。它对 "Do I use a Dependency Injection already?"、"Do I need a Dependency Injection?" 等问题给出了简短但很好的答案
我要提到的第三个 C++ DI 框架是 Infector++。
这些只是众多 C++ DI 框架中的三个。您可以在 this page.
上找到很多
我的观点是，如果 C++ 有这么多的 DI 框架，不管它们是否被广泛接受，没有托管堆的 DI 肯定是可能的:-)
If so, what code patterns work well to ensure that resources are released correctly?
上面的链接提供了有关如何在 C++ 中完成完整的 DI 框架的额外输入，包括依赖项解析、不同的创建策略和对象范围，最后是您的问题，对象生命周期管理。
在这里，我将简要概述一下 如何一致且确定地完成生命周期管理。所有提到的框架都大量使用智能指针（std::unique_ptr、std::shared_ptr，如果它们提供 Boost 支持，也会使用 boost::shared_ptr）并将创建策略语义附加到它们。请注意，您不需要完整的 DI 框架即可使用此模式。基本思路很简单。
假设我声明一个 class 如下所示：
class i_depend_on_others {
i_depend_on_others(std::unique_ptr<other>,
std::shared_ptr<another_other>,
boost::shared_ptr<yet_another_other>)
{ }
};
这是一个清晰的构造函数注入，但具有关于 "others" 预期生命周期的附加语义。第一个 other 将由 i_depend_on_others 实例拥有，因为我们有 std::unique_ptr 它会在删除 i_depend_on_others 实例后立即被删除。 another_other 和 yet_another_other 的生命周期应该独立于 i_depend_on_others 实例。该模式清楚地定义了 i_depend_on_others 实例何时负责清理资源以及调用代码何时应执行此操作。 （在 DI 框架的情况下，框架负责共享实例。）
问题是在这种情况下该怎么办：
class i_depend_on_others_as_well {
i_depend_on_others_as_well(other*) { }
};
（我不会在这里争论现代 C++ 开发中应避免使用原始指针。假设我们被迫使用它们。）
同样，该模式定义了清晰的语义。 原始指针意味着所有权转移。 i_depend_on_others_as_well 的实例负责删除 other。
对于像 [Boost].DI 这样的 DI 框架，指针的类型将决定注入对象的默认生命周期。对于共享指针，它们将是单例，创建一次并由 [Boost].DI 维护，对于原始指针和唯一指针，每次都会创建一个新实例。
可以在 [Boost].DI 文档的 "Decide the life times" 章节中找到有关此模式的更详细说明。
通过依赖注入，class' 依赖由调用者实例化并传入，通常作为构造函数参数。这在具有托管堆的语言中效果很好，因为无需担心依赖项生命周期的结束。但是其他类型的语言呢？
比如在传统的malloc和free环境下，分配内存的方法一般也应该释放。我不确定如何使用 DI 来完成。
或者使用需要引用计数的内存方案，例如COM，我不确定调用者何时会在依赖项上调用 Release，或者接收注入的对象是否应该调用 Release 两次。
是否可以在没有托管堆的情况下使用 DI？如果是这样，哪些代码模式可以很好地确保资源被正确释放？
对我来说，DI 和垃圾收集是无关的。你只需要组织内存管理。从尝试在任何地方使用静态对象开始。如果您的 DI 图是静态的（即它在应用程序工作期间没有改变），这将起作用。
如果您的 DI 图在不断发展或者其结构是在应用程序启动期间决定的，则需要有关您如何执行此操作的更多信息。我不确定适合每种情况的通用解决方案是否可行。修改 DI 图的实体应负责清理。在其他情况下，与在 C++ 中完成的方式完全相同。例如，您可以将 DI 代理对象放入一个静态容器中，该容器将在应用程序工作结束时被销毁（如果所有内容都组织得当的话）。
在 C/C++ 中，需要以这种或那种方式进行内存管理，以管理容器、连接和无数其他事物。我不明白为什么 DI 很特别。垃圾收集解决了它所用的所有内容的内存管理（仍然有其自身的缺点）。
But what about other types of languages? Is it possible to use DI without a managed heap?
拥有托管堆不是 DI 的先决条件。 例如 C++ 不是托管语言，但有针对它的 DI 框架，其功能与 DI 框架相当Java 或 C# 等托管语言。
Daniele Pallastrelli 的精彩演讲 Going native with less coupling - Dependency Injection in C++ explains in detail the benefits of DI over two other decoupling techniques (factories and service locators). It also presents a C++ DI framework called Wallaroo 并解释了其内部结构。
另一个 C++ DI 框架，基于与 Wallaroo 不同的方法 [Boost].DI。我强烈推荐阅读介绍章节。它对 "Do I use a Dependency Injection already?"、"Do I need a Dependency Injection?" 等问题给出了简短但很好的答案
我要提到的第三个 C++ DI 框架是 Infector++。
这些只是众多 C++ DI 框架中的三个。您可以在 this page.
上找到很多我的观点是，如果 C++ 有这么多的 DI 框架，不管它们是否被广泛接受，没有托管堆的 DI 肯定是可能的:-)
If so, what code patterns work well to ensure that resources are released correctly?
上面的链接提供了有关如何在 C++ 中完成完整的 DI 框架的额外输入，包括依赖项解析、不同的创建策略和对象范围，最后是您的问题，对象生命周期管理。
在这里，我将简要概述一下 如何一致且确定地完成生命周期管理。所有提到的框架都大量使用智能指针（std::unique_ptr、std::shared_ptr，如果它们提供 Boost 支持，也会使用 boost::shared_ptr）并将创建策略语义附加到它们。请注意，您不需要完整的 DI 框架即可使用此模式。基本思路很简单。
假设我声明一个 class 如下所示：
class i_depend_on_others {
i_depend_on_others(std::unique_ptr<other>,
std::shared_ptr<another_other>,
boost::shared_ptr<yet_another_other>)
{ }
};
这是一个清晰的构造函数注入，但具有关于 "others" 预期生命周期的附加语义。第一个 other 将由 i_depend_on_others 实例拥有，因为我们有 std::unique_ptr 它会在删除 i_depend_on_others 实例后立即被删除。 another_other 和 yet_another_other 的生命周期应该独立于 i_depend_on_others 实例。该模式清楚地定义了 i_depend_on_others 实例何时负责清理资源以及调用代码何时应执行此操作。 （在 DI 框架的情况下，框架负责共享实例。）
问题是在这种情况下该怎么办：
class i_depend_on_others_as_well {
i_depend_on_others_as_well(other*) { }
};
（我不会在这里争论现代 C++ 开发中应避免使用原始指针。假设我们被迫使用它们。）
同样，该模式定义了清晰的语义。 原始指针意味着所有权转移。 i_depend_on_others_as_well 的实例负责删除 other。
对于像 [Boost].DI 这样的 DI 框架，指针的类型将决定注入对象的默认生命周期。对于共享指针，它们将是单例，创建一次并由 [Boost].DI 维护，对于原始指针和唯一指针，每次都会创建一个新实例。
可以在 [Boost].DI 文档的 "Decide the life times" 章节中找到有关此模式的更详细说明。