Thomas L. Christensen wrote:
On Wed, 28 Sep 2005 02:07:40 -0500, Logan Shaw
<[EMAIL PROTECTED]> wrote:
Whoa, wait a minute. You didn't say anything about allocating some
space for listdata. If you're going to use listdata as an array of
pointers, then there has to be some memory somewhere that acts as
an array. You need to do something like this:
listdata = MemPtrNew (sizeof (Char *) * totalRecNo);
Thanks a lot. It's working fine now.
I started learn C 10 years ago, and I still have problems with
pointers.
I found this history of the development of the C language to be
an interesting read, and it sort of helps you understand how C's
pointers and arrays came to develop the unusual relationship
that they have:
http://cm.bell-labs.com/cm/cs/who/dmr/chist.html
It talks about how everything in B and BCPL is divided into a cell:
all of memory is one big sequence of cells of all the same size
(the word size of the computer), and pointers are just integer
indices into the sequence of cells. This is very convenient until
you start to realize the limitations of all your datatypes being
exactly the same size. So, C can be viewed as sort of an extended
BCPL where the ability to have cells of different sizes has been
added. You can think of each array in C as a separate BCPL address
space, and each address space with potentially a different cell size.
But the thing is that something has to keep track of what address
space has what cell size, which in C is handled by the type system.
The compiler knows the cell size for each datatype.
At any rate, I think sometimes knowing the story behind something
can make that something's historical baggage more intuitive and
easier to understand and remember.
On a complete tangent, I personally found that taking an intro class
in compilers was one of the most helpful things I did when getting
a CS degree. Not because I have definite plans to write a compiler
(although it could be fun), but because by taking that class I
learned a lot about computer languages. For instance, I never
realized that "." (as in "rect.extent.x") was an operator until I
took that class. I just thought it was "part of the variable name".
Also, ever notice how sometimes you reach a point where you think
you've got most of your program's compile errors eliminated, then
you fix that "last" one and suddenly you have 25 errors instead of
the zero you expected? That's because a compiler processes things
in phases, and if it can't get meaningful results out of one phase,
it can't even try the following phase. But once it can, there comes
that avalanche of irritating, unexpected errors. (And I don't want
to belabor the point, but cryptic compiler messages become easier
to understand as well.) So the point is that there are lots of
things you can ignore if you just want to get some code written,
but once you dive in and start to understand computer languages
under the hood, a whole lot of mysteries get solved, and the world
makes more sense. Whether it's a desirable thing to reach a point
where C starts to seem like it's intuitive and the right way to
do things is another question entirely, though. :-)
- Logan
--
For information on using the PalmSource Developer Forums, or to unsubscribe,
please see http://www.palmos.com/dev/support/forums/
