On 27-Nov-1999, Rob Walker <[EMAIL PROTECTED]> wrote:
>
> Tyson> hcell is a pointer to a BasicCell. xaccMallocTextCell creates
>
> do we get to know where this BasicCell is at, or is that something
> that "just isn't needed to be known", so we always refer to it with a
> pointer (to its' memory space, right?)?
Always with a pointer. This is what is known as "dynamic allocation".
The other possibility is static allocation (e.g. the same thing without
a *) where it is put on the stack (if it is declared at the start of the
function) or in a global variable somewhere.
> reg-> header_label_cells[DATE_CELL] = hcell;
>
> oh! like the . in perl. i get it now.....
Yep. It's just the "paste" operator for the pre-processor.
C isn't a string based language so you can't do this at run-time, but
you can play little tricks with ## at compile time using the
preprocessor.
> Tyson> at the register data structure, has a field inside it call
> Tyson> header_label_cells. This is an array, and we go to a
> Tyson> particular element of it and assign that element the value
> Tyson> hcell.
>
> ok, no problem. kind of like an array of arrays, or a hash of hashes
> or a hash of arrays or an array of hashes in perl?
Ah, so you are familiar with perl. Good, same concepts apply, C is just
closer to the machine level.
It's kind of like an associative array (the register struct, which we can
index by field name) which has a regular (integer indexed) array as one
of the values. Except that it's probably efficient than even using hashes.
>
> -> means the same as * followed by .
>
> zoom! right over my head! -> means *. I hope I never see a
> *. somewhere, the -> I almost get, the *. I don't.
Well you have to be careful of the operator precedence.
. means field access. This is pretty similar to looking up a particular
field of an associative array to find it's value. You use . on structs.
struct foo {
int a;
int b;
}
void myfunc()
{
foo f;
f.a = 7;
f.b = 3;
printf("%d %d", f.a, f.b);
}
So . is pretty easy, it just means "go to the field of this struct and
get the value".
* means pointer de-referencing. This is just a fancy way of saying
"follow that pointer". To understand * it's good to know about &.
* and & are inverses. & "takes the address" of something.
If you apply & to a value, you will get the address that the value is
stored in.
If you apply * to an address, you get the value that is stored at the
address.
void myfunc2()
{
int x = 7;
int *y;
y = &x; /* y now points to the address x lives in */
printf("%p %d %d", y, *y, x); /* will print 0x34782374 7 7 */
*y = *y + 4;
printf("%p %d %d", y, *y, x); /* will print 0x34782374 11 11 */
}
The exact pointer value you get (0x34782374) depends on what machine you
run it on, and it doesn't really mean anything special. But the address
of a value doesn't change, even though the value might change (like in
this example).
To understand this it's a good idea to draw boxes and arrows. A box
with a number in it is a value. A box with an arrow coming out of it is
a pointer, and it points to wherever the arrow goes. The * operator
does along an arrow (towards the pointy bit) while the & operator goes
away from the pointy bit. Perhaps I'm stretching the analogy now.
> Tyson> Maybe, but it doesn't really matter, the variable is inside a
> Tyson> very small scope (the curly braces) and so it isn't going to
> Tyson> cause any trouble.
>
> oh? that's cool. no memory leaks? I guess just simply redefining a
> variable over and over again will get caught by the compiler's garbage
> collector, right?
In general there is no garbage collector in C compilers. Certainly not
in gcc.
It's only using hcell as a temporary variable. As soon as the curly
braces end, hcell goes away. A good compiler will just re-use the same
location for each hcell.
Of course the memory allocated by xaccMallocTextCell won't go away, but
to see whether that causes a leak you have to look at who is free()ing
that memory. free() is the opposite of malloc().
Of course you could use a garbage collecting library (replaces malloc
with a version that does garbage collection) but I think adding another
dependency for gnucash would be a bit much right now.
> thanks for the help again, this should help a ton while looking
> through the gnucash code.
No problem, you're doing heaps of work on the code so I thought this
would be a completely selfish way to get you to do more ;-)
--
The quantum sort:
while (!sorted) { do_nothing(); }
Tyson Dowd <[EMAIL PROTECTED]> http://tyse.net/
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
