Member variable with the same name in base and derived?

[marcwentink]

In C++ is it possible to have a class B with a public member int i, and
to have a class D that derives from B, and define in that class D a
member also named i of type int?

[Victor Bazarov]

ma*********@hotmail.com wrote:

In C++ is it possible to have a class B with a public member int i,
and to have a class D that derives from B, and define in that class D
a member also named i of type int?

What do you think? Do you have a problem stemming from this situation?
Or is it just a homework assignment?

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[marcwentink]

Victor Bazarov schreef:

What do you think?

I think it is possible and comparable with have a variable with the
same name in an inner and outer loop in a program. It masks the
original name, it is absolutely stupid to do so, but syntactically it
would be allowed.

Do you have a problem stemming from this situation?
Or is it just a homework assignment?

It's a check question of some selfstudy material I am voluntary reading
at this moment. Actually it is about the same situation in Java. But as
a C++ programmer I wondered if this would also be in C++.

Unfortunately, I am well passed the age in which they would give me a
homework assignment. I used to look a lot better, and even more did the
women and girls of my age back then :-(

[marcwentink]

ma*********@hotmail.com schreef:

Actually it is about the same situation in Java.

And to add: since I am working in Java at my present project, I do not
have a C++ compiler at hand to test the outcome. If you know, you could
give a reply. Otherwise, and I can imagine you think I am a kid too
lazy to do his homework rereading my message, I will test some things
on my home PC this night, no problem.

[Victor Bazarov]

ma*********@hotmail.com wrote:

ma*********@hotmail.com schreef:

> Actually it is about the same situation in Java.

And to add: since I am working in Java at my present project, I do not
have a C++ compiler at hand to test the outcome. If you know, you
could give a reply. Otherwise, and I can imagine you think I am a kid
too lazy to do his homework rereading my message, I will test some
things on my home PC this night, no problem.

http://www.comeaucomputing.com/tryitout/

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[Victor Bazarov]

ma*********@hotmail.com wrote:

Victor Bazarov schreef:

>What do you think?

I think it is possible and comparable with have a variable with the
same name in an inner and outer loop in a program. It masks the
original name, it is absolutely stupid to do so, but syntactically it
would be allowed.

It is not stupid to do so. And I am sure within five minutes I can
come up with a case or two where it would make all the sense to do just
that. I just don't have the five minutes.

>Do you have a problem stemming from this situation?
Or is it just a homework assignment?

It's a check question of some selfstudy material I am voluntary
reading at this moment. Actually it is about the same situation in
Java. But as a C++ programmer I wondered if this would also be in C++.

I don't know how it is in Java. Nor it is really topical to discuss it
here. But in C++ it is allowed.

Unfortunately, I am well passed the age in which they would give me a
homework assignment. I used to look a lot better, and even more did
the women and girls of my age back then :-(

What age is that? I am wondering because I seem to have homework all
the time (although it may not be called that), and I do it, just like
most of my colleagues. Doing one's homework is a necessity; the only
thing defeats the purpose of it is if somebody else is doing it for
you.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[marcwentink]

Victor Bazarov schreef:

It is not stupid to do so.

Two private variable members with the same name perhaps, but public
data members? Keep in mind that it is the public that would make the
variable possibly accessible in the inherited class, and public data
members in a class are a bad thing almost always.

Nevertheless, yes, I always do my homework, I did have some idea what
the answer was, I just wanted an expert like you to give me some
comfirmation that I was thinking right. We must always all do some
homework to keep on track, you're right.

[Victor Bazarov]

ma*********@hotmail.com wrote:

Victor Bazarov schreef:

>It is not stupid to do so.

Two private variable members with the same name perhaps, but public
data members?

You said nothing about the access specifier for the member in class D,
although it is possible to conclude that you were talking of public
in both classes.

Keep in mind that it is the public that would make the
variable possibly accessible in the inherited class, and public data
members in a class are a bad thing almost always.

Again, not true. Were they a bad thing, they would probably be more
difficult to declare/manage in C++. They aren't. Which means, public
members are just fine, AFA the language is concerned.

[..]

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[marcwentink]

Victor Bazarov schreef:

Again, not true. Were they a bad thing, they would probably be more
difficult to declare/manage in C++.

Well not everything you can declare in a language is good design, I
just read somewhere that it's better never to use public members
because:

1. Then you have a consistent interface only existing of functions
2. If you lateron add something to the getter it is all directly in the
code using the class.

That would not apply to really all the applications, but would be a
good rule of thumb, I hope?

[Victor Bazarov]

ma*********@hotmail.com wrote:

Victor Bazarov schreef:

>Again, not true. Were they a bad thing, they would probably be more
difficult to declare/manage in C++.

Well not everything you can declare in a language is good design, I
just read somewhere that it's better never to use public members
because:

1. Then you have a consistent interface only existing of functions
2. If you lateron add something to the getter it is all directly in
the code using the class.

That would not apply to really all the applications, but would be a
good rule of thumb, I hope?

Not to step on any aching corns or something like that, but are you
limiting the view of C++ to only one paradigm, the OOP part of it?

Public data members are fun and useful and have their place in all of
our activities as long as we don't forget what we're doing and for what.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[marcwentink]

Victor Bazarov schreef:

Not to step on any aching corns or something like that, but are you
limiting the view of C++ to only one paradigm, the OOP part of it?

Well, I guess yes I am.

Public data members are fun and useful and have their place in all of
our activities as long as we don't forget what we're doing and for what.

I will keep it in mind, thanks for all your advice.