473,287 Members | 1,904 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,287 software developers and data experts.

"this" and "base"

Question: Why can't you access a private inherited field from a base
class in a derived class? I have a *theory* of how this works, of
which, I'm not completely sure of but makes logical sense to me. So,
I'm here for an answer (more of a confirmation), hopefully.

First let me say that I know people keep saying; it doesn't work
because the member "is a private". I believe there's more to it than
just simply that...

Theory: You inherit, not only the members in the base class, but the
whole base class itself - as an object, which contains the members.
Therefore, this has *almost* the same effect as if you declared a base
class manually in the derived class as shown in figure 1:

public class Base
{
private string name;
// more members and methods...
}

public class Derived
{
// instance members:
Base baseField;
private uint numbersField;
}
and if you tried to access the private member "name" of baseField
inside a method in the derived class like: baseField.string, you would
get an error, because it is private and can only be accessed within
it's own class scope (container). And similarly, this holds true for
why you cannot access a private base member in a derived class in a
"base and derived class relationship". This theory makes good, perfect
logical sense (to me) of why you *cannot* access a private member
*because* you're trying to access a private member outside of the
container where it is defined. And also, the keyword "base" then
essentially becomes the reference to that base class object. Just like
"this" is a reference to an instantiated object. And this(not the
keyword), also, essentially means this: when you derived a class from a
base class, you then have "two" classes within one unit, and this unit
is the drived class.

To elaborate some more, let's throw in a problematic problem:
So with that just said, How then does the keywords "base" and "this"
refer to the same "data" (fields etc..) and "code" (methods etc..) - at
times - when they *are* two different objects which are within one unit
- the derived class (this == drived class object AND base == base class
object)? But, they also, sometimes can refer to different "code" (when
you override). I believe the reason is because when you do not override
a virtual method in the base class, the compiler (or early binding)
makes both objects "this" and "base" point to the same "code". But in
the case where you do override a virtual method in the derived class,
the compiler (or early bindig) makes each object (this AND base) point
to different methods (code).

Sorry for the long post but I decided to try to make some sense out of
this after I encountered a problem ( which I could've posted instead of
all this but decided against; in fear of being told "it's becase it's a
private". That alone, I believe is not a clear answer, but a vague one.
But anyways, I am going to include this code:

public class Car
{
private uint odometer;
}

public class RacingCar : Car
{
private uint odometer;

public static void Main( )
{
}
}

The above compliles with no errors and only two warnings (no
assignement). But the problem I see is this: Why do I *not* get an
error from the compiler, along the lines of "error: redefinition of
Car.odometer", because I inherit a member with the exact same signature
that's also declared in RacingCar? And as I said; someone looking at
this would probably say "because Car.odometer is private and it's
inside its own class scope". And it's true that it's within its own
scope, which would prove my theory of two seperate class objects
(through "base" and "this") exist when you have a derived class, but,
that alone is not enough of an answer to me so I wrote all this for
some enlightment and confirmationt. What's your take or view on this?

Jan 23 '06 #1
7 2181
> What's your take or view on this?

It doesn't work because the member "is a private".
But your explanation would be a good way to put it to beginner
programmers who had never heard of OO...

Jan 23 '06 #2
"What keeps you from accessing a Private member" is more of what you are
looking for I think? You know why (because it is private) but you are not
sure what (compiler, runtime, something else) is keeping you from accessing
it. Well.. It is both the Compiler and Runtime engine that keep you from
doing it. If you tried to compile something that accessed a private member
you would get a compile error. During runtime the access level (public,
private, protected) gets checked to determine if you are allowed access to
it.

You can verify this by doing the following:

Create a Control Library with a public method in it and compile it.
Create an application that calls the public method in this Control Library
and compile it.
Run the application and it should work fine.
Now go back to your Control Library and change that method to Private and
recompile _JUST_ the Control Library.
Now run the application.
It should give you an exception because the runtime engine is doing access
level checking!

When you Override it does not change what base points to. The reason you
would use base in the first place would be to get to the "original" version
of a method that you have overridden.

Lastly, the reason that your last example compiles and works fine is because
of Scope. When a member is declared makes all the difference. If you had a
member function in your derived class you could have a local variable called
odometer in it as well and it would work just fine!

So.. To answer your question in 3 words.. "Because it's Private!" :-)

