While I agree it would be better if the compiler just supported virtual functions in all situations, the point I make in my book is that this is what we have to live with, so here are some alternatives to consider. None of them are great, but there's little we can do about that. If you're porting multi-platform code, for example, you may find that relaunching the app to restore its globals is the only way to do it. You do what you have to do.... Eric Giguere author of "Palm Database Programming", see http://www.ericgiguere.com ----- Original Message ----- > Date: 20 Dec 1999 10:39:05 -0800 > From: "B. Flaumenhaft" <[EMAIL PROTECTED]> > Subject: Re: C++ Virtual Functions > > This is an extremely frustrating issue. It's still not clear to me why this > has to be the case. I can't think of a reason (other than convenience, > laziness, or poor initial design) why globals should have to be used for > vtable pointers. > > The three issues suggested below are all completely unacceptable. > > 1. this is akin to rejecting the OO approach (because without inheritance, > languages are merely object-based, not object-oriented) > > 2. this is akin to saying that you don't need language support to do OO > programming. I fully agree, from a theoretical point of view. There's no > reason why you can't write OO programs in BASIC or Cobol. There is, > however, a reason why people *don't*. > > 3. this defeats the whole point of the launch code mechanism. > > This thing has driven me very near to craziness in the last few months. > > >In 'Palm Database Programming' Eric Giguere suggests either > >1) avoid them > >2) simulate them > >3) relaunch app ( not supported by palm) if Global variables are not > >available e.g. find function
