C / C++ / MFC

18-Dec-02 10:16

I am ALWAYS exploring and uncovering things in C++, and if by chance I believe I may have discovered something unusual, I revert to the various C++ textbooks for clarification and/or correction.

Here's an example of what I'm talking about: A publicly derived class ought to be able to access "protected" members of its base class. Well this sample exercise I did, doesn't seem to follow that rule.

This is what the compiler said, "error C2248: 'storename' : cannot access protected member declared in class 'Store'."

==============================================

class Store
{
etc.

protected:
string storename; // I should be able to access this member !!!!!!!
int storenum;
};

class Food : public Store
{
public:
Food(string na, int num, string foodItem, float retprice, int invAmt)
: Store(na, num)
{ etc. }

void Msg(string msg)
{
reinterpret_cast<<store*>>(this)->Msg("HQtrs"); // dbl angle brackets needed for msg
cout << '\n' << ((Store*)this)->storename << endl; // error here !!!!!!!

etc.
}
etc.
};

==============================

The reason I'm casting the 'this' pointer to Store is to qualify the data member to which I am referring.

But why is the compiler telling me that this publicly derived class cannot access the protected member of its base class?

Thanks for any help. I appreciate it.

Cool | :cool:

William

Ravi Bhavnani18-Dec-02 10:23

Ravi Bhavnani

18-Dec-02 10:23

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

WREY18-Dec-02 11:03

18-Dec-02 11:03

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.

Cool | :cool:

William

Ravi Bhavnani18-Dec-02 11:23

Ravi Bhavnani

18-Dec-02 11:23

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

WREY19-Dec-02 6:34

19-Dec-02 6:34

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.

Cool | :cool:

William

Alvaro Mendez18-Dec-02 10:33

Alvaro Mendez

18-Dec-02 10:33

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.)

WREY18-Dec-02 10:56

18-Dec-02 10:56

"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

Alvaro Mendez18-Dec-02 12:41

Alvaro Mendez

18-Dec-02 12:41

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.)

WREY19-Dec-02 7:18

19-Dec-02 7:18

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

Alvaro Mendez20-Dec-02 6:05

Alvaro Mendez

20-Dec-02 6:05

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.)

WREY20-Dec-02 7:18

20-Dec-02 7:18

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.)

Cool | :cool:

William

Chris Richardson19-Dec-02 18:59

Chris Richardson

19-Dec-02 18:59

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... Smile | :)

Chris Richardson

Programmers find all sorts of ingenious ways to screw ourselves over. - Tim Smith

WREY19-Dec-02 21:49

19-Dec-02 21:49

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)!!

Cool | :cool:

William

Chris Richardson20-Dec-02 7:03

Chris Richardson

20-Dec-02 7:03

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; // <<A>> Obviously incorrect.
      delete pBase;

      // Just because we use the "this" pointer in the next line of code, doesn't mean we should be able to access the base member.
      // We have taken away our access to the Base protected member, because we have told the compiler that we are now working with
      // a "Base" pointer, instead of a "Derived" pointer.
      // The only "Base" members we have access to, are from the "this" pointer, and once we cast that to a different type of object,
      // in this case "Base", we lose access to those members.
      pBase = (Base*)this;
      pBase->x = 10; // Just as incorrect as the line marked <<A>>
   }
};

Chris Richardson

Programmers find all sorts of ingenious ways to screw ourselves over. - Tim Smith

WREY20-Dec-02 7:24

How to delete an HBITMAP?

20-Dec-02 7:24

Cool!!! Your explanation makes a lot of sense.

Thanks for your reply!

Cool | :cool:

William

Joan M18-Dec-02 9:37

Joan M

18-Dec-02 9:37

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...

Christian Graus18-Dec-02 9:49

Christian Graus

18-Dec-02 9:49

::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

Joan M18-Dec-02 9:59

Joan M

18-Dec-02 9:59

Great, thank you!

Paul M Watt18-Dec-02 9:51

Paul M Watt

18-Dec-02 9:51

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!