Hope this helps ya out!
"relient" <xl***************@gmail.com> wrote in message
news:11********************@g43g2000cwa.googlegrou ps.com...
Question: Why can't you access a private inherited field from a base
class in a derived class? I have a *theory* of how this works, of
which, I'm not completely sure of but makes logical sense to me. So,
I'm here for an answer (more of a confirmation), hopefully.

First let me say that I know people keep saying; it doesn't work
because the member "is a private". I believe there's more to it than
just simply that...

Theory: You inherit, not only the members in the base class, but the
whole base class itself - as an object, which contains the members.
Therefore, this has *almost* the same effect as if you declared a base
class manually in the derived class as shown in figure 1:

public class Base
{
private string name;
// more members and methods...
}

public class Derived
{
// instance members:
Base baseField;
private uint numbersField;
}
and if you tried to access the private member "name" of baseField
inside a method in the derived class like: baseField.string, you would
get an error, because it is private and can only be accessed within
it's own class scope (container). And similarly, this holds true for
why you cannot access a private base member in a derived class in a
"base and derived class relationship". This theory makes good, perfect
logical sense (to me) of why you *cannot* access a private member
*because* you're trying to access a private member outside of the
container where it is defined. And also, the keyword "base" then
essentially becomes the reference to that base class object. Just like
"this" is a reference to an instantiated object. And this(not the
keyword), also, essentially means this: when you derived a class from a
base class, you then have "two" classes within one unit, and this unit
is the drived class.

To elaborate some more, let's throw in a problematic problem:
So with that just said, How then does the keywords "base" and "this"
refer to the same "data" (fields etc..) and "code" (methods etc..) - at
times - when they *are* two different objects which are within one unit
- the derived class (this == drived class object AND base == base class
object)? But, they also, sometimes can refer to different "code" (when
you override). I believe the reason is because when you do not override
a virtual method in the base class, the compiler (or early binding)
makes both objects "this" and "base" point to the same "code". But in
the case where you do override a virtual method in the derived class,
the compiler (or early bindig) makes each object (this AND base) point
to different methods (code).

