| Solution ClassXUses a variant of the handle/body idiom. as incluented by coplien (coplien92), handle/body was described as primarily useful for reference counting of a shared implementation, but it also has more-general implementation-hiding uses. for convenience, from now on I'll callXThe "visible class" andXimplThe "pimpl class ." One big advantage of this idiom is that it breaks compile-time dependencies. First, system builds run faster, because using a pimpl can eliminate extra# IncludeS as demonstrated in Items 27 and 28. I have worked on projects in which converting just a few widely-visible classes to use pimpls halved the system's build time. second, it localizes the build impact of code changes because the parts of a class that reside in the pimpl can be freely changed wrong hat is, members can be freely added or removed already ithout recompiling client code. Let's answer the item questions one at a time.
What shoshould goXimpl? Option 1 (score: 6/10): Put all private data (but not functions)Ximpl. This is a good start, because it hides any class that appeared only as a data member. Still, we can usually do better. Option 2 (score: 10/10): Put all nonvirtual private membersXimpl. This is (almost) my usual practice these days. After all, in C ++, the phrase "client code shouldn't and doesn' t care about these parts" is spelled"Private"Inclund privates are always hidden.[4]
[4] memory T in some liberal European countries.
There are some caveats.
You can't hide virtual member functions in the pimpl, even if the virtual functions are private. if the virtual function overrides one inherited from a base class, then it must appear in the actual derived class. if the virtual function is not inherited, then it must still appear in the visible class in order to be available for overriding by further derived classes. Virtual functions shoshould normally be private, should t that they have to be protected if a derived class's version needs to call the base class's version (for example, for a virtualDowrite ()Persistence function ). Functions in the pimpl may require a "back Pointer" to the visible object if they need to, in turn, use visible functions, which adds another level of indirection. (By convention, such a back pointer is usually namedSelf _At peerdirect .) Often the best compromise is to use option 2, and in addition to putXimplOnly those non-private functions that need to be called by the private ones (see the back pointer comments below ). Guideline
|
For widely used classes, prefer to use the compiler-firewall idiom (pimpl idiom) to hide implementation details. use an opaque pointer (a pointer to a declared, but undefined, class) declared"Struct xxxximpl; xxxximpl * pimpl _;"To store private members (including both data and member functions ). |
Option 3 (score: 0/10): Put all private and protected membersXimpl. Taking this extra step to include protected members is actually wrong. protected members shoshould never go into a pimpl, because putting them there just emasculates them. after all, protected members exist specifically to be seen and used by Derived classes, so they aren't nearly as useful if derived classes can't see or use them. Option 4 (score: 10/10 in restricted cases): MakeXimplEntirely the class thatXWocould have been, and writeXAs only the public interface made up entirely of simple forwarding funding (another handle/body variant ). this is useful in a few restricted cases and has the benefit of avoiding a back pointer, because all services are available within the pimpl class. the chief drawback is that it usually makes the visible class useless for any inheritance as either a base or a derived class. DoesXimplRequire a pointer back toXObject? Does the pimpl require a back pointer to the visible object? The answer is: Sometimes, unhappily, yes. After all, what we're doing is (somewhat artificially) splitting each object into two halves for the purposes of hiding one part. Consider: Whenever a function in the visible class is called, usually some function or data in the hidden half is needed to complete the request. that's fine and reasonable. what's perhaps not as obvious at first is that often a function in the pimpl must call a function in the visible class, usually because the called function is public or virtual. one way to minimize this is to use option 4 (abve) judiciously for the functions concerned under hat is, implement option 2 and, in addition, to put inside the pimpl any nonprivate functions that are used by private functions.
|
