blocks|key|3327707|text|Pointer+to+implementation通常是关于隐藏结构化实现细节的。Interfaces是关于实例化不同的实现。它们实际上有两个不同的目的。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|3327708|entityMap^0|0|P|15|A|0^^$0|@$1|2|3|4|5|6|7|H|8|@$9|I|A|J|B|C]|$9|K|A|L|B|C]]|D|@]|E|$]]|$1|F|3|-4|5|6|7|M|8|@]|D|@]|E|$]]]|G|$]]

<code>Pointer to implementation</code> is usually about hiding structural implementation details. <code>Interfaces</code> are about instancing different implementations. They really serve two different purposes.

blocks|key|3327736|text|pimpl惯用法可以帮助您减少构建依赖和构建时间，特别是在大型应用程序中，并最大限度地减少类的实现细节在一个编译单元中的头部暴露。您的类的用户甚至不需要知道粉刺的存在(除非是他们不了解的隐秘指针！)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3327737|抽象类(纯虚拟)是你的客户必须知道的东西:如果你试图使用它们来减少耦合和循环引用，你需要添加一些方法来允许它们创建你的对象(例如，通过工厂方法或类，依赖注入或其他机制)。|3327738|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

The pimpl idiom helps you reduce build dependencies and times especially in large applications, and minimizes header exposure of the implementation details of your class to one compilation unit. The users of your class should not even need to be aware of the existence of a pimple (except as a cryptic pointer to which they are not privy!). 

Abstract classes (pure virtuals) is something of which your clients must be aware: if you try to use them to reduce coupling and circular references, you need to add some way of allowing them to create your objects (e.g. through factory methods or classes, dependency injection or other mechanisms).

blocks|key|3327775|text|在我的理解中，这两件事的目的完全不同。pimple成语的目的基本上是给你一个实现的句柄，这样你就可以做一些事情，比如快速交换一个排序。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3327776|虚类的用途更多的是允许多态性，即你有一个未知的指针指向派生类型的对象，当你调用函数x时，无论基指针实际指向的是什么类，你总是会得到正确的函数。|3327777|真的是苹果和橙子。|3327778|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

In my understanding these two things serve completely different purposes. The purpose of the pimple idiom is basically give you a handle to your implementation so you can do things like fast swaps for a sort.

The purpose of virtual classes is more along the line of allowing polymorphism, i.e. you have a unknown pointer to an object of a derived type and when you call function x you always get the right function for whatever class the base pointer actually points to.

Apples and oranges really.

blocks|key|341294|text|共享库有一个非常真实的问题，pimpl惯用法巧妙地绕过了纯虚拟无法解决的问题:如果不强制类的用户重新编译他们的代码，就不能安全地修改/删除类的数据成员。在某些情况下，这可能是可以接受的，但例如对于系统库，这是不能接受的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|341295|要详细解释该问题，请考虑共享库/标头中的以下代码：|341296|//+header
struct+A
{
public:
++A();
++//+more+public+interface,+some+of+which+uses+the+int+below
private:
++int+a;
};

//+library+
A::A()
++:+a(0)
{}|code-block|syntax|javascript|341297|编译器在共享库中发出代码，该代码计算要初始化的整数的地址，使其与它知道为this的A对象的指针之间的某个偏移量(在本例中可能为零，因为它是唯一的成员)。|offset|length|style|CODE|341298|在代码的用户端，new+A将首先分配sizeof(A)字节的内存，然后将指向该内存的指针作为this传递给A::A()构造函数。|341299|如果在以后的库修订中，您决定删除整数、使其更大、更小或添加成员，则用户代码分配的内存量与构造函数代码期望的偏移量之间将不匹配。可能的结果是崩溃，如果你够幸运的话--如果你不够幸运，你的软件会表现出奇怪的行为。|341300|通过pimpl，您可以安全地向内部类添加和删除数据成员，因为内存分配和构造函数调用发生在共享库中：|341301|//+header
struct+A
{
public:
++A();
++//+more+public+interface,+all+of+which+delegates+to+the+impl
private:
++void+*+impl;
};

