Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The pimpl method looks like it ads a level of indirection to every private member access. Is that an issue in practice?


Qt uses it extensively. For big, complex objects like QTextEdit it's probably the least of your concerns, but they do avoid it for simple value types like QPoint.


A good chunk of these questions I'm asking are because I half remember Qt's binary compatibility guidelines from when I did an internship at Trolltech many years ago :) A similar list is here: https://community.kde.org/Policies/Binary_Compatibility_Issu... . It looks like the virtual function restrictions are what I was talking about, that's where pure additions can break compatibility.


If you worked at Trolltech, you almost certainly know more than me. I was just a user of Qt who peeked under the covers occasionally.


It's an issue if the methods on that object are short-lived enough that the overhead of indirection is significant.

It's also an issue if very performance-sensitive routines need to read data from the object. In which case they already know exactly what's in there, so "pimpl" hiding has no benefit in the first place.

Implementations should be hidden if they are likely to change. In other words, there are are non-obvious data or method members and/or it's likely that functionality will be added in the future. These are the high-level architectural situations, not the leaf level ones where you optimize out every cyle possible.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: