Re: Can you help me summarize all the bad things with global variables?
On Sep 11, 12:00 am, =D6=F6 Tiib <oot...@hot.ee> wrote:
*.h
struct opaque_type_ref {};
void api(opaque_type_ref&, params); // rinse, repeat
*.cpp
namespace // implementation
{
class type : public opaque_type_ref
{
void api(params)
{
// "no this->" zone here.
}
}
type& impl(opaque_type_ref& obj) { return static_cast<type&>(obj); }
}
void api(opaque_type_ref& obj, params)
{
impl(obj).api(params);
}
This example does not solve the major inconvenience of such opaque
pointer style information hiding in general case of C++ class. Pimpl
has to be usually used because in C++ you often want to let the users
to derive from a class (if it hides its internals using compilation
firewall or not does not really matter)... and that means you have to
make virtual interface and protected interface visible.
That doesn't sound right. Pimpl is there exactly because you want to
hide the implementation completely. It kinda implies well separated
server and client roles.
What is the user supposed to derive from? Implementation or exposed
pimpl holder class?
If implementation, what's the purpose of hiding it then? If the
purpose is to have hidden implementation _and_ extension points, isn't
it better to create extension points, instead of hiding implementation
with one hand, and exposing it with the other?
Deriving from holder, OTOH, goes into "prefer containment to
inheritance" rule of thumb. Sure, user can do it, but only to make
holder's public interface bigger, not to change the behavior (pimpl
holder should not have any virtual functions anyhow).
I somehow think, you are making things more complicated than they
should be.
Goran.