functions calling parents in MFC -- how does it work?

[sandup]

Most MFC functions call their parent's functions, like for instance:

void CMyDoc:eleteContents()
{
...do stuff
CDocument:eleteContents();
}

How do they do this? They aren't calling member functions of an *object*, they are calling member functions of a *class*.

And those member functions aren't static either -- I looked.

 

[PerFnurt]

>Most MFC functions call their parent's functions

It's is quite common in C++ in general not only in MFC.

>They aren't calling member functions of an *object*, they are calling member functions of a *class*.

No they are not. They are calling the methods of the instance, not the class. As you pointed out they are not static.

I guess you're confused by the looks of CDocument:eleteContents();
as you interpret that as a static call, which its not because DeleteContents is not a static method.

This is simply the C++ syntax of calling "parent" methods...


/Per

_{"It was a work of art, flawless, sublime. A triumph equaled only by its monumental failure."}

 

[sandup]

Got it!

You can't call a class' method from anywhere, presumably because 'this' doesn't get passed.

I'm curious though -- what are the risks of calling the methods of a class which hasn't been initialized?

By that I mean, normally an instance of a class is constructed, etc., after which its methods are called. But calling a method out of the blue, without any construction? That could backfire, right?

 

[PerFnurt]

>That could backfire, right?

Not really. Unless it is a static method you can't call it "out of the blue". You would have to instantiate it first. Consequently it will be initialized through some constructor.

If the method indeeed is static its not a problem either, because there'd be nothing to initialize. Remember that when you're "inside" a static method there's no such thing as member variables (not even a "this&quot.

>what are the risks of calling the methods of a class which hasn't been initialized?

The only risk is if you don't do the proper initializations in the constructor(s), but since it actually is their responsibility to initialize properly, the risk you're curious about doesn't apply to the context you mention.

In other words - you can trust your C++ to not let you fiddle about too much


/Per

_{"It was a work of art, flawless, sublime. A triumph equaled only by its monumental failure."}

 

[Roudter]

Hey, what's up.

Don't confuse inherited classes with parent classes. CDocument is the base class of MyDoc. MyDoc inherits protected or public functions/variables from CDocument. Inheritance is what allows you to look at 'MyDoc' and see it as a standard 'CDocument.'

A parent is typically an object that opens another object under it's own scope.

For example I could make a 'popup' dialog message within a standard Windows app. The popup would most likely be a child to the parent application. Although CDialog is not a 'CView','CFormView' etc. object. A parent can only access public members of a child object. And there is no 'inheritance' relationship between them.

eat pizza
-Blockhead-

 

[sandup]

>> it will be initialized through some constructor.

Right! Should have figured it out. When the child constructor gets called, it calls the parent's constructor as part of the construction process, so the parent (which is a 'subset' in the child) is properly initialized.

>> A parent can only access public members of a child object.

You mean the other way around Roudter?