Tyson,
thank you for your help. It is most useful.
>>>>> On Sat, 27 Nov 1999 21:34:33 +1100, Tyson Dowd <[EMAIL PROTECTED]>
>>>>> said:
>> and up at the beginning of the file, I see these lines:
>>
>> #define HDR(NAME) \
>> { \
>> BasicCell *hcell; \
>> hcell = xaccMallocTextCell(); \
reg-> header_label_cells[NAME##_CELL] = hcell; \
>> }
>>
>> now, what does that do? I thought that I understood what a #DEFINE
>> did, but I guess not. Aren't they kinda like search and replaces for
>> the preprocessor? I thought that they were. But now this blows that
>> theory out of the water.
>>
>> I continue with my thoughts. NAME is the argument which gets passed
>> into the function. I get that. hrmm... BasicCell is the type of the
>> variable *hcell. I don't get the *, but owell. Does that mean that
>> this is really a pointer to the variable hcell, which really exists
>> outside of this function? _this_ function? _which_ function?
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?)?
Tyson> this cell and assigns it to hcell (probably a nice new one,
Tyson> since malloc is the C function call that allocates memory, so
Tyson> xaccMallocTextCell probably calls malloc).
ok.
>> xaccInitSplitRegister ??? I don't see a hcell in
>> xaccInitSplitRegister. so hcell gets the return value of
>> xaccMallocTextCell... and that is... in src/register/textcell.c,
>> line 52, okay, it returns cell. does that mean that cell is the
>> name of the cell which just got initialized?
Tyson> hcell is the name of the variable that just got initialized.
ok.
Tyson> It points to the cell that was allocated but might not be
Tyson> initialized yet. In this case I suspect it is initialized in
Tyson> the xaccMallocTextCell function.
ok.
>> okay, so hcell is a cell (or the name of the cell?) which is
>> getting initialized. that's cool. for instance, in one point,
>> hcell could be the first header cell. hrmm... ok, NAME shows up
>> on that last line, and it ends up being
reg-> header_label_cells[DATE##_CELL] = hcell; right? now, I _really_
>> don't have a clue with "all that arrow stuff". what does that last
>> line do?
Tyson> ## joins two things together, so you end up with
reg-> header_label_cells[DATE_CELL] = hcell;
oh! like the . in perl. i get it now.....
Tyson> The data structure reg, which I assume is something that points
I _thought_ that there was a reg struct somewhere. I couldn't find it
though, so that threw me off, since I couldn't _know_ I was right or
not.
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?
-> 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.
Tyson> So -> is the same as de-referencing (following) the pointer
Tyson> (that's what * does) and then going to a particular field (.)
Tyson> Note that * is used in C both as an operator to do
Tyson> dereferencing and as a pointer type. This is one of the many
pointer to a memory location holding some value, I get. dereferencing
I don't.
Tyson> joys of C.
Tyson> [x] goes to the xth cell in the array preceding it. DATE_CELL
Tyson> is probably defined to be some number elsewhere in the code.
I get it. No problem. it goes to the DATE_CELL'th one. That makes
sense.
>> hey! is #define different than #DEFINE ??? is _that_ what I am
>> missing?
Tyson> No, you just didn't know what -> did.
thanks again.
>> ps. if i understand #define's, then every time we see HDR (DATE),
>> those three lines get copied into the source file each time on the
>> way to/through the preprocessor. Doesn't that bring out a ton
>> extra BasicCell *hcell; lines??
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?
thanks for the help again, this should help a ton while looking
through the gnucash code.
rob
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