//+library+
A::A()
++:+impl(new+A_impl())
{}|341302|您现在需要做的就是保持您的公共接口没有数据成员，而不是指向实现对象的指针，这样您就不会出现此类错误。|341303|编辑：我可能应该补充说，我在这里谈论构造函数的唯一原因是我不想提供更多的代码-同样的论证适用于所有访问数据成员的函数。|BOLD|341304|entityMap^0|0|0|0|10|4|0|8|5|I|9|1A|4|1H|6|0|0|0|0|0|0|3|0^^$0|@$1|2|3|4|5|6|7|13|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|14|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|15|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|16|8|@$K|17|L|18|M|N]]|9|@]|A|$]]|$1|O|3|P|5|6|7|19|8|@$K|1A|L|1B|M|N]|$K|1C|L|1D|M|N]|$K|1E|L|1F|M|N]|$K|1G|L|1H|M|N]]|9|@]|A|$]]|$1|Q|3|R|5|6|7|1I|8|@]|9|@]|A|$]]|$1|S|3|T|5|6|7|1J|8|@]|9|@]|A|$]]|$1|U|3|V|5|F|7|1K|8|@]|9|@]|A|$G|H]]|$1|W|3|X|5|6|7|1L|8|@]|9|@]|A|$]]|$1|Y|3|Z|5|6|7|1M|8|@$K|1N|L|1O|M|10]]|9|@]|A|$]]|$1|11|3|-4|5|6|7|1P|8|@]|9|@]|A|$]]]|12|$]]

There's a very real problem with shared libraries that the pimpl idiom circumvents neatly that pure virtuals can't: you cannot safely modify/remove data members of a class without forcing users of the class to recompile their code. That may be acceptable under some circumstances, but not e.g. for system libraries.

To explain the problem in detail, consider the following code in your shared library/header:

<pre><code>// header
struct A
{
public:
 A();
 // more public interface, some of which uses the int below
private:
 int a;
};

// library 
A::A()
 : a(0)
{}
</code></pre>

The compiler emits code in the shared library that calculates the address of the integer to be initialized to be a certain offset (probably zero in this case, because it's the only member) from the pointer to the A object it knows to be <code>this</code>.

On the user side of the code, a <code>new A</code> will first allocate <code>sizeof(A)</code> bytes of memory, then hand a pointer to that memory to the <code>A::A()</code> constructor as <code>this</code>.

If in a later revision of your library you decide to drop the integer, make it larger, smaller, or add members, there'll be a mismatch between the amount of memory user's code allocates, and the offsets the constructor code expects. The likely result is a crash, if you're lucky - if you're less lucky, your software behaves oddly.

By pimpl'ing, you can safely add and remove data members to the inner class, as the memory allocation and constructor call happen in the shared library:

<pre><code>// header
struct A
{
public:
 A();
 // more public interface, all of which delegates to the impl
private:
 void * impl;
};

// library 
A::A()
 : impl(new A_impl())
{}
</code></pre>

All you need to do now is keep your public interface free of data members other than the pointer to the implementation object, and you're safe from this class of errors.

Edit: I should maybe add that the only reason I'm talking about the constructor here is that I didn't want to provide more code - the same argumentation applies to all functions that access data members.

blocks|key|3115122|text|在编写C%2B%2B类时，应该考虑它是否将是|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3115123|3115124|A值类型|ordered-list-item|3115125|3115126|按值复制，身份从来都不重要。它适合作为std::map中的一个键。例如，"string“类，或"date”类，或"complex+number“类。“复制”这样一个类的实例是有意义的。|3115127|3115128|An实体类型|3115129|3115130|身份很重要。总是通过引用传递，从不通过"value“传递。通常，“复制”类的实例是没有意义的。当它确实有意义时，多态的“克隆”方法通常更合适。示例:套接字类、数据库类、“策略”类，以及函数式语言中的任何“闭包”。|3115131|pImpl和纯抽象基类都是减少编译时依赖性的技术。|3115132|然而，我只使用pImpl来实现值类型(类型1)，而且只有在我真正想要最小化耦合和编译时依赖时才使用它。通常，这是不值得的。正如您正确地指出的那样，有更多的语法开销，因为您必须为所有的公共方法编写转发方法。对于类型2类，我总是使用带有关联工厂方法的纯抽象基类。|3115133|entityMap^0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|U|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|V|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|W|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|X|8|@]|9|@]|A|$]]|$1|G|3|H|5|6|7|Y|8|@]|9|@]|A|$]]|$1|I|3|-4|5|6|7|Z|8|@]|9|@]|A|$]]|$1|J|3|K|5|E|7|10|8|@]|9|@]|A|$]]|$1|L|3|-4|5|6|7|11|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|12|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|13|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|14|8|@]|9|@]|A|$]]|$1|S|3|-4|5|6|7|15|8|@]|9|@]|A|$]]]|T|$]]

