[C++] Pimpl usage
Author
Say you have a Pimpl'd class, with a static implementation pointer and reference counter. (All instances of the interface object use the same implementation instance)
Does this go by any other name?
Author
Oh, shoot. Glad you brought that up. I was thinking about dynamic allocation of the impl class. Don't need that, do I? [smile]
Thanks for the term reference... Couldn't find it on searches.
Thanks for the term reference... Couldn't find it on searches.
What is your intended use case? Any form of implicit shared state should be very carefully managed.
Author
Application timer. The user is not in a position to accidentally cause damage. I do not use threads, either. (I've haven't used them at all, yet.)
... So you have a pImpl to hide implementation details, of some functionality that only requires one implementation-structure?
You're making it too complicated. Think outside the class.
Just put function descriptions in the header, and implementation, plus file globals that represent the state, in the implementation file. Like they used to do in C. Maybe put it in a namespace or something if you want to keep tidy.
Globals aren't magically "bad". Rather, scoping things more widely than you need to is worse than scoping them exactly as widely as you need to. Data members of a class are scoped more widely than the member functions, so you don't use those (prefer locals to the member functions) when you don't need to (i.e. they don't represent shared state of the object).
Member functions are shared state of a class. Globals are shared state of a module. It's the same thing, really; except that classes are instantiable. If you don't need to instantiate, don't bother.
You're making it too complicated. Think outside the class.
Just put function descriptions in the header, and implementation, plus file globals that represent the state, in the implementation file. Like they used to do in C. Maybe put it in a namespace or something if you want to keep tidy.
Globals aren't magically "bad". Rather, scoping things more widely than you need to is worse than scoping them exactly as widely as you need to. Data members of a class are scoped more widely than the member functions, so you don't use those (prefer locals to the member functions) when you don't need to (i.e. they don't represent shared state of the object).
Member functions are shared state of a class. Globals are shared state of a module. It's the same thing, really; except that classes are instantiable. If you don't need to instantiate, don't bother.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
