C / C++ / MFC

3-Jul-01 12:05

The wrong function is getting called. I believe it goes like this:

class foo {
public:
inline foo() {
bar();
}
virtual bar();
};

class fooplus : public foo {
public:
inline fooplus() : foo() {};
virtual bar();
}

The problem is that when I instantiate fooplus, foo::bar gets called instead of fooplus::bar.

I believe that if you said
fooplus fooinst;
fooinst.bar();
then it would call foo::bar and then fooplus::bar.

I'm trying to use more of the power of C++, but stuff like this is making me want to just use it like C with member functions like I used to. Frown | :(

Alex Griffing3-Jul-01 12:16

3-Jul-01 12:16

I'm working around it by putting everything except the call to the overridden function in a new member function (Init). This way it works, but both constructors have the same code.

foo() {
init(); //foo::init()
bar(); //foo::bar()
}

fooplus() {
init(); //foo::init();
bar(); //fooplus::bar();
}

Ben Burnett3-Jul-01 13:40

Ben Burnett

3-Jul-01 13:40

You should never call virtual functions within a ctor, the result is undefined.

-Ben

---------
On the topic of code with no error handling -- It's not poor coding, it's "optimistic" Wink | ;)

Alex Griffing3-Jul-01 13:57

3-Jul-01 13:57

Is the alternative to say:
pMyThing = new Thing();
pMyThing->Init();
all the time? That would suck.

Stan Shannon3-Jul-01 14:40

Stan Shannon

3-Jul-01 14:40

Well, first off, polymophism is NOT the answer to every programming problem you might confront. So maybe for whatever it is you are trying to achieve you SHOULD be using C functions. I have no idea why you are defining your contstructors as inline, or what effect it has on the virtual calls. I've never seen that done before, and have no clue why you would need it. However, consider that the virtual table does not exist prior to the construction of the object. How would you expect a virtual call from the constructor to work? Obviously, as stated, it is undefined.

You do not need to call an "Init" function after the ctor, because the object should initialize itself IN the ctor. Each derived class, will probably have unique initialization demands which do not warrent a virtual call anyway.

If I really needed a "virtual constructor" (re: Stroustrup)which is essentially what you are trying to achieve here I would do something like this:

class foo {
foo(); //default constructor.
foo( foo& rfoo ); // copy constructor.
virtual foo* Clone(){ return( new foo( *this )); }

virtual bar();

};

class fooplus : public foo {

fooplus();
fooplus( fooplus& rfooplus );

virtual fooplus* Clone(){ return( new fooplus( *this )); }

virtual bar();

};

In this way, an object can always return a properly initialized copy of itself on demand.

Alex Griffing3-Jul-01 16:33

3-Jul-01 16:33

Thanks for your reply!
I don't think I've gone polymorphism happy (in the everything-looking-like-a-nail sense.)
My vision is to have code that says:

pObject = new MyFoobarizedZonkObject();

and I want the initialisation of the foobarized part of it to take place as a virtual function because there might also be a MyFoobarizedBlipObject whose foobarized part might be initialized a bit differently from MyFoobarizedZonkObject's. I guess you could take all the code that makes the objects foobarized and put it into its own class and use containment rather than inheritance, but this might or might not be natural. Does this make sense?

I don't know what I was thinking with the inline constructor except that I've just started using inline functions a lot and I'm used to putting 'inline' whenever I don't have the function defined in the cpp file. I know this isn't how it goes though and that 'inline' shouldn't be before the constructor declaration.

Saying 'virtual' before the 'bar' declaration in the fooplus class is also redundant, right?

I guess I don't quite see how the 'virtual constructor' would apply because I don't have a correctly initialized object to start with. What would the code look like to use it?

Thank you,
Alex

Stan Shannon3-Jul-01 17:38

Stan Shannon

3-Jul-01 17:38

The entire point of construction is to give an object the opportunity to uniquely initialize itself. Usually the way it is done is something like this:

class foo1
{
foo1() { m_x = 0; m_y = 0; m_y = 0; }
};

class foo2 : public foo1
{
// call the base class' constructor as you construct the derived class.
foo2(): foo1() { m_xx = 0; m_yy = 0; mm_zz = 0; }

};
class anotherfoo : public foo1
{
anotherfoo (): foo1() { m_xx = 0; m_yy = 0; mm_zz = 0; }
};

Now, both base and derived classs are properly initialize when you declare a foo2:

foouser::UseFoo()
{
foo2 footoo;
anotherfoo fooalso;

// or

foo2* pfootoo = new foo2();
anotherfoo* pfooalso = new anotherfoo();
};

So, I guess I don't really see what your issue is with initializing the objects. At this point, polymorphism has not even become
an issue.

The "Virtual Constructor" is simply a way to ensure a correct object is created if you do something like this:
(As I typically keep my objects in paramatarized lists, this technique comes in handy)

foouser::UseFoo()
{
foo2 footoo;

DoSomethingElse( &footoo );
}

foouser::DoSomethingElse( foo* pfoo )
{
foo* pfooX = pfoo->Clone();// pfoo creates a copy of a foo2, or anotherfoo, if it was called with that.

//// use pfooX.
//// Obviously, for this example, I could have just used pfoo as is, but say I wanted to store a foo2 in its
//// current state for whatever reason, this is very convenient. The point is that my Constructor is now capable of
//// polymorphic behavior.
delete pfooX;
};

I believe you are technically right about the derived virtual bar() being redundant. But the rule of thumb, I think, is once virutal, always virtual. You can keep yourself out of a lot of trouble by keeping that in mind.

3-Jul-01 21:12

Yep, it sucks, but that's just the way it is.

Who can give me a help????

Malcolm McMahon3-Jul-01 23:24

Malcolm McMahon

3-Jul-01 23:24

I've been caught out by this one in the past. What happens is that the object, although allocated enough space for a fooplus is first initialised as a foo object, then the foo constructor is called. At that point the foo virtual method table is in effect. Only once the foo constructor exits does the fooplus intialisation occur and the VMT switches to the one containing fooplus::bar. This behaviour is logical, fooplus::bar might refer to variables in fooplus that the foo constructor doesn't know to initialise.

How you get arround it depends on details of what you're doing that we don't know. If you're really getting into polymorphic programming you'll often find the best solution is static factory routines which give you a uniform access to constructors e.g.

<br />
<br />
class foo {<br />
protected:<br />
    foo(...) {<br />
     };<br />
public:<br />
    static foo *factory( ... );<br />
    virtual void bar();<br />
    };<br />
<br />
class fooplus : public foo {<br />
protected:<br />
     fooplus( ... ) : foo(plus) {<br />
      }<br />
<br />
public:<br />
    static foo *factory( ... );<br />
    virtual void bar;<br />
  ..<br />
<br />
   };<br />
<br />
foo *foo::facory( ... ) {<br />
  foo *f = new foo( ...);<br />
  f->bar();<br />
  return f;<br />
  }<br />
<br />
foo *fooplus::factory ( ...) {<br />
  fooplus *f = new fooplus ( ...);<br />
  f->bar;<br />
  return f;<br />
  }<br />
<br />

Because the factory methods are static and have the same signature you can store pointers to them in a table of variations on foo.

3-Jul-01 11:26

How can I detect the state of a network card???????
I have try to use MIB_IFROW structure in PSDK, but don't know why, the only result I can get from this strcture is: unreachable.
WHy?
Any other solution?????
Send me a email if possible....

cheers
m0th@dcs.shef.ac.uk

multiple active windows in MDI?

Jake Palmer3-Jul-01 11:15

Jake Palmer

3-Jul-01 11:15

Is it possible for more than one window to be "active" in an MDI app? I ask because I need to have a toolbar send commands to all open views, not only the one active view. Possible? Cool | :cool:

thanks,

Jake

3-Jul-01 12:19

I don't think you want to do that by trying to make all open views active, even if you could. I assume you are using the Document/View architecture. If it were me, I would utilize your app's CDocument class, via the UpdateAllViews() call, to achieve that result, passing a hint to each view as to what toolbar command was sent. I have also seen people use the Main frame window to communicate commands to each open view - but I prefer CDocument. Just a suggestion.

Jake Palmer3-Jul-01 14:31

Jake Palmer

3-Jul-01 14:31

Thanks for the help - The UpdateAllViews is exactly what I want to do, except I can't get it to work for some reason. I'm basically doing something like:

The View catches the toolbar message, and a handler function is called. This function does some stuff and ends with: GetDocument()->UpdateAllViews(this, ENUM_VALUE1, NULL). Ideally this should call the OnUpdate() function of every open View, assuming I have an enum that allows ENUM_VALUE1.

However, OnUpdate never gets called. Passing "this" prevents it from being called on the active view, and nothing happens to the inactive views. I can't figure out why it's not doing anything Dead | X|

thanks again,
Jake

Ben Burnett3-Jul-01 18:45

Ben Burnett

3-Jul-01 18:45

Unless all the views in your application share the same document, this approach will not work. You must first get a list of all the open documents, and then update all their respective views.

It might look something like the following;

CWinApp * pApp = AfxGetApp ();
ASSERT_VALID ( pApp );

// Iterate through the application's document templates list
POSITION posTemplate = pApp->GetFirstDocTemplatePosition ();

while ( NULL != posTemplate ) {

	// For each document template object...
	CDocTemplate * pTemplate = pApp->GetNextDocTemplate ( posTemplate );
	ASSERT_VALID ( pTemplate );
	ASSERT_KINDOF ( CDocTemplate, pTemplate );

	// Iterate through the template's document list
	POSITION posDocument = pTemplate->GetFirstDocPosition ();		

	while ( NULL != posDocument ) {

		// For each document object...
		CDocument * pDocument = pTemplate->GetNextDoc ( posDocument );
		ASSERT_VALID ( pDocument );
		
		// update the document's views
		pDocument->UpdateAllViews ( NULL, ENUM_VALUE1, NULL );

	}

}

-Ben

---------
On the topic of code with no error handling -- It's not poor coding, it's "optimistic" Wink | ;)

#realJSOP4-Jul-01 1:06

#realJSOP

4-Jul-01 1:06

Send the messages by way of the associated documents instead.