我正在从Modern C++ Design学习基于策略的设计，我陷入了下面的一个简单示例，我试图在我的模板化策略类中使用 a std::vectorof s：std::unique_ptr

上面的一切都很好。然而，问题在于，因为MyPolicy应该是继承自的，所以它的析构函数必须是virtualand public，或者非virtualand protected（至少，从书中引用）。

在上面的示例中，每当我取消注释这些行以使其成为

或者

代码无法编译。我无法理解std::unique_ptr此示例中与问题相关的内容，因为类型T不完整或具有受保护/私有析构函数的东西。

我会很感激你的帮助。谢谢。

我按照Microsoft 文档在我的 Web 服务中实现基于策略的授权，但“ConfigureServices”功能没有运行。如果我有什么遗漏，请告诉我。

启动.cs

Shell在我的设计中，我有一个针对大量参数模板化的类（让它成为）。这些参数中的大多数是我在项目中定义的其他类，因为我为我的项目选择了基于策略的设计方法。

类声明看起来像这样：

前两个参数是应使用的整数和浮点类型。其余参数是项目中定义的特定策略。

这种设计对我来说很方便，因为它可以避免很多运行时检查（我们的目标是运行时性能）。然而，每当他/她想要创建Shell类的实例时，输入一个包含 10 多个参数的列表是非常麻烦的（从用户的角度来看）。

出于这个原因，我选择将这个打字负担连同宏一起移到一个单独的文件中。首先，我将所有策略默认为宏：

模板参数可以在单独的文件中作为宏提供，而不是在求解器的声明中。例如：

这样，实例化类只需要传递给模板参数（其他+10参数通过宏传递）。定义甚至可以移动到单独的文件中，如下所示：

这只是一种解决方法，因此不必在每次创建类的实例时都提供 10 多个参数的参数列表。宏是迄今为止我发现的最好的解决方案。但是，我知道宏不是大多数 C++ 应用程序中的“推荐”解决方案。

出于这个原因，我想知道这是否是一个典型的问题，以及如何在没有宏的情况下克服它。我还想知道宏是否是一个“好的”解决方案，或者我是否应该不惜一切代价避免这种设计。我将不胜感激有关此主题的任何帮助/评论，因为我对 C++ 很陌生 :)

此代码编译（至少使用 C++14 之后的 GNU GCC 编译器）。但是，我不喜欢使用的语法

由于它不应该要求 Buffer 被专门化：我希望 Buffer 被识别为模板模板参数，例如：

然后我希望 mutable_storage 结构能够识别模板专业化，例如

（当然不允许，因为“Buffer”不是一种类型，所以也应该改变）。但是它现在使用的方式，能够专门使用类型 Buffer 感觉有点讨厌。例如，使用 typedef

也觉得有点恶心。我正在寻找一种更清洁的方式。我试图制作一个模板模板模板参数，但这会导致模板参数中的额外模板无限流动（我不确切知道 template<...> 是如何工作的，所以也许是这样？），作为Buffer 继承自需要另一个 Buffer 才能声明 storage_t 的东西。我也尝试过使用隐式类，即 inner_storage_t。这也没有导致成功。有没有人有建议以使程序更清洁？顺便说一句，如果您发现任何其他错误或效率低下，请随时提及。感谢您的阅读以及您的帮助。

我正在创建一个库来从贝叶斯模型中抽取样本，作为 R 包的后端。问题是，MCMC算法往往会给调试带来困难。此外，Rcpp 没有简单的调试方法；在实践中，我最终得到了大量的“cout”语句。

问题是当我尝试将所有内容移至独立库时，我意识到我爱上了 Rcpp 的List。是一种非常巧妙的方式来存储不同尺寸的样品。我试图了解 Rcpp 的实现，但真诚地 我无法理解它（基于策略）来尝试复制它。

问题：有没有办法实现任意大小的命名元组？（从广义上讲，没有必要使用 C++ 元组）。

我知道我可以使用 R 安装路径链接 Rcpp，但我不确定这是否是一个好习惯，或者我是否会在尝试将 R 包上传到CRAN时遇到问题（它们非常严格）或将其用作没有 R 的用户的独立库。

谢谢！

Example_Buffer<...>继承自Buffer<...>。Buffer<storage_t, T, is_allocated>继承自storage_t<T, is_allocated>。storage_t<...>包括typedefs和静态 constexpr 数据。有没有办法通过继承访问这些typedefs和static constexpr data构造函数？Example_Buffer（通过继承，也就是不使用storage_t<T, is_allocated>? 在同一个类中使用这种语法两次感觉有点奇怪。

随意问我是否需要详细说明。

描述

我想知道我展示的代码是否可以被视为 Python 中基于策略的设计的示例。另外，我想知道您是否见过使用类似此示例的 python 模块，以便我可以向它们学习？

我在一篇文章中写了更多关于这种方法的细节和例子。

最近，我需要为我正在研究的 python 模块进行基于策略的设计之类的东西。

我在这个论坛上发现了一个类似的问题，但它已关闭，我无法添加评论。

让我总结一下我对 Python 中这种方法的期望。

