Gmail Calendar Documents Reader Web more »
Recently Visited Groups | Help | Sign in
Google Groups Home
Inherit, same named methods
There are currently too many topics in this group that display first. To make this topic appear first, remove this option from another topic.
There was an error processing your request. Please try again.
flag
  3 messages - Collapse all  -  Translate all to Translated (View all originals)
The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
 
From:
To:
Cc:
Followup To:
Add Cc | Add Followup-to | Edit Subject
Subject:
Validation:
For verification purposes please type the characters you see in the picture below or the numbers you hear by clicking the accessibility icon. Listen and type the numbers you hear
 
Michael D. Berger  
View profile  
 More options Nov 5, 4:50 am
Newsgroups: comp.lang.c++
From: "Michael D. Berger" <m_d_berger_1...@yahoo.com>
Date: 04 Nov 2009 17:20:01 GMT
Local: Thurs, Nov 5 2009 4:50 am
Subject: Inherit, same named methods
Given:

class A : protected B
{
...

}

Can can the two classes have inline,
non-virtual methods with the same name?

What if the inheritance is public?

Thanks,
Mike.


    Reply    Reply to author    Forward  
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Pete Becker  
View profile  
 More options Nov 5, 5:03 am
Newsgroups: comp.lang.c++
From: Pete Becker <p...@versatilecoding.com>
Date: Wed, 04 Nov 2009 12:33:27 -0500
Local: Thurs, Nov 5 2009 5:03 am
Subject: Re: Inherit, same named methods

Michael D. Berger wrote:
> Given:

> class A : protected B
> {
> ...
> }

> Can can the two classes have inline,
> non-virtual methods with the same name?

Yes.

> What if the inheritance is public?

Doesn't matter. Try it.

--
   Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of
"The Standard C++ Library Extensions: a Tutorial and Reference"
(www.petebecker.com/tr1book)


    Reply    Reply to author    Forward  
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Kaz Kylheku  
View profile  
 More options Nov 5, 8:17 am
Newsgroups: comp.lang.c++
From: Kaz Kylheku <kkylh...@gmail.com>
Date: Wed, 4 Nov 2009 20:47:36 +0000 (UTC)
Local: Thurs, Nov 5 2009 8:17 am
Subject: Re: Inherit, same named methods
On 2009-11-04, Michael D. Berger <m_d_berger_1...@yahoo.com> wrote:

> Given:

> class A : protected B
> {
> ...
> }

> Can can the two classes have inline,
> non-virtual methods with the same name?

In a sense yes, in a sense no.

Suppose B has one or more member functions called foo. (There may be more
than one due to overloading).

If A also introduces a member called foo, then this identifier will
shadow all of those functions in B.

So, as you correctly suspect, there is in fact a kind of conflict between same
names in a base and derived class, which is resolved by shadowing:  the
presence of a name in the derived class suppresses the inheritance of that
/name/ from the base class into the scope of the derived class.  (But it does
not suppress the inheritance of the /things/ which are named, just the names!
C++ has two kinds of inheritance going on: inheritance of class-scoped
identifiers from one class to another, and inheritance of actual entities like
member functions, data members, and member types).

So for instance if you have

  int B::foo(int);
  int B::foo(double);

and inside A you have

  int A::foo(unsigned long);

then when you call ``a.foo(3)'' on an A object a, only A::foo(unsigned long) is
considered by overload resolution. It's as if the two B::foo functions did not
exist; the expression simply does not see them.

But if A did not have a member called foo, then A::foo will nicely refer to the
set of overloaded functions from B. I.e. the B::foo name is inherited into A,
becoming visible in A's class scope.

In either case, the B functions are reachable via scope resolution:
a.B::foo(...).

You can promote the B functions into A with using directives, so that they are
considered together with A::foo(unsigned int) as candidates for overload
resolution:

   class A : public B {
   public:
      using B::foo; // This is as if A itself now defined those functions.
      int foo(unsigned long);
   };

You don't get to cherry-pick the foo's from B: using B::foo gets
you all of them (you're importing the name, not the functions,
which you have already inherited!)

There can't be a clash, either. If one of the B::foo function is
foo(unsigned long), you're out of luck. Or if B has a foo name which
refers to something other than a function, you're also out of luck: because
then you're asking to have an A::foo which refers to the function
int A::foo(unsigned long), as well as some non-function entity also,
which is a form of overloading not supported in C++.

> What if the inheritance is public?

These public, private and protected specifiers determine access control.
Access control does not determine what is visible and what is inherited,
but what is accessible.

Access control is a way of specifying that if when some visible identifiers are
referenced from certain scopes, then a diagnostic message is required from the
compiler. It's like a glass case: you can see something, but you can't
touch it.


    Reply    Reply to author    Forward  
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
End of messages
« Back to Discussions « Newer topic     Older topic »

Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
©2009 Google