Dave wrote:
Hello all,
Suppose that derived inherits privately from base. A base pointer may not
be made to point at a derived object in this case. I understand that is
exactly what is supposed to happen and I understand that this is explicitly
dictated by the Standard.
I'm trying to understand the diagnostic my compiler generates in this case
though:
'type cast' : conversion from 'derived *' to 'base *' exists, but is
inaccessible
Exactly WHAT is it that is inaccessible? A constructor? A destructor?
Consider this case:
class base {};
class derived: private base {};
This means that the only scope that has visibility into base is within
the class "derived".
theoretically you could write :
class derived: private base
{
base * get_base() { return this };
};
A method in derived is able to convert it's pointer to a base.
There's nothing in either class to be inaccessible!!!
"private" inheritance means that only the deriving class has access to
the base class.
Yet this diagnostic results. Again, I do understand that this *IS* proper behavior.
That *IS* the proper behaviour because it is defined like this.
I'm just trying to understand what underlying language mechanism is coming into play
here to enforce this restriction which is, indeed, explicitly requried by
the standard.
The reason "public", "protected" and "private" inheritance is to control
how classes can be used (i.e. what is supposed to be part of the
interface and what is part of the implementation).
Suppose you had to create a class that made "widgets". Now, suppose we
only wanted a very small interface (because your programmers just love
to mess with everything just because it's there and make a mess of
things) ... and suppose making "widgets" is very similar to making
"foobars" and so you can inherit from foobars but you only want a small
amount of the foobars interface exposed.
So - after all this supposing - here is an example:
class make_foobars
{
public:
void check_maker();
void make_stuff();
void foobar_stuff();
};
class make_widgets : private make_foobars
{
public:
using make_foobars::check_maker; // we really want check_maker
void make_stuff();
};
int main()
{
make_widgets widget_maker;
widget_maker.check_maker(); // calls foobar::check_maker()
widget_maker.make_stuff(); // calls make_widgets::make_stuff()
// widget_maker.foobar_stuff(); // Can't do this ... this is foobar.
};
There is another way to do this use pure abstract classes. Notw that
this mechanism is very good for reducing the coupling between
application, interface and implementation even in compiled versions of
the implementation.
// Header file (interface) ..........
class make_widgets
{
public:
virtual ~make_widgets() {};
virtual void make_stuff() = 0;
virtual void check_maker() = 0;
protected :
make_widgets() {};
};
make_widgets * new_widget_maker();
// End header file ...........
// Implementation (.cpp file) ...........
class make_widgets_impl : public make_foobars, public make_widgets
{
void make_stuff();
void check_maker()
{
make_foobars::check_maker();
}
};
make_widgets * new_widget_maker()
{
return new make_widgets_impl;
}
// End of .cpp file
// using widget maker (application).
int main()
{
make_widgets * y = new_widget_maker();
y->make_stuff();
y->check_maker();
delete y;
}
..................
In the example above - the implementation of make_widgets is completly
hidden. There are NO dependantcies other than the ones in the interface
between the implementation and the application.
This is used by COM and various "plug-in" systems however it is also
just good practice to define clearly what the "interface" is.
