Timeline for What's is the point of PImpl pattern while we can use interface for the same purpose in C++?
Current License: CC BY-SA 3.0
16 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Aug 22, 2020 at 15:02 | comment | added | CygnusX1 |
@MartinC.Martin Just for compilation times interfaces can help too. You add unordered_set only to the actual implementation of the interface, which is not included much. Everywhere else, where you use your class, you use it only via the interface, which does not have said include.
|
|
| May 18, 2017 at 16:17 | history | edited | Jan Hudec | CC BY-SA 3.0 |
added 145 characters in body
|
| May 18, 2017 at 13:54 | comment | added | Martin C. Martin |
PImpl also reduces the initial compile time. For example, if my implementation has a field of some template type (e.g. unordered_set), without PImpl, I need to #include <unordered_set> in MyClass.h. With PImpl, I only need to include it in the .cpp file, not the .h file, and therefore everything else that includes it...
|
|
| Mar 18, 2016 at 13:13 | comment | added | SnakE | To clarify why adding a virtual method breaks the ABI. It has to do with linkage. Linking to non-virtual methods is by name, regardless whether the library is static or dynamic. Adding another non-virtual method is just adding another name to link to. However virtual methods are indices in a vtable, and external code effectively links by index. Adding a virtual method can move other methods around in the vtable without any way for the external code to know. | |
| May 4, 2014 at 15:43 | comment | added | Jan Hudec | @DonalFellows: Adding a public function/method does not break ABI. Adding a virtual method does and does so always unless the user is prevented from inheriting the object (which PImpl achieves). | |
| May 4, 2014 at 10:18 | comment | added | Donal Fellows | Adding a public function/method doesn't have to break the ABI; strictly additive changes aren't breaking changes. However, you have to be ever so careful; the code mediating between the front-end and the back-end has to deal with all sorts of fun with versioning. It all gets tricky. (This sort of thing is why a number of software projects prefer C to C++; it lets them get a tighter grip on exactly what the ABI is.) | |
| Oct 30, 2013 at 23:30 | comment | added | ZijingWu | @James, I should say "add public virtual function in interface" in my comments, but seams I can not edit it now. | |
| Oct 30, 2013 at 23:15 | vote | accept | ZijingWu | ||
| Oct 24, 2013 at 6:57 | history | edited | Jan Hudec | CC BY-SA 3.0 |
added 80 characters in body
|
| Oct 24, 2013 at 6:56 | comment | added | Jan Hudec | @ThomasEding: Difference between P1 and I1 is, that is pimpl case the wrapper method in the public class is non-virtual (and adding even virtual method on the pimpl itself is ok; it's not part of the ABI), while all public methods of an interface are virtual (that's a definition of interface) and those can't be added without breaking the ABI. You are right about P2. | |
| Oct 24, 2013 at 1:30 | comment | added | Thomas Eding | I fail to see the differences between P1 and I1; they both break ABI when adding virtual members or data members. P2 can be said about interfaces as well (define and instantiate the concrete class inside a source file) | |
| Oct 23, 2013 at 23:53 | comment | added | James | How does adding public function break the ABI? | |
| Oct 3, 2013 at 12:37 | history | edited | Jan Hudec | CC BY-SA 3.0 |
added 164 characters in body
|
| Oct 3, 2013 at 12:27 | comment | added | ZijingWu |
Good point. Add public function in Impl class will not break the ABI, but add public function in interface will break ABI.
|
|
| Oct 3, 2013 at 11:37 | history | edited | Jan Hudec | CC BY-SA 3.0 |
say why interface is inferior as decoupling technique
|
| Oct 3, 2013 at 11:17 | history | answered | Jan Hudec | CC BY-SA 3.0 |