When writing a C++ class, it's appropriate to think about whether it's going to be
<ol>
<li>A Value Type
Copy by value, identity is never important. It's appropriate for it to be a key in a std::map. Example, a &quot;string&quot; class, or a &quot;date&quot; class, or a &quot;complex number&quot; class. To &quot;copy&quot; instances of such a class makes sense.
</li>
<li>An Entity type
Identity is important. Always passed by reference, never by &quot;value&quot;. Often, doesn't make sense to &quot;copy&quot; instances of the class at all. When it does make sense, a polymorphic &quot;Clone&quot; method is usually more appropriate. Examples: A Socket class, a Database class, a &quot;policy&quot; class, anything that would be a &quot;closure&quot; in a functional language.
</li>
</ol>
Both pImpl and pure abstract base class are techniques to reduce compile time dependencies.
However, I only ever use pImpl to implement Value types (type 1), and only sometimes when I really want to minimize coupling and compile-time dependencies. Often, it's not worth the bother. As you rightly point out, there's more syntactic overhead because you have to write forwarding methods for all of the public methods. For type 2 classes, I always use a pure abstract base class with associated factory method(s).

blocks|key|3115163|text|我在为同样的问题寻找答案。在阅读了一些文章和一些实践之后，我更喜欢使用“纯虚拟类接口”。|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|entityRanges|data|3115164|3115165|他们更直截了当(这是一个主观的观点)。Pimpl惯用法让我感觉我是在“为编译器”写代码，而不是为将阅读我的代码的“下一位开发人员”。|ordered-list-item|3115166|一些测试框架直接支持模拟纯虚拟类|3115167|确实你需要一个工厂()才能从外部访问。但如果你想利用多态性:这也是“赞成”的，而不是“反对的”。...and一个简单的工厂方法并不会对|3115168|造成太大的伤害|3115169|唯一的缺点(我正在尝试研究这一点)是pimpl惯用法可以更快|3115170|3115171|当代理调用是内联时，虽然继承必须在运行时额外访问对象VTABLE+|3115172|+pimpl公共代理类的内存占用更小(您可以轻松地进行优化，以实现更快的交换和其他类似的pimpl|3115173|3115174|entityMap^0|Q|H|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|Z|8|@$9|10|A|11|B|C]]|D|@]|E|$]]|$1|F|3|-4|5|6|7|12|8|@]|D|@]|E|$]]|$1|G|3|H|5|I|7|13|8|@]|D|@]|E|$]]|$1|J|3|K|5|I|7|14|8|@]|D|@]|E|$]]|$1|L|3|M|5|I|7|15|8|@]|D|@]|E|$]]|$1|N|3|O|5|6|7|16|8|@]|D|@]|E|$]]|$1|P|3|Q|5|6|7|17|8|@]|D|@]|E|$]]|$1|R|3|-4|5|6|7|18|8|@]|D|@]|E|$]]|$1|S|3|T|5|I|7|19|8|@]|D|@]|E|$]]|$1|U|3|V|5|I|7|1A|8|@]|D|@]|E|$]]|$1|W|3|-4|5|6|7|1B|8|@]|D|@]|E|$]]|$1|X|3|-4|5|6|7|1C|8|@]|D|@]|E|$]]]|Y|$]]

