Calling a parent class's protected function from another instance of the class
JoshG
use implicit conversion, i.e. '(pkOtherObject->*&Child::Query)()'. -mod }
Hey Guys,
I just want to throw a quick question out there,
Can I do the following (syntax is not 100% checked, but you will get
the gist)
class Parent
{
protected:
bool Query();
};
class Child: public Parent
{
public:
DoSomething(Parent* pkOtherObject)
{
if (pkOtherObject->Query())
// ... Etc
}
};
When I compile the above code under VS it complains that Query is an
unaccessible protected member.
Though I was under the impression that this would have been ok...
If this is infact wrong, could someone please point out somewhere
where this language rule is defined, as there are obviously subtleties
I'm not familiar with here.
Cheers
Josh
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Neil Butterworth
> use implicit conversion, i.e. '(pkOtherObject->*&Child::Query)()'. -mod }
I fail to see how this is a valid response from a moderator under the
published moderation guidelines.
Neil Butterworth
red floyd
> class Parent
> {
> protected:
> bool Query();
>
> };
>
> class Child: public Parent
> {
> public:
> DoSomething(Parent* pkOtherObject)
> {
> if (pkOtherObject->Query())
> // ... Etc
> }
>
> };
>
> When I compile the above code under VS it complains that Query is an
> unaccessible protected member.
> Though I was under the impression that this would have been ok...
>
> If this is infact wrong, could someone please point out somewhere
> where this language rule is defined, as there are obviously subtleties
> I'm not familiar with here.
>
No. You can't access *another* object's parent's protected members,
only your own.
I don't have chapter and verse right now, but an alternative
workaround without the
horrendously evil syntax the mod suggested would be:
class Parent
{
protected:
bool Query();
};
class Child: public Parent
{
public:
DoSomething(Parent* pkOtherObject)
{
if (pkOtherObject->callParent())
// ... Etc
}
private:
bool callParent()
{
return Query();
}
};
Andrei Alexandrescu
>> { Responders please note that C++ type rules do allow the call when rewritten to
>> use implicit conversion, i.e. '(pkOtherObject->*&Child::Query)()'. -mod }
>
> I fail to see how this is a valid response from a moderator under the
> published moderation guidelines.
>
> Neil Butterworth
Thank you for doing this, Neal. It's the second time in a week I'm
seeing downright participation from the mods in the form of moderator
comments.
Moderators, please be modular: read a post, approve it, and if you feel
like it then write your own post answering it. Before long there'll be
an entire out-of-band exchange in the form of moderator comments and
responses to them.
Andrei
Alf P. Steinbach
>> { Responders please note that C++ type rules do allow the call when rewritten to
>> use implicit conversion, i.e. '(pkOtherObject->*&Child::Query)()'. -mod }
>
> I fail to see how this is a valid response from a moderator under the
> published moderation guidelines.
I was the one who added that note.
I think your reference to the published guidelines is not what you're really
trying to convey, because the note is 100% in compliance with the literal
guidelines. I think that you simply think there have been too many mod notes
lately and that moderators should not willy-nilly add notes just because
"hurray, there's something I know, I'll add a note with the answer". Of course
all the active moderators could answer most if not all of the questions of that
nature that pop up here, so we're absolutely /not/ doing that.
But at least I disagree with the /abundance/ of notes, the frequency, I think
it's too high, and I choose to believe that rather than some technicality which
doesn't hold up on examination, you mean the same as me, that they're too
frequent now -- but that you happened to choose a bad example in that respect.
For this note is not in any way an answer to the OP's problem, or a note added
on the spur of the moment without due consideration of what it could and can
achieve versus the desire for totally "transparent" operation of the group.
It is an in my view important additional and little-known relevant fact. I
believe it's important and relevant because earlier threads on that theme have
nearly always got off on the wrong foot, with a host of articles, the majority
and I believe in most such threads all the articles, assuming that C++ rules
could not allow something like the mod note exemplified. And when that happens
in the majority of articles in a thread, not to say all the articles, then at
least the causal reader will most likely get an incorrect impression.
Having the relevant facts at hand from the beginning is, I strongly believe,
beneficial for a thread about an issue where earlier threads have show the need
for such facts.
Cheers & hth.,
- Alf
Alf P. Steinbach
> On Feb 19, 8:21 am, JoshG <Inbi...@gmail.com> wrote:
>> class Parent
>> {
>> protected:
>> bool Query();
>>
>> };
>>
>> class Child: public Parent
>> {
>> public:
>> DoSomething(Parent* pkOtherObject)
>> {
>> if (pkOtherObject->Query())
>> // ... Etc
>> }
>>
>> };
>>
>> When I compile the above code under VS it complains that Query is an
>> unaccessible protected member.
>> Though I was under the impression that this would have been ok...
>>
>> If this is infact wrong, could someone please point out somewhere
>> where this language rule is defined, as there are obviously subtleties
>> I'm not familiar with here.
>>
>
> No. You can't access *another* object's parent's protected members,
> only your own.
Sorry, with the most general interpretation (not that "you can't do that with
that syntax" but that "you can't do that except by suppressing type checking")
that's incorrect, that's what the mod comment exemplified: namely that you can,
even without explicit casting or any such suppress-the-typechecking measures.
I think[1] the mod comment was to prevent the misconception that "you can't"
from propagating as a false assumption in the thread, as it has in earlier threads.
On the other hand, ideally it would IMO have been Very Nice if you couldn't.
> I don't have chapter and verse right now, but an alternative
> workaround without the
> horrendously evil syntax the mod suggested would be:
Heh, anyone suggesting that as a workaround, or for that matter suggesting any
purely technical workaround for this design problem, should IMHO be thoroughly
spanked and then forced to drink Seagram's tonic water (bleh!)[2]! :-)
> class Parent
> {
> protected:
> bool Query();
>
> };
>
> class Child: public Parent
> {
> public:
> DoSomething(Parent* pkOtherObject)
> {
> if (pkOtherObject->callParent())
> // ... Etc
> }
> private:
> bool callParent()
> {
> return Query();
> }
>
> };
Uhm, again sorry, but that won't work without a cast since pkOtherObject is a
Parent* pointer, while the callParent method resides in the Child class. But it
is in what IMO is the right direction, namely some re-design, making that
desired functionality available where it's needed. However, without knowing much
more about the OP's application it's difficult to suggest re-designs.
The C++ rules made that design problem very manifest, so, why are the rules the
way they are for the case of 'pkOtherObject->Query()'?
Well, if that was allowed then if 'pkOtherObject' was actually a pointer to a
SomeoneElsesDerived object, then all one would have to do to gain access to the
innards of SomeoneElsesDerived class would be to derive a class from Parent. And
then 'protected' wouldn't count for much... Which would generally be ungood,
because then one could easily /inadvertently/ break class invariants and
introduce dependencies on internal implementation details (that might change).
And this rationale was, as I understand it, much of what the OP asked for.
But hey, as the mod exemplified, with member pointers the ability to easily,
inadvertently circumvent 'protected' /is/ effectively the situation.
And what this means is that when creating a design based on 'protected' access
one needs to be acutely aware that it does not provide much of a protection
against member pointers, where there is what amounts to a big hole in the C++
type system -- i.e., one is then designing for use of a limited subset of the
language (which is nearly always the case, but ordinarily what's assumed to not
be used is casts or even more dirty use of the preprocessor and the like, not
just use of what one might think are type safe high level language features).
Cheers & hth.,
- Alf
Notes:
[1] Actually, I'm fairly sure about that. ;-)
[2] Schweppe's Indian Tonic Water, on the other hand, is quite good, IMHO. And
it reportedly turns blue under ultra-violet light. If true, that seems to
suggest that what at first sight seems to be obviously true about something
might be different when that something is viewed in a different light! <g>
Neil Butterworth
I haven't edited any of the above so as not to be accused of
partiality. But really!
a) I found what you said almost incomprehensible, unlike your posts on
technical subjects. Perhaps you need to sit down and breath deeply?
b) The role of a moderator is pretty simple:
1. filter out spam, irelevancies & obscenity
2. ..hmm, there is no number 2
It is not the role role of a moderator to act as some sort of pre-
filtering guru. So please stop doing it.
Balog Pal
>"Neil Butterworth" <nbutterw...@googlemail.com>
>>"Alf P. Steinbach" <al...@start.no> wrote:
>>{ Responders please note that C++ type rules do allow the call when
>>rewritten to
>> use implicit conversion, i.e. '(pkOtherObject->*&Child::Query)()'. -mod }
> a) I found what you said almost incomprehensible, unlike your posts on
> technical subjects. Perhaps you need to sit down and breath deeply?
I much disagree with that. The explanation is sound and makes sense.
It's up to judgement which force is stronger. I'd probably wrote a separate
message in the case. But that doesn't make Alf's thinking any less
comprehensible.
> b) The role of a moderator is pretty simple:
> 1. filter out spam, irelevancies & obscenity
> 2. ..hmm, there is no number 2
Yea. The first bullet could be summed as 'noise', that eats resources of
writers and readers as well.
Moderator actions that help to contain noise (through i.e. pointing to
earlier instance of the same starting question, FAQ-like places, non-facts
in the question, etc) are good and helping. Yust like this current note
motivated by experience on earlier instances of the same thread.
> It is not the role role of a moderator to act as some sort of pre-
> filtering guru. So please stop doing it.
I'm not aware of any "filtering" happened. Unless you consider some
people's chance to *just* post the note's content without any additional
info got prevented. I'd think that risk is theoreric and not a big loss even
if real.
JoshG
{ edits: sig & banner removed. please don't quote extraneous material. -mod }
Hey guys,
To be completely honest, I was aware that moderators in this group are
allowed to add little notes to the posts if they know about the area.
Whats more, I beleive the note that was added was actually a good
clarification of my post, that should have deterred people from
thinking "Well of course, why would you even expect that to work?" I
expect it to work, because of the exact reason he noted - because if I
was dealing with child objects, then it'd be fine!
Thanks for the information guys, I now understand that it is a semi-
plugged type safety and encapsulation issue in C++.
Thanks to Alf for the helpful note, and the explanation of the
rationale behind these rules!
Not so many thanks to the guys who hijacked my thread to complain
about the great job he's done.
Josh