Hi Bob - fast reply, it's late, and I'm semi-conscious (had to use

the spell checker for that word...)



 RM> square1() can't alter the value of i, because we are calling it

 RM> with 2 as the parameter. square2() *can* alter the value of b,

 RM> because we are calling it with the actual memory address of b

 RM> as a parameter... [crunch to tutorial]



 BL>   Yair... in my mind, if you change it inside the function, then you

 BL> have to expect that it comes out changed. That happens with VB too,

 BL> and is a trap for young players... but now write me one using

 BL> strings. I don't have any trouble passing characters and integers...

 BL> but do it with strings and you *have* to pass addresses, and you

 BL> *have* to allocate space.



You have to pass addresses, *or* you have to allocate space, if you

are passing a string [shorthand for a char array!] to a function.

To pass a string to a function for the function to modify, try

this (simplified)



myfunc( char *s)

{

 int i;

 char *p;

 i = strlen(s);

 p = malloc(i);

 strcpy(p,s);

 /* do stuff to p */

 free(p);

}



 RM> Lesson 2: Calling by reference can be more efficient, if the

 RM> parameter is a large object.



 BL>   If the parameter is a large object how can you pass it unless you

 BL> use the address? Even when you *think* you're not, C is doing it

 BL> automatically.



sales1() does pass a copy of the entire contents of the structure, not

the address.



 RM> typedef struct      /* this defines a new "type" called
"person". */

 RM> {                   /* No memory allocation is done here, we are */

 RM> char name[20],   /* just telling the compiler what "person" is. */

 RM>      address[40];

 RM> int   sales[4096];

 RM> } person;



 BL>   You are telling the compiler that "person" is 20 + 40 +
4096. That's

 BL> what a struct does! You just haven't used it yet.



I did warn you I was in babytalk mode - I was just throwing in some

gratuitous side lessons on the off chance that they'd be handy.





 BL>   How do I know how big a string is going to be when I haven't read

 BL> the file yet? VB is dynamic, and if I want to increase the size of a

 BL> string it happens as I do it. In C, I have to allocate memory at every

 BL> stage... sometimes at the beginning, and sometimes with malloc()

 BL> halfway through. It's a bloody shambles and too easy to get crossed up -

 BL> for what? What do I gain?



Paul Markham wrote a pkt sorter called Sortpkt that does massive

on-the-fly memory grabs. I use it between Bink and Ppoint to get

the messages into subject and date order, and it's not unusual for

Sortpkt to grab 1.5M of ram; it reads multiple pkt files all into

ram, seeks out the message headers, sorts an array of headers, and

writes the big ram block msg by msg into a sorted file. The dos

version runs under the dos extender Dos4GW that comes with the

Symantec compiler. Source is available. Paul Rightwing may still

have the archive somewhere.



Cheers - more later, maybe



--- PPoint 1.88