|
A derived class can internally access the protected member. You're trying to access it from the global namespace.
What I mean is, an instance of Store could refer to storenum within one of its methods. But storenum isn't accessible outside the class. That would make all protected members essentially public!
/ravi
Let's put "civil" back in "civilization"
http://www.ravib.com
ravib@ravib.com
|
|
|
|
|
Thanks Ravi.
I don't believe I'm accessing the class member from the global namespace. I am accessing it from within the definition of the derived class.
William
|
|
|
|
|
Did you mean to do void Food::Msg(string msg) instead of void Msg(string msg)? The way you have it, Msg() is declared in the global namespace.
/ravi
Let's put "civil" back in "civilization"
http://www.ravib.com
ravib@ravib.com
|
|
|
|
|
Thanks Ravi.
Because I am defining the function 'Msg()' inside the class definition, I don't need to qualify it with the class name and the scope resolution operator. Therefore, the definition of 'Msg()' is correct.
There is also another function named, 'Msg()' defined in the base class 'Store' (which I did not show), which is why I chose to use the 'reinterpret_cast' cast operator to access that specific 'Msg()' function in 'Store'. But that's NOT where the problem is happening. That line gets executed fine, and everything gets done that is supposed to get done in that line. Everything is OK with that line!!!
The problem is with the next line following it, where I'm accessing a protected data member of the base class. That's where the problem is occurring.
Now, according to the rules of C++, a publicly derived class is allowed to access protected data members of its base class, but the compiler is not agreeing, and that's the line where the disagreement is pointing to.
William
|
|
|
|
|
public derivation:
- public members (of base class) are made public
- protected members are made protected
- private members are not accessible
protected derivation:
- public members are made protected
- protected members are made protected
- private members are not accessible
private derivation:
- public members are made private
- protected members are made private
- private members are not accessible
I hope this answers it. You were trying to access a protected member as if it were public.
Regards,
Alvaro
Well done is better than well said. -- Benjamin Franklin
(I actually prefer medium-well.)
|
|
|
|
|
"A member of a derived class can use the public and protected members of its base class as if they were declared in the derived class itself."
The C++ Programming Language (page 305)
Bjarne Stroustrup
William
|
|
|
|
|
 Oops, I went back to look at your poorly formatted sample and realized that Msg() is a member of the Food class. That explains why you're confused about the compiler error.