• 模块类分为策略类和主机类。
• 策略类通过继承实现对宿主类的行为或接口的修改。
• 用户通过提供一组策略类从宿主类实例化一个新类。

这是我的玩具示例：

在示例中，我希望所有类都已在模块中定义。用户只需要使用符合他或她要求的输出策略来实例化HelloWorld类。

设计成分

基本的设计成分是

• 多重继承：存在于 C++ 和 Python 中。

• 推迟继承：推迟主机类和策略类之间的继承定义，直到用户实例化主机类

• 类实例化

使用 mixins 作为替代

我刚刚从其中一条评论中了解到，可以使用Python mixins作为创建新类的替代方法。在这种方法下，模块的代码分为基础类和混合类。然后，您可以从基类创建新类，并使用 mixin 类来实现对基类提供的行为或接口的修改。

按照这个答案，我能够使用 mixins 编写我的第一个示例。

方法之间的区别

mixin 和我之前的示例之间的主要区别在于类之间的继承层次结构。mixin 和 based classes 都不能推断出哪个是 mixin 或 based class 的角色。这是因为它们都是PrintHelloWorld或SaveHelloWorld等新类的父类。

在我尝试进行基于策略的设计时，宿主类总是可以知道哪些类是他们的策略，因为它们是它的父类。此功能允许我利用 Python 的方法解析顺序 (MRO) 在主机类和策略类之间创建组合。这些组合是使用实例化的主机类作为策略来实例化另一个主机类的结果，请参见下面的示例。

我不确定这种差异在这两种方法之间是否有任何实际意义。目前我只是想了解可以用它们表达什么。

走下递归的兔子洞

我想指出，可以在混合中添加递归。这让人想起 C++ 中使用的一些元编程技术，这些技术可以在编译时进行计算。这原则上在作为解释语言的 Python 中没有应用。请耐心等待下面的下一个不切实际的例子。

MandelbrotSeq工厂将Mandelbrot序列递归地映射为层次连接类的列表。M的第一个元素指的是Identity类的第五代后代。这意味着调用M [0] 实例的run(.)成员函数将返回序列的第 5 个值。同样，我调用M [1] 实例的run(.) 成员函数将返回序列的第 4 个值。

这只是如何利用 Python MRO 的一个极端示例，如前面部分所示。这只是一个玩具示例，仅仅因为涉及递归，我无法想出比分形之类的更好的主意。请不要在家里这样做！

在 Meeting C++ 2019 上，Jon Kalb 发表了关于模板技术的演讲并提到了策略类。见这里的来源：https ://youtu.be/MLV4IVc4SwI?t=1815

有问题的有趣代码片段是：

我经常看到这种类型的设计，我想知道这里的继承是否比组合有任何真正的优势。以我个人的经验，我听说过很多关于Prefer 组合优于继承范式的信息。所以我编写代码的方式会更像这样：

不会涉及任何虚拟功能。不过，如果您能分享一些见解，我将不胜感激。我会对内存布局的差异及其影响特别感兴趣。如果CheckingPolicy没有数据成员，而只有一个check方法或一个重载的调用运算符，它会有所不同吗？

问题的主要部分是使用基于策略的设计和可变参数模板的CRTP。从策略无法访问主/派生类的受保护或私有成员。由于使用可变参数模板，我不能将策略声明为朋友。

问题是，如何将所有策略类设置为派生类的朋友。

鉴于此 CRTP 解决方案，什么是支持多继承级别并解决了没有虚拟继承的菱形问题。

在带有可变参数模板的基于策略的设计中使用此 CRTP 解决方案

目标是像这样使用策略中的受保护变量

使用示例

可运行示例

我正在试验并尝试制作一个基于模板策略的元库。示例案例是为设备驱动程序聚合 2 个类。类实现device_logicand connection_logic，它们不需要依赖于彼此的类型：

• 设备逻辑仅取决于通信协议（消息）。
• connection_logic 只是字节数组的来源，可能使用不同类型的连接：SerialPort、tcp、udp、自定义 PCI Express 设备等。

目标不是在它们上强制使用任何接口或类型。它们必须完全依赖于 API 规范，并且只提供必要的特征。

STL 方法是在标头中定义特征，然后在类中使用它们。所以特征标签必须定义在模板库的头文件中。

在这种情况下aggregate_device，聚合连接和设备逻辑。如果设备逻辑可读，则连接逻辑必须提供输入。如果设备逻辑是可写的，则连接必须提供输出。

此版本有效，但引入了对模板库的依赖。引入依赖项（甚至是仅包含头文件的库）对开发人员来说并不方便，而且通常对库也不利。有人可能想device_logic在另一个模块或项目中使用类，但不想拉取它所依赖的模板库。

消除依赖关系的另一个解决方案不是强制类提供者将io_type标签注入他的类，而是自己定义它们。

现在我使用第二种方法并且它有效。问题是：

• 这是一种合法的方法吗？
• 对于类提供者来说，这不会令人困惑吗？
• 会（在多大程度上）更难维护？
• 编译性能可能有什么不同？