The Dangers of C++

by David Fedor, Newton DTS

Now that the Newton C++ Tools are available, you might be thinking that you
should throw away the Newton Toolkit and just redo everything in C so that
it's faster and smaller. Nothing could be farther from the truth.

With the C++ tools there are no APIs to do user interface, or
communications, or data storage - all that has to be done through the
existing NewtonScript APIs. The C++ tools are for writing algorithms that
have to run at maximum speed, or for porting existing self-contained
routines where you don't have the ability to rewrite them in NewtonScript.

C++ code in a package will take more space than equivalent NewtonScript
code, which can make your application run more slowly since more paging will
be required to access the code. It's possible to create C++ code which is
slower than the NewtonScript code it's replacing. Pick carefully what you
want to move to C, (use the profiler in NTK) or you'll just be wasting your
time.

Writing C++ code for a Newton device is trickier and more error prone than
writing NewtonScript code. Though Newtsbug is provided as a low-level
debugging tool, it's much faster, safer, and efficient to write and debug
your code in NewtonScript, with Newton Toolkit. If you find that your
NewtonScript code isn't fast enough, only then should you optimize it and/or
redesign it. (And don't forget to ask Newton DTS for suggestions!)

All right, if you've gotten to this point, then maybe you're still wanting
to try coding in C. Here are some differences you can expect, and some
things to watch out for.

   * When writing C code, you use pointers. If you mess these up, you can
     write to the wrong locations in memory and possibly corrupt your user
     stores, causing you to lose any data in the device. Or it could cause
     seemingly random problems with other applications on the unit. Worst
     case, if your bad pointer hits exactly the wrong spots, you can put
     some devices in a condition which not even a cold reboot will fix them
     - they'll continuously plead to be returned to the factory for repairs.
     No kidding.
   * Using NewtonScript from C is cumbersome-because C doesn't interact
     easily with the flexibility of frames and dynamic typing. You can work
     with NewtonScript objects from C, but you might be amazed at how much
     code is needed to mimic a single line of NewtonScript.
   * When writing C code, debugging is harder. You can add calls that use
     NSCallGlobalFn, MakeString, and sprintf to print strings to the NTK
     inspector. Or you can use printf to display text in Newtsbug, or simply
     use NewtsBug to walk through the assembly code and stare at memory
     dumps. But this is sort of like cutting your lawn on your hands and
     knees, looking at each blade of grass through a microscope. It makes
     the admittedly imperfect NS Debug Tools look like sheer luxury.
   * When writing C code, you'll spend lots of your time recompiling, then
     switching to NTK to build the package, then downloading it, then
     watching it crash, and repeating the cycle. It makes you incredibly
     appreciative of the integrated NTK build environment and Inspector,
     where you can try out code immediately, and override methods on the fly
     to save tons of development time.
   * When writing C code, you've got to constantly keep track of allocated
     memory and make sure you free it all. Or else you will leak memory from
     the C heap, which is mostly indetectable other than that the unit will
     gradually slow down more and more until it reboots. You can't just quit
     your application like you do on a desktop, that doesn't free up the
     leaked memory.

Ok, so you're still determined. Well, there is a (relatively) good side:
you've got APIs to work directly with NewtonScript frames and other data
structures, and lots of the OS utility functions are callable directly
without going through NewtonScript. Newtsbug can have its advantages; you
can examine objects in the NewtonScript heap and see what's going on
underneath the covers. If you're careful or clever, you can reuse code
you've already written, or squeeze every last millisecond out of your
algorithm's time, leading to new possibilities for your application.

So back up your data, think carefully about how you can write the minimum of
C code, and don't forget that the Newton DTS group is available to answer
any questions about developing for Newton, especially with the Newton C++
Tools.