By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,234 Members | 2,010 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,234 IT Pros & Developers. It's quick & easy.

Private bases

P: n/a
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 {};

There's nothing in either class to be inaccessible!!! Yet this diagnostic
results. Again, I do understand that this *IS* proper behavior. 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.

Also, just want to let everyone know I'm not trying to solve a particular
real-life problem here. This question is purely academic in nature, so
there is no answer to the oft-asked question "What are you trying to do?".
Just trying to learn, man!!!

Thanks!
Dave
Jul 22 '05 #1
Share this Question
Share on Google+
8 Replies


P: n/a
....

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:

....

I would guess that, in this diagnostic message, inaccessible == private
Jul 22 '05 #2

P: n/a
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.

Jul 22 '05 #3

P: n/a
Gianni Mariani wrote:
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();
};


again i see a lot of similarities between classes/structs and
namespaces.. they must be strict cousins in the inner compiler
representation...

-----[ Domenico Andreoli, aka cavok
--[ http://filibusta.crema.unimi.it/~cavok/gpgkey.asc
---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50

Jul 22 '05 #4

P: n/a

"Dave" <be***********@yahoo.com> wrote in message news:vr************@news.supernews.com...
Exactly WHAT is it that is inaccessible? A constructor? A destructor?


The whole class. The class is termed accessible if an arbitrary invented
member would be accessible.

Here base::foo() (if there were such a foo()) would not be accessible in derived,
so the class "base" is not accessible.
Jul 22 '05 #5

P: n/a

"Domenico Andreoli" <ca***@freemail.it> wrote in message
news:9t**********************@twister1.libero.it.. .
Gianni Mariani wrote:
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();
};


again i see a lot of similarities between classes/structs and
namespaces.. they must be strict cousins in the inner compiler
representation...


Which seems reasonable, doesn't it? :-)

Chris
Jul 22 '05 #6

P: n/a

"Ron Natalie" <ro*@sensor.com> wrote in message
news:3f*********************@news.newshosting.com. ..

"Dave" <be***********@yahoo.com> wrote in message news:vr************@news.supernews.com...
Exactly WHAT is it that is inaccessible? A constructor? A destructor?
The whole class. The class is termed accessible if an arbitrary invented
member would be accessible.

Here base::foo() (if there were such a foo()) would not be accessible in

derived, so the class "base" is not accessible.


class base
{
public:
void foo();
};

class derived: private base
{
};

base::foo() *is* accessible inside of derived! The only case where it would
not be is if it were private, but a private base member is never accessible
in the derived class in *any* case!
Jul 22 '05 #7

P: n/a
On Mon, 17 Nov 2003 21:17:53 -0700, "Dave" <be***********@yahoo.com>
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?
The conversion from derived* to base*, just as it says. That
conversion is only accessible inside derived or using a c-style cast.
I don't understand the question, given that you present the answer
within the question...
Consider this case:

class base {};
class derived: private base {};

There's nothing in either class to be inaccessible!!! Yet this diagnostic
results. Again, I do understand that this *IS* proper behavior. 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.


It's just that there is an implicit conversion from derived* to base*
that is accessible globally if the inheritence is public, but only
within derived if it is private.

Tom
Jul 22 '05 #8

P: n/a
"Domenico Andreoli" <ca***@freemail.it> wrote in message
news:9t**********************@twister1.libero.it.. .
again i see a lot of similarities between classes/structs and
namespaces.. they must be strict cousins in the inner compiler
representation...


Not necessarily, but they are indeed related, in that they
all define a scope. A struct and a class are the same thing
except that they have different default access.

-Mike
Jul 22 '05 #9

This discussion thread is closed

Replies have been disabled for this discussion.