I was searching an answer for the same question.
After reading some articles and some practice I prefer using "Pure virtual class interfaces".

<ol>
<li>They are more straight forward (this is a subjective opinion). Pimpl idiom makes me feel I'm writing code "for the compiler", not for the "next developer" that will read my code. </li>
<li>Some testing frameworks have direct support for Mocking pure virtual classes</li>
<li>It's true that you need a factory to be accessible from the outside. 
But if you want to leverage polymorphism: that's also "pro", not a "con". ...and a simple factory method does not really hurts so much</li>
</ol>

The only drawback (I'm trying to investigate on this) is that pimpl idiom could be faster

<ol>
<li>when the proxy-calls are inlined, while inheriting necessarily need an extra access to the object VTABLE at runtime</li>
<li>the memory footprint the pimpl public-proxy-class is smaller (you can do easily optimizations for faster swaps and other similar optimizations) </li>
</ol>

blocks|key|3327929|text|我们不能忘记，继承是一种比委托更强、更紧密的耦合。在决定使用什么设计习惯用法来解决特定问题时，我还会考虑到答案中提出的所有问题。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3327930|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

We must not forget that inheritance is a stronger, closer coupling than delegation. I would also take into account all the issues raised in the answers given when deciding what design idioms to employ in solving a particular problem.

blocks|key|342743|text|我讨厌粉刺！他们把这个类写得很难看，而且不可读。所有方法都被重定向到pimple。你永远看不到头部，什么函数有类，所以你不能重构它(例如，简单地改变一个方法的可见性)。这门课感觉像是“怀孕了”。我认为使用iterfaces更好，而且确实足以对客户端隐藏实现。你可以通过事件让一个类实现几个接口来保持它们。人们应该更喜欢界面！注意:您不需要工厂类。相关的是，类客户端通过适当的接口与它的实例通信。我发现隐藏私有方法是一种奇怪的偏执，看不出原因，因为我们有接口。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|342744|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

I hate pimples! They do the class ugly and not readable. All methods are redirected to pimple. You never see in headers, what functionalities has the class, so you can not refactor it (e. g. simply change the visibility of a method). The class feels like "pregnant". I think using iterfaces is better and really enough to hide the implementation from the client. You can event let one class implement several interfaces to hold them thin. One should prefer interfaces!
Note: You do not necessary need the factory class. Relevant is that the class clients communicate with it's instances via the appropriate interface.
The hiding of private methods I find as a strange paranoia and do not see reason for this since we hav interfaces.

blocks|key|346233|text|尽管在其他答案中进行了广泛的介绍，但也许我可以更明确地说明pimpl相对于虚拟基类的一个好处：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|346234|pimpl方法对用户来说是透明的，这意味着你可以在堆栈上创建类的对象，并直接在容器中使用它们。如果您试图使用抽象虚拟基类隐藏实现，则需要从工厂返回指向基类的共享指针，从而使其使用复杂化。考虑以下等效的客户端代码：|346235|//+Pimpl
Object+pi_obj(10);
std::cout+<<+pi_obj.SomeFun1();

std::vector<Object>+objs;
objs.emplace_back(3);
objs.emplace_back(4);
objs.emplace_back(5);
for+(auto&+o+:+objs)
++++std::cout+<<+o.SomeFun1();

//+Abstract+Base+Class
auto+abc_obj+=+ObjectABC::CreateObject(20);
std::cout+<<+abc_obj->SomeFun1();

std::vector<std::shared_ptr<ObjectABC>>+objs2;
objs2.push_back(ObjectABC::CreateObject(13));
objs2.push_back(ObjectABC::CreateObject(14));
objs2.push_back(ObjectABC::CreateObject(15));
for+(auto&+o+:+objs2)
++++std::cout+<<+o->SomeFun1();|code-block|syntax|javascript|346236|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|K|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|L|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|M|8|@]|9|@]|A|$G|H]]|$1|I|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|J|$]]

Although broadly covered in the other answers maybe I can be a bit more explicit about one benefit of pimpl over virtual base classes:

A pimpl approach is transparent from the user view point, meaning you can e.g. create objects of the class on the stack and use them directly in containers. If you try to hide the implementation using an abstract virtual base class, you will need to return a shared pointer to the base class from a factory, complicating it's use. Consider the following equivalent client code:

<pre><code>// Pimpl
Object pi_obj(10);
std::cout &lt;&lt; pi_obj.SomeFun1();

std::vector&lt;Object&gt; objs;
objs.emplace_back(3);
objs.emplace_back(4);
objs.emplace_back(5);
for (auto&amp; o : objs)
 std::cout &lt;&lt; o.SomeFun1();

// Abstract Base Class
auto abc_obj = ObjectABC::CreateObject(20);
std::cout &lt;&lt; abc_obj-&gt;SomeFun1();

std::vector&lt;std::shared_ptr&lt;ObjectABC&gt;&gt; objs2;
objs2.push_back(ObjectABC::CreateObject(13));
objs2.push_back(ObjectABC::CreateObject(14));
objs2.push_back(ObjectABC::CreateObject(15));
for (auto&amp; o : objs2)
 std::cout &lt;&lt; o-&gt;SomeFun1();
</code></pre>

blocks|key|343666|text|关于pimpl惯用法最恼人的问题是，它使得维护和分析现有代码变得极其困难。所以使用pimpl，你付出了开发人员的时间和挫折，只是为了“减少构建依赖和时间，并最大限度地减少实现细节的头部暴露”。如果真的值得的话，你自己决定吧。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|343667|特别是“构建时间”是一个问题，你可以通过更好的硬件或使用Incredibuild+(+www.incredibuild.com，也已经包含在Visual+Studio2017中)这样的工具来解决，因此不会影响你的软件设计。软件设计通常应该独立于软件的构建方式。|343668|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

The most annoying problem about the pimpl idiom is it makes it extremely hard to maintain and analyse existing code. So using pimpl you pay with developer time and frustration only to "reduce build dependencies and times and minimize header exposure of the implementation details". Decide yourself, if it is really worth it.

Especially "build times" is a problem you can solve by better hardware or using tools like Incredibuild ( www.incredibuild.com, also already included in Visual Studio 2017 ), thus not affecting your software design. Software design should be generally independent of the way the software is built.

I was wondering what would make a programmer to choose either Pimpl idiom or pure virtual class and inheritance.

I understand that pimpl idiom comes with one explicit extra indirection for each public method and the object creation overhead.

The Pure virtual class in the other hand comes with implicit indirection(vtable) for the inheriting implementation and I understand that no object creation overhead. 
EDIT: But you'd need a factory if you create the object from the outside

What makes the pure virtual class less desirable than the pimpl idiom?

Pimpl idiom vs Pure virtual class interface

我想知道是什么让程序员选择Pimpl惯用法或纯虚拟类和继承。我知道pimpl惯用法为每个公共方法和对象创建开销提供了一个显式的额外间接地址。另一方面，Pure虚拟类为继承实现提供了隐式的间接性(Vtable)，我知道没有创建对象的开销。编辑：但是如果您从外部创建对象，则需要一个工厂是什么让纯虚拟类不如pimpl习惯用法...

问Pimpl惯用法与纯虚拟类接口
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问Pimpl惯用法与纯虚拟类接口EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问Pimpl惯用法与纯虚拟类接口
EN