Why is this allowed?

[blangela]

A student of my class submitted a solution where a derived class had
the exact same member data declared as the abstract base class that it
inherited from. Surprisingly, MS VS 2005 did not complain about this.

Assuming this is "standard c++", why would the language allow this?

I have not had a chance to experiment to find out if it is only
allowed when the data members are private (which is what I suspect).

Also, it it allowed because the base class is an abstract base class?

What is the benefit of this "feature"? In other words, why would a
programmer want to do this?

Cheers,

Bob

 

[Pete Becker]

A student of my class submitted a solution where a derived class had
the exact same member data declared as the abstract base class that it
inherited from. Surprisingly, MS VS 2005 did not complain about this.

Assuming this is "standard c++", why would the language allow this?

I have not had a chance to experiment to find out if it is only
allowed when the data members are private (which is what I suspect).

Also, it it allowed because the base class is an abstract base class?

What is the benefit of this "feature"? In other words, why would a
programmer want to do this?

Names are defined in scopes, and there's nothing that prohibits
defining the same name in multiple scopes. It's often useful.

// global scope:
void f();
int i;

// namespace scope:
namespace ns
{
void f();
int i;
}

namespace ns
{
namespace nested
{
void f();
int i;
}

// class scope:
struct S
{
void f();
int i;
};

struct D: S
{
void f();
int i;
};

In all cases, you can refer to the thing you actually want with
appropriate qualifiers:

f(); // global name
ns::f(); // namespace name
ns::nested::f(); // namespace name
&S::f; // class member name
&D::f; // class member name

Same thing for data members.

As to why, there's no good reason to prohibit it. In particular,
private data in a base class shouldn't interfere with names in derived
classes. And, more generally, if you don't care about the data members
in a base class, there's no reason to require your derived class to
avoid their names.

 

[Puppet_Sock]

As to why, there's no good reason to prohibit it. In particular,
private data in a base class shouldn't interfere with names in derived
classes. And, more generally, if you don't care about the data members
in a base class, there's no reason to require your derived class to
avoid their names.

Indeed, if the data is private, there is good reason
not to require the derived class to avoid those names.
Or to put it more forcefully, there is good reason for
the derived class to have no awareness of the private
parts of the parent class. It is object oriented. That
way, the parent class can change those details, and the
derived class won't break.
Socks