C++ c++；：跨pimpl实现的共享代码

我目前正在编写一些必须可移植的代码。为此，我使用pimpl习惯用法，因为我认为它将实际实现与API完全分离。 无论如何，pimpl习惯用法只有在实现不共享代码的情况下才非常有效（例如，一些在实现之间共享的通用函数）

另一个选择是抽象接口，我想。-无论如何，因为我在整个项目中使用pimpl，我真的不认为将其与抽象接口（在API级别）混合使用是一个好主意

那么，您建议在不同PIMPL之间共享代码的选项是什么？我考虑为pimpl本身设计一个抽象接口类，这样实际的API仍然清晰地分开，但这似乎也是一个奇怪的想法

PS：我不想讨论pimpl或抽象接口是否更好。从API的角度来看，我决定使用pimpl，并且我愿意坚持使用它。

有很棒的pimpl设计。检查一下

---

您可以将共享代码移动到新的独立类、命名空间或模块。

您的类模型可以包含抽象类，即使实现包含PIMPL。两者是正交的

然而，如果您将所有私有方法都放在pimpl中，可能会遇到一些困难。无论在何处定义，调用实例方法都需要指向实例的指针。可以将实例指针作为pimpl方法的参数提供，也可以隐式地在外部类的私有方法中提供

---

另一种选择是通过组合而不是继承来共享，这有其自身的优势。

如果实现PIMPL的细节是可重用的，那么就其本身而言，将其公开也不会让您感到不安。主要的一点是保持界面干净

不过，有时您希望共享不应该在外部使用的帮助程序。在这一点上，清楚地记录不应重复使用的东西是您试图解决的真正问题。我喜欢使用细节/私有标题

// Implementation details, not for reuse
namespace some_public_ns {
namespace detail {
  // .. shared code
}}

通常，您会将此详细代码放在它自己的头中。组织通常会选择命名约定以避免混淆

thingajig.h
thingajig_priv.h
thingajig_detail.h

它不会让拿着猎枪的人离开你的客厅。我想说的是，你不应该试图这么做。不过，很难意外地引入这个共享代码

然后，在重用代码的cpp文件中，您可以只在一个非名称空间中包含细节名称空间

namespace some_public_ns {
namespace {
  using namespace detail;
}}

---

这允许您将混乱排除在名称空间之外，但在实现时不必指定

：：detail

。

是的，我考虑过按组合共享。-我认为这甚至可能会使依赖关系更加明确，这对于希望接触实际实现代码进行移植的人来说非常好。当然要考虑一下！这个标准看起来好像是十五年前写的：很遗憾错过了C++发生的一切。@ NicolaMusatti：可能是真的。您应该检查支持的VTK编译器。标准非常重要，我对改进感到非常高兴，但另一方面，我们应该在真正的编译器上工作。：）@Naszta是的，人们往往会忘记有几个百分点的市场份额没有被g++和VC++所覆盖；-）更不用说更早，有时甚至更早发布！您好，我实际上正是出于这个原因将所有pimpl类放在一个详细名称空间中（即，实际名称空间中只有一个以Window开头的类，而不是另一个WindowImpl）。我想我现在有了一些想法来解决我的问题，或者使用自由函数，或者使用组合和一些可以被PIMPL使用的帮助器结构。谢谢