WREY wrote:
The reason I'm casting the 'this' pointer to Store is to qualify the data member to which I am referring.
You don't need to that in this case, since you don't have a storename in the Food class. If you did, the proper way to qualify it is via the scope-resolution operator: Store::storeName.
Still, I don't really understand why the compiler doesn't account for the scope of the variable when the cast is made. It may just be a compiler bug.
Regards,
Alvaro
Well done is better than well said. -- Benjamin Franklin
(I actually prefer medium-well.)
|
|
|
|
|
I am one of those people who ranks neatness and readability high on his list when writing code. I do NOT believe in sloppiness and poorly formatted code. You saw poorly formatted code because that's what CodeProject showed, but that's NOT the way it appears when looking at my code.
Also, I try to limit only those portions of the sample code that are relevant, which means a lot of times you will see, "etc." for parts that are missing and are not relevant.
You suggestion is a good one (which does work), but I could have used just "storename", (and not "Store::storename" as you have shown), and it would have worked just fine also.
In this exercise, I PURPOSELY want to use the 'this' pointer; I PURPOSELY want to qualify the 'this' pointer with the class name whose object it is supposed to be pointing to, and then by way of such a pointer, have it access a protected data member of the base class from the derived class.
Two things I'm trying to accomplish in this exercise:
1) Access protected members of the base class by way of the 'this' pointer (which means qualifying it).
2) Specifically pick which member(s) of either class (base or derived) I might want to access (if by chance BOTH classes have members with the SAME name) ultimately providing me with a way I might be able to transcribe the code using templates.
William
|
|
|
|
|
WREY wrote:
I am one of those people who ranks neatness and readability high on his list when writing code. I do NOT believe in sloppiness and poorly formatted code. You saw poorly formatted code because that's what CodeProject showed, but that's NOT the way it appears when looking at my code.
Relax William. I was commenting on the fact that it was poorly formatted here. And as a matter of fact, it's not just CP's fault, because you could have used the pre tags around the code to help keep it well formatted. I'm sure you understand that it could have made a significant difference to those reading your post.
At any rate, it's good to hear about yet another developer who cares about neatness and readibility. My experience has been that we're a rare breed.
WREY wrote:
You suggestion is a good one (which does work), but I could have used just "storename", (and not "Store::storename" as you have shown), and it would have worked just fine also.
In this exercise, I PURPOSELY want to use the 'this' pointer; I PURPOSELY want to qualify the 'this' pointer with the class name whose object it is supposed to be pointing to, and then by way of such a pointer, have it access a protected data member of the base class from the derived class.
Yes, I realized that it was basically just an exercise. I just wanted to make sure you knew the proper way to distinguish between variables of the same name across derived classes.
WREY wrote:
1) Access protected members of the base class by way of the 'this' pointer (which means qualifying it).
I see, so you wanted to use this as an obvious way to say, "storename is a member of this class", sort of like what the m_ prefix does for the MFC classes.
WREY wrote:
2) Specifically pick which member(s) of either class (base or derived) I might want to access (if by chance BOTH classes have members with the SAME name) ultimately providing me with a way I might be able to transcribe the code using templates.
Again, the scope resolution operator is the way to go, which you can also use with "this": this->Store::storename;
I think Chris may have hit upon the actual reason why the compiler does not like what you're trying to do. And I must confess that I also thought of it myself, but just wasn't sure. I thought there was a possibility of it being a compiler bug; perhaps one only found in VC6.
Regards,
Alvaro
Well done is better than well said. -- Benjamin Franklin
(I actually prefer medium-well.)
|
|
|
|
|
Thanks for your reply.
I believe you have provided me with what I was looking for (at least for the time being); the use of "this->storename" from the derived class. (Again, I don't need to qualify the data member with its class name. That would only be necessary if ambiguity becomes an issue.)
William
|
|
|
|
|
It's not working because to the compiler, what you are trying to do is equivalent to this:
class Base
{
protected:
int x;
};
class Derived : public Base
{
public:
void Function()
{
Base b;
b.x = 10;
}
};
Obviously this is incorrect. And, when you tell the compiler that "this" is a "Store" pointer by casting it, you are doing the exact same thing I just showed in this example. Now, if you want to "qualify" the class to which you are referring, to remove an ambiguity, as in the following example, you should use the scope resolution operator.
class Base
{
protected:
int x;
};
class DerivedBase : public Base
{
protected:
double x;
};
class Derived2 : public DerivedBase
{
public:
void Function()
{
Base::x = 10;
DerivedBase::x = 10.0;
}
};
Maybe I'm wrong, but this is how it seems to me...
Chris Richardson
Programmers find all sorts of ingenious ways to screw ourselves over. - Tim Smith
|
|
|
|
|
Thanks for your reply.
I can see your point for needing the class name and the scope resolution operator. It's needed because there are two data members with the SAME name in two different classes, and the only way you can avoid ambiguity in that situation is by specifically qualifying each data member with their respective class name followed by the scope resolution operator.
That is NOT the case in my example. In my sample, only the base class has that particular data member name (there's no ambiguity present). Moreover, the base class is instantiated through the derived class constructor initializer list.
The thing is, I can use just the protected data member name by itself (from a derived class function, even without the base class name and scope resolution operator) and it would be correct!! But if I were to try and access the base class by way of its own 'this' pointer (and qualify it as the base class through casting), suddenly, the compiler starts complaining if I were to try and access a protected member of the base class.
This is where I am. The compiler obviously isn't happy, and it's complaining. I need to know what is there in the rules of C++ that's causing the compiler to report a syntactical error (other than what it's already saying), when another part of the rule is definitely saying differently.
I don't see where I'm violating anything by using the base class 'this' pointer to access one of its protected data member from a derived class.
Maybe I'm suffering from tunnel vision here, but this is the kind of stuff that makes C++ so interesting (or frustrating)!!
William
|
|
|
|
|
The first example illustrates why you can't access the protected base member. The second example was only illustrating the way to avoid ambiguities you had discussed with Alvaro Mendez. Let me see if I can show a better example of why the compiler is complaining.
class Base
{
protected:
int x;
};
class Derived : public Base
{
public:
void Function()
{
Base * pBase = new Base;
pBase->x = 10;
delete pBase;
pBase = (Base*)this;
pBase->x = 10;
}
};
Chris Richardson
Programmers find all sorts of ingenious ways to screw ourselves over. - Tim Smith
|
|
|
|
|
Cool!!! Your explanation makes a lot of sense.
Thanks for your reply!
William
|
|
|
|
|
hello,
I've noticed that when I set a bitmap on a CStatic the previous bitmap don't get destroyed, then I would like to know how to delete the previous image from memory.
Thank you in advance.
NOTE:
Please don't laugh too much while answering...
|
|
|
|
|
::DeleteObject will delete any GDI object such as a HPen or HBitmap. If you're using MFC and the bitmap is in a CBitmap, then it's going to be deleted for you.
Joan Murt wrote:
Please don't laugh too much while answering...
I'm not laughing - I might laugh if you ask this again and again over the next few months, as that would indicate an inability to learn. But every single API, every single keyword, every single bit of knowledge we have, someone had to show us, either indirectly through a web site or book, or directly as I am now. There is no shame in wanting to learn, there is shame in not being willing to be told.
Christian
No offense, but I don't really want to encourage the creation of another VB developer.
- Larry Antram 22 Oct 2002
C# will attract all comers, where VB is for IT Journalists and managers - Michael
P Butler 05-12-2002
Again, you can screw up a C/C++ program just as easily as a VB program. OK, maybe not
as easily, but it's certainly doable. - Jamie Nordmeyer - 15-Nov-2002
|
|
|
|
|
|
You should only delete a bitmap if you created it. When you create a memory DC, it automatically has a default bitmap in it that windows will manage for you, I believe the same is true for the CStatic that you are talking about.
In order to delete a HBITMAP use ::DeleteObject(HBITMAP). There is one catch though, the bitmap cannot be selected into a memory DC otherwise the function will fail. So that is why you need to select the old bitmap into the memory DC before you call DeleteObject on the bitmap. Or you can delete the memory DC before you delete the bitmap, that will effectively unselect the bitmap from the memory DC as well.
Good Luck
Build a man a fire, and he will be warm for a day
Light a man on fire, and he will be warm for the rest of his life!
|
|
|
|
|
|
Hi everyone,
i have an existing code that i need to revise, in this code i used gotoxy() function to set cursor locations in my console. When i try to compile this code in Visual C++ 6.0 (console application) i get an error "error C2065: 'gotoxy' : undeclared identifier" why am i getting this? i'm sure that the conio.h is in my system and that it is included in my source code. any idea why i get this error? and what will be the solution for this?
Thanks/Regards
Sidney
Thanks/Regards
Sidney
|
|
|
|
|
Moving the code over from Borland? It's been a really really long time since I had to manipulate the cursor position of the console, so I can't remember if there's any C++ standard stuff to do it, but in Win32, you can use SetConsoleCursorPosition, which the C++ routine would probably call anyways.
Chris Richardson
Programmers find all sorts of ingenious ways to screw ourselves over. - Tim Smith
|
|
|
|
|
Not actually moving, i just dont have a Borlang compiler right now and i was wondering if i can compile my code using Microsoft Visual C++ 6.0. Well ok let me try replacing the gotoxy with the SetConsoleCursorPosition, Thanks Chris! I really appreciate your help
Thanks/Regards
Sidney
|
|
|
|
|
No problem , I hope it works for ya!
Chris Richardson
Programmers find all sorts of ingenious ways to screw ourselves over. - Tim Smith
|
|
|
|
|
Hi,
Quick question that is probably easy to implement.
I have an MFC Grid control as part of a dialog application. Problem is once it has focus, the user cannot tab-key out of it.
What needs to be done to enable this?
Some example code would be very much appreciated.
Thanks,
-Chris
|
|
|
|
|
Here's what I came up with for the above problem. Is there a more efficient or nicer way to solve this problem?
typedef struct _List
{
int data;
_List* pNext;
_List(int d) : data(d), pNext(0) {}
} List;
int main(int argc, char* argv[])
{
List* pList = new List(0);
List* pTemp = pList;
for (int i = 1; i < 10; i++)
{
pTemp->pNext = new List(i);
pTemp = pTemp->pNext;
}
pTemp = pList;
while (pTemp)
{
DEBUGF("%i", pTemp->data);
pTemp = pTemp->pNext;
}
DEBUGF("reversing...");
List* p1 = pList;
List* p2 = pList->pNext;
p1->pNext = 0;
while (p2)
{
List* p3 = p2->pNext;
p2->pNext = p1;
p1 = p2;
p2 = p3;
}
pList = p1;
pTemp = pList;
while (pTemp)
{
DEBUGF("%i", pTemp->data);
pTemp = pTemp->pNext;
}
return 0;
}
Todd Smith
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
