-22 Mar 97  16:22:39-

=Henk den Adel babbled to Mike Phillips about trap 0005=



 HdA> Now i'm puzzled. Maybe you can help me out of the maze. The way i was

 HdA> thinking is as follows. Languages like C urge one to declare

 HdA> variables, in contrast to e.g. Fortran, where the motto is: if you

 HdA> need one, just use it, you don't have to declare it. So there must be



Be careful there.  C does not require prototyping.  C++ does, but it

also allows block scoped variables and allows you to declare variables

anywhere, which you correctly claim that C does not below.



 HdA> a reason for the necessity to declare variables in a language like C.



To protect the programmer from errors.  It also makes it easier for the

compiler to set up the data segment and stack frames since it doesn't

have to guess as to how many bytes it needs to reserve (otherwise it

would use the largest number of bytes you could have meant from your

assignments).



 HdA> Another fact: all declarations must be contained in the first part of

 HdA> a function, before the first executable statement, i.e. 



In straight C.



 HdA> float x, y;

 HdA> y = sin(x);

 HdA> int i;



This is allowed in C++.



 HdA> over the place. Furthermore, since sizeof(struct whatsoever) produces

 HdA> the right size of more complex type of variables, such as structs, the

 HdA> compiler should be able to determine the amount of memory which is

 HdA> needed for a struct, by sheer interpretation of the formal declaration

 HdA> of the struct, as provided in the function or its include files. BTW,



Yes, it can set up its own local stack frames without you dropping down

into inline assembler to adjust sp and bp.



 HdA> i have declared my struct as a variable, not as a pointer. 

 HdA> Could you be so kind to indicate which step in my reasoning is

 HdA> incorrect? 



I don't see where your reasoning leads to the conclusion that the

optimum size of the *entire* stack and heap are known to the compiler.



 MP> That function needs 40k of stack. What if that function called a function

 MP> in another source file that needs another 40k of stack. How is the

 MP> compiler to know this?



 HdA> Just add another 40 kB of stack?



What if the other function needs 45k?  What if the other function calls

yet another function?  What if those functions engage in mutual

recursion?



 MP> Anyways, it's the linker that actually makes the stack definitions, and

 MP> it doesn't know how much you've used.



 HdA> In my opinion the compiler can determine how much memory is needed to

 HdA> contain the variables which have been declared. Isn't that it what



Yes it can.  And it makes data segment definitions in the object file

for globals and stack frames for parameters and locals.  However, we're

talking about the global stack segment.  That's a different beast.  It

must be large enough to hold all of the local stack frames that the

compiler calculates.  Since the compiler does not follow the logic of

your code, it cannot know how large to make the total stack segment. 

It only knows about the local stack frames, which are of a constant

size determined by your parameter and local variable declarations, not

the logic of your code.



 HdA> declarations are meant for? I can't believe the more misantropic

 HdA> suggestion: to be able to generate error messages when an unfortunate

 HdA> programmer forgets a variable to declare? 



But that's the case.  BASIC and Fortran work just fine without such

declarations.



 MP> Just make your stack large enough.



 HdA> Murray Lesser wrote me that excessive stack does not hurt my

 HdA> resources, if the compiler is good, so that will be the solution. 



Under OS/2 and UNIX.  Don't try that in DOS or Win16 :)



The same argument goes for the heap.  I usually compile with a 32 meg

heap.  If you're not dealing with a braindead OS, allocate more than

you will need and let the OS deal with it.



Mike Phillips

INTERNET:  phil4086{at}utdallas.edu



... I'd rather hit with a .22 than miss with a .44

--- FMail/2 1.22