Sorry for the long post but I decided to try to make some sense out of
this after I encountered a problem ( which I could've posted instead of
all this but decided against; in fear of being told "it's becase it's a
private". That alone, I believe is not a clear answer, but a vague one.
But anyways, I am going to include this code:

public class Car
{
private uint odometer;
}

public class RacingCar : Car
{
private uint odometer;

public static void Main( )
{
}
}

The above compliles with no errors and only two warnings (no
assignement). But the problem I see is this: Why do I *not* get an
error from the compiler, along the lines of "error: redefinition of
Car.odometer", because I inherit a member with the exact same signature
that's also declared in RacingCar? And as I said; someone looking at
this would probably say "because Car.odometer is private and it's
inside its own class scope". And it's true that it's within its own
scope, which would prove my theory of two seperate class objects
(through "base" and "this") exist when you have a derived class, but,
that alone is not enough of an answer to me so I wrote all this for
some enlightment and confirmationt. What's your take or view on this?

Jan 23 '06 #3
C.C. (aka Me):
<quote>worte stuff</quote>

Ok, So I thought about what you said and I wrote something new, which,
ironically makes sense also:P

Tell me what you think about it:

When you inherit from a base class, you inherit their members
regardless of their access modifiers. If they are public members, you
can refer to them with the "this" keyword and "base" keyword (that is
if you do not hide them as will be explained next). But you can hide
their base implementation and implement your own version by declaring
members, in the derived class, with the same name and signature as the
base members you wish to hide. Then, the "this" keyword refers to your
implementation instead of the base implementation (which are totally
seperate now). But you can still gain access to the original
implementation by using the "base" keyword.

If the base members are private members, they can only be refered to
with the "base" keyword because of their scope (defined within base
class scopeness).

Jan 23 '06 #4
relient <xl***************@gmail.com> wrote:

<snip>
If the base members are private members, they can only be refered to
with the "base" keyword because of their scope (defined within base
class scopeness).


No. Using "base" doesn't give you any more access to the members. If
they're private, then only code in that type (and in nested type) can
get at them.

Basically, just because you've inherited the members doesn't mean you
have access to them - inheritance and access are separate concepts.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Jan 23 '06 #5
The answer is much simpler than you imagine. As a programmer, you should
know it already. When you write a program, you create a set of business
rules that determine how the program operates, what it does, how it does it,
when it must, can and cannot perform certain operations, what the exceptions
to the general rules are, etc. These rules are enformced with conditional
logic in the program. If you don't write the code correctly, the rules are
broken.

These rules generally follow a certain logic, but ultimately, they are
arbitrary. The creator of the program is the arbiter of the rules.

The same applies to a programming language (or any language for that
matter). There are business rules that govern how a programming language is
compiled and run, and these rules are determined by the author of the
compiler and the programming language. These decisions are arbitrary.

For example, since C# and VB.Net compile to the same MSIL, why can't you use
pointer arithmetic in VB.Net? Well, one might imagine all sorts of
apparently logical reasons, but when it comes down to it, the answer is that
the developers of VB.Net made a decision that VB.Net would not support
pointer arithmetic. It is entirely possible that they could have decided
otherwise. They have even talked about supporting it in future versions. But
the point is that, ultimately, they made a decision to create the rule in
that fashion, and that they made it arbitrarily.

Here's another example: In some states, the legal drining age is 18. In
others, the legal age is 21. Why? Because the legislatures of these states
made the decision that the rule would be thus.

Rules and law are not so much about right and wrong, subjectively logical
versus subjectively illogical, but simply because a decision must be made.
Without rules, there is chaos.

The answer to your question is therefore, the reason that you cannot access
a private inherited field in a base class from a derived class is that the
developers of the CLI made an arbitrary decision that the rule should be
thus. You can imagine all you like what the logic behind it is. However, no
matter how much you speculate, you will never know unless they tell you. And
even if you know, it changes nothing. The rule remains. It is what it is.
Until the creator decides otherwise.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
Who is Mighty Abbott?
A twin turret scalawag.

"relient" <xl***************@gmail.com> wrote in message
news:11********************@g43g2000cwa.googlegrou ps.com...
Question: Why can't you access a private inherited field from a base
class in a derived class? I have a *theory* of how this works, of
which, I'm not completely sure of but makes logical sense to me. So,
I'm here for an answer (more of a confirmation), hopefully.

First let me say that I know people keep saying; it doesn't work
because the member "is a private". I believe there's more to it than
just simply that...

Theory: You inherit, not only the members in the base class, but the
whole base class itself - as an object, which contains the members.
Therefore, this has *almost* the same effect as if you declared a base
class manually in the derived class as shown in figure 1:

public class Base
{
private string name;
// more members and methods...
}

public class Derived
{
// instance members:
Base baseField;
private uint numbersField;
}
and if you tried to access the private member "name" of baseField
inside a method in the derived class like: baseField.string, you would
get an error, because it is private and can only be accessed within
it's own class scope (container). And similarly, this holds true for
why you cannot access a private base member in a derived class in a
"base and derived class relationship". This theory makes good, perfect
logical sense (to me) of why you *cannot* access a private member
*because* you're trying to access a private member outside of the
container where it is defined. And also, the keyword "base" then
essentially becomes the reference to that base class object. Just like
"this" is a reference to an instantiated object. And this(not the
keyword), also, essentially means this: when you derived a class from a
base class, you then have "two" classes within one unit, and this unit
is the drived class.

To elaborate some more, let's throw in a problematic problem:
So with that just said, How then does the keywords "base" and "this"
refer to the same "data" (fields etc..) and "code" (methods etc..) - at
times - when they *are* two different objects which are within one unit
- the derived class (this == drived class object AND base == base class
object)? But, they also, sometimes can refer to different "code" (when
you override). I believe the reason is because when you do not override
a virtual method in the base class, the compiler (or early binding)
makes both objects "this" and "base" point to the same "code". But in
the case where you do override a virtual method in the derived class,
the compiler (or early bindig) makes each object (this AND base) point
to different methods (code).

Sorry for the long post but I decided to try to make some sense out of
this after I encountered a problem ( which I could've posted instead of
all this but decided against; in fear of being told "it's becase it's a
private". That alone, I believe is not a clear answer, but a vague one.
But anyways, I am going to include this code:

public class Car
{
private uint odometer;
}

public class RacingCar : Car
{
private uint odometer;

public static void Main( )
{
}
}

The above compliles with no errors and only two warnings (no
assignement). But the problem I see is this: Why do I *not* get an
error from the compiler, along the lines of "error: redefinition of
Car.odometer", because I inherit a member with the exact same signature
that's also declared in RacingCar? And as I said; someone looking at
this would probably say "because Car.odometer is private and it's
inside its own class scope". And it's true that it's within its own
scope, which would prove my theory of two seperate class objects
(through "base" and "this") exist when you have a derived class, but,
that alone is not enough of an answer to me so I wrote all this for
some enlightment and confirmationt. What's your take or view on this?

Jan 23 '06 #6
Why do you think so much about things that are so clear?

The people who have designed the language have defined that a private
member can only by accessed from within the class. Even derived classes
have no access to private base-class members.

Have you thought about this: what if your theory was the one used to
design a language? It would mean that making a different between
private, protected and public is of no sence because then you can create
a inheriting class that makes all private members public.

So, just take it as it is: make your private members protected (this is
why something like protected exists).

Have you ever asked someone why 3 = 2 + 1. I can easily write a theory
that says that 2 + 1 = 4.

Greetz,
Rudderius

relient wrote:
Question: Why can't you access a private inherited field from a base
class in a derived class? I have a *theory* of how this works, of
which, I'm not completely sure of but makes logical sense to me. So,
I'm here for an answer (more of a confirmation), hopefully.

First let me say that I know people keep saying; it doesn't work
because the member "is a private". I believe there's more to it than
just simply that...

Theory: You inherit, not only the members in the base class, but the
whole base class itself - as an object, which contains the members.
Therefore, this has *almost* the same effect as if you declared a base
class manually in the derived class as shown in figure 1:

public class Base
{
private string name;
// more members and methods...
}

public class Derived
{
// instance members:
Base baseField;
private uint numbersField;
}
and if you tried to access the private member "name" of baseField
inside a method in the derived class like: baseField.string, you would
get an error, because it is private and can only be accessed within
it's own class scope (container). And similarly, this holds true for
why you cannot access a private base member in a derived class in a
"base and derived class relationship". This theory makes good, perfect
logical sense (to me) of why you *cannot* access a private member
*because* you're trying to access a private member outside of the
container where it is defined. And also, the keyword "base" then
essentially becomes the reference to that base class object. Just like
"this" is a reference to an instantiated object. And this(not the
keyword), also, essentially means this: when you derived a class from a
base class, you then have "two" classes within one unit, and this unit
is the drived class.

To elaborate some more, let's throw in a problematic problem:
So with that just said, How then does the keywords "base" and "this"
refer to the same "data" (fields etc..) and "code" (methods etc..) - at
times - when they *are* two different objects which are within one unit
- the derived class (this == drived class object AND base == base class
object)? But, they also, sometimes can refer to different "code" (when
you override). I believe the reason is because when you do not override
a virtual method in the base class, the compiler (or early binding)
makes both objects "this" and "base" point to the same "code". But in
the case where you do override a virtual method in the derived class,
the compiler (or early bindig) makes each object (this AND base) point
to different methods (code).

Sorry for the long post but I decided to try to make some sense out of
this after I encountered a problem ( which I could've posted instead of
all this but decided against; in fear of being told "it's becase it's a
private". That alone, I believe is not a clear answer, but a vague one.
But anyways, I am going to include this code:

public class Car
{
private uint odometer;
}

public class RacingCar : Car
{
private uint odometer;

public static void Main( )
{
}
}

The above compliles with no errors and only two warnings (no
assignement). But the problem I see is this: Why do I *not* get an
error from the compiler, along the lines of "error: redefinition of
Car.odometer", because I inherit a member with the exact same signature
that's also declared in RacingCar? And as I said; someone looking at
this would probably say "because Car.odometer is private and it's
inside its own class scope". And it's true that it's within its own
scope, which would prove my theory of two seperate class objects
(through "base" and "this") exist when you have a derived class, but,
that alone is not enough of an answer to me so I wrote all this for
some enlightment and confirmationt. What's your take or view on this?

Jan 23 '06 #7
>> 2 + 1 = 4.

It does, if 1 inherits from 2, and its private count property isn't
made public.

Jan 24 '06 #8

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

21
by: Alex Martelli | last post by:
I hesitate a bit to post this, but... on the Italian Python NG, somebody was asking whether there was any way to convert an integer number x into a string which represents it in an arbitrary base N...
14
by: Ernst Murnleitner | last post by:
Dear Readers, Is it possible to forbid conversion from this or use of this in general except where it is explicitly wanted? Reason: I changed my program from using normal pointers to...
11
by: Joseph Turian | last post by:
Fellow hackers, I have a class BuildNode that inherits from class Node. Similarly, I have a class BuildTree that inherits from class Tree. Tree includes a member variable: vector<Node>...
9
by: Player | last post by:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello all. I am in the process of teaching myself C# and I think I am doing OK. I have learnt how to how to call the right constructor of a...
4
by: Gecko | last post by:
I noticed that every time I override a class member, the intellisense behavior is to automatically add a call to the base class of the overridden member such as: public override void...
2
by: Wade | last post by:
Hi all, We have created some "Base" class pages for our WebForms and UserControls. For instance, when we create a WebForm called "WebForm1.aspx", instead of inheriting from "System.Web.UI.Page"...
2
by: qazmlp1209 | last post by:
class base { public: base() { } base(int number) { priNumber = number ;
3
by: Rob | last post by:
I have these classes (elided methods): class Base { public: Base(string name) {...} }; class Derived : public Base {
3
by: Ravi | last post by:
Is this the correct way to think of "base class"? The "base class" is a class from which other classes are derived. The "base class" will never be derived from another class.
2
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 7 Feb 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:30 (7.30PM). In this month's session, the creator of the excellent VBE...
0
by: MeoLessi9 | last post by:
I have VirtualBox installed on Windows 11 and now I would like to install Kali on a virtual machine. However, on the official website, I see two options: "Installer images" and "Virtual machines"....
0
by: DolphinDB | last post by:
The formulas of 101 quantitative trading alphas used by WorldQuant were presented in the paper 101 Formulaic Alphas. However, some formulas are complex, leading to challenges in calculation. Take...
0
by: Aftab Ahmad | last post by:
So, I have written a code for a cmd called "Send WhatsApp Message" to open and send WhatsApp messaage. The code is given below. Dim IE As Object Set IE =...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
0
by: marcoviolo | last post by:
Dear all, I would like to implement on my worksheet an vlookup dynamic , that consider a change of pivot excel via win32com, from an external excel (without open it) and save the new file into a...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.