How do you like them PIMPLs
-
Pointer to Implementation (PIMPL) pattern can help when working with a dynamic link library as it helps maintain a stable ABI at the cost of an extra indirection in almost every data access. My question is, do you see any merit to using them in a static link library? My gut feeling is no, but maybe you can sway me.
Mircea
-
Pointer to Implementation (PIMPL) pattern can help when working with a dynamic link library as it helps maintain a stable ABI at the cost of an extra indirection in almost every data access. My question is, do you see any merit to using them in a static link library? My gut feeling is no, but maybe you can sway me.
Mircea
Mircea Neacsu wrote:
when working with a dynamic link library as it helps maintain a stable ABI
Not the only use case but that statement sounds like protectionism intended to defeat other programmers. So basically not trusting them. So not something that I engage in.
Mircea Neacsu wrote:
in a static link library
Presuming C++ the library type has nothing to do with it. Over time and hopefully rarely one comes up with a case where there is a 'lot' of information that is needed to fully declare the functionality that a class needs. The normal idiom for doing this is to put it all in the include file. Even though there is no need for the user of the class to be exposed to all of that. So one moves most of that extra information either into the class file itself or even uses a secondary include file (if one finds it emotionally difficult to put it in the class file) which is only included in the class file. Using an actual redirect is not required. It is fluff. And probably only hurts to make maintenance more complicated. A void pointer works as well and then using it is just a cast which has no runtime impact. And if performance is a problem with the redirect, as in an actual measurable impact rather than something that is hypothetical and unrealistic, then seems likely to me that there is something wrong with the design that lead to the class in the first place.
-
Mircea Neacsu wrote:
when working with a dynamic link library as it helps maintain a stable ABI
Not the only use case but that statement sounds like protectionism intended to defeat other programmers. So basically not trusting them. So not something that I engage in.
Mircea Neacsu wrote:
in a static link library
Presuming C++ the library type has nothing to do with it. Over time and hopefully rarely one comes up with a case where there is a 'lot' of information that is needed to fully declare the functionality that a class needs. The normal idiom for doing this is to put it all in the include file. Even though there is no need for the user of the class to be exposed to all of that. So one moves most of that extra information either into the class file itself or even uses a secondary include file (if one finds it emotionally difficult to put it in the class file) which is only included in the class file. Using an actual redirect is not required. It is fluff. And probably only hurts to make maintenance more complicated. A void pointer works as well and then using it is just a cast which has no runtime impact. And if performance is a problem with the redirect, as in an actual measurable impact rather than something that is hypothetical and unrealistic, then seems likely to me that there is something wrong with the design that lead to the class in the first place.
jschell wrote:
Over time and hopefully rarely one comes up with a case where there is a 'lot' of information that is needed to fully declare the functionality that a class needs.
The key word here is "rarely" :). Yes, I know this "God class" anti-pattern and I agree it is something to avoid, but the situation I ran into is just mindless application of a design principle. Every class, no matter how small, had it's entrails taken out and replaced with PIPMLs. Also, for good measure, all classes have only private or protected constructors and objects can be created only through static member factories. Of course, that means all objects live on heap, not on stack and this is again, anywhere and everywhere! What was that saying that to a man with a hammer everything looks like a nail :D
Mircea
-
jschell wrote:
Over time and hopefully rarely one comes up with a case where there is a 'lot' of information that is needed to fully declare the functionality that a class needs.
The key word here is "rarely" :). Yes, I know this "God class" anti-pattern and I agree it is something to avoid, but the situation I ran into is just mindless application of a design principle. Every class, no matter how small, had it's entrails taken out and replaced with PIPMLs. Also, for good measure, all classes have only private or protected constructors and objects can be created only through static member factories. Of course, that means all objects live on heap, not on stack and this is again, anywhere and everywhere! What was that saying that to a man with a hammer everything looks like a nail :D
Mircea
Mircea Neacsu wrote:
is just mindless application of a design principle. Every class, no matter how small, had it's entrails taken out and replaced with PIPMLs.
Which is wrong. Not a unique event though. Someone, I believe on this site, years ago mentioning an application where every class was required to have an interface and factory. Fallacy of that of course is that one then could of course insist that the factory must also have an interface and factory and that then recurses. I have seen multiple times where people suggest that code should be written so code injection can be used at run time to load the various parts of the application. Yet they are unable to explain in realistic terms how that will in any way be cost effective.
-
Mircea Neacsu wrote:
when working with a dynamic link library as it helps maintain a stable ABI
Not the only use case but that statement sounds like protectionism intended to defeat other programmers. So basically not trusting them. So not something that I engage in.
Mircea Neacsu wrote:
in a static link library
Presuming C++ the library type has nothing to do with it. Over time and hopefully rarely one comes up with a case where there is a 'lot' of information that is needed to fully declare the functionality that a class needs. The normal idiom for doing this is to put it all in the include file. Even though there is no need for the user of the class to be exposed to all of that. So one moves most of that extra information either into the class file itself or even uses a secondary include file (if one finds it emotionally difficult to put it in the class file) which is only included in the class file. Using an actual redirect is not required. It is fluff. And probably only hurts to make maintenance more complicated. A void pointer works as well and then using it is just a cast which has no runtime impact. And if performance is a problem with the redirect, as in an actual measurable impact rather than something that is hypothetical and unrealistic, then seems likely to me that there is something wrong with the design that lead to the class in the first place.
