>
Yes, it is frustrating, but there are ways around it. Most people I
know who use C++ on the Palm figure out ways around using virtual
functions in the launch codes that don't provide globals. However,
this absolutely involves some very careful coding, and GREATLY
lengthens the time it takes to bring a product to market.
Most virtual function effeciency gains are realized when writing UI
code. Generally, UI code is not used in launch codes (except in an
alarm), so you are cool there.
Another excellent place that could possibly use virtual functions is
in the data architecture for your program, but you don't want to do
that. Many launch codes will also need to get to that data. I tend to
use templates to get the benefits of code re-use, but it is a pain to
be careful about this.
A nice place to use virtual functions would be to use a stream to
support beaming, but again, beam receive might happen when globals
aren't around. One way around this that I am working on is to use the
Palm Stream functions to stream a beam receive into a temporary file,
then launch the app and use a C++ stream to actually import the
stream into the database.
There is theoretically a way to make globals available during the
various launch codes. It is difficult, and nobody that I know of has
actually succeeded in making it work, but it involves looking at what
the Palm System source code does during a SysUIAppSwitch, and then
recreating that functionality in the startup code. Metrowerks
provides the source for its startup code library, which you would
need to edit and build a new startup library.
For each launch code that you want to support, you have to decompress
the binary source, fix up all the intersegment jumps in the code (if
you want to call code in other segments), make sure there is enough
space for your own global space, possibly initialize these globals,
then save off the A5 register and point it to the new global space
you created. Then reverse some of that as the launch code exits. You
don't want to do this for all launch codes, as it might really slow
the Palm down.
The problem, which is common to all launch codes, is what if the
current running process has taken up so much dynamic ram space that
you can't create enough memory to do what you want to do. If you are
allocating a chunk for your globals, that would take up much more
dynamic space then just dealing with the launch code normally. There
is a similar issue in terms of the amount of stack space that the
current running process is taking up, but that is a different
discussion.
I suspect the Palm engineers know that this is a pain, and I imagine
they are working with Metrowerks to try to fix it. One possible
solution, as you might guess, is to have the startup code allocate a
separate chunk for virtual tables and for C++ exception handling
needs, and then fix the compiler to use this space instead of the
global space. You won't get globals in this case, but you WILL get
the benefits of OO. Again, the problem is going to be determining
which launch codes to do this on and how to deal with low memory
situations, because if it happens across the board, it might slow
things down.
Thanks,
Shannon
>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.
>
>RE:
>
>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.
>
> >Hi
> > I was wondering if people who are coding their Palm apps in C++,
> >tend to use virtual functions (and how) or tend to shy away from them
> >due to their use of Global data.
> >
> >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
> >
> >
> >Declan O'Reilly
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Hands High Software
Award winning software for the Palm(tm) Computing platform
<http://www.handshigh.com/>
[EMAIL PROTECTED]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
