Re: FindFirstFile Possible Memory Leak




"Michael C" <nospam@xxxxxxxxxx> wrote in message
news:eE0aePZrHHA.2368@xxxxxxxxxxxxxxxxxxxxxxx
"Robert Morley" <rmorley@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:uqZK4kXrHHA.5092@xxxxxxxxxxxxxxxxxxxxxxx
Of course, if he'd Dim'd his variables up top, like most people do,

Actually most don't. Dimming at the top is just one of those things that
is
considered the done thing in VB but no-one can give a good reason why they
do it.

Declaring all variables at the top is an artifact of how programming
languages were compiled, starting of course even earlier with how machine
instructions were setup. And later codified by Wirth, Dijkstra, Yourdon, et
al, via Structured or "Top Down Programming".

In C, for example, one declared a function this way...
int foo(s, i)
char* s;
int i;
{
int x;
int y;
....
<code body>
<any attempt at declaring a variable generated an error>
}

The first part told the compiler to setup a function call, then set up a
arg/symbol table (on the compiler's stack) for everything that followed the
')' until you reached a '{'. Stop. Mark the spot. Then pop everything back
creating a stack setup for the call. (everything ended up right-left). This
setup the function calls and all its args on the stack.

Build a symbol table for everything declared after the '{' until you run out
of declarations. Stop. Build the asm to build the program's stack. The
'auto' variables.

Now build the code until you come to the '}'. Blow-up if you run across
something you never heard of.

When you hit the '}'. Then move the stack pointer to end of the arg list.
(effectively dumping the stack). Populate the AX with the return.

And your function 'cleanup' (essentially in the caller), then go on to the
next.

Nice, quick, and simple. You HAD to declare all variables in these
locations. The compiler would barf if you didn't.

Interpreted languages were not quite so constrained as their only
requirement was nothing could be called before it was placed in the symbol
table. That's where the Fathers of Programming took over. Dijkstra probably
the worse of the bunch as he believed that programming was so complicated
and so outside of 'human' experience that one needed to formalize it as much
as possible. So Code became formal recipes. And top-down.

Look at any recipe and what do you see ...
A definition of what you going to make.
A list of ingredients.
A list of instructions.

Pascal, originally designed to be a teaching language, also enforced
declaring all variables at the top. This practice became Gospel long after
multiple-pass pre-processors made it unnecessary.


In other languages it's possible to reduce the scope of a variable
down even further so it only exists in a for loop or inside an if
statement.
In these languages it makes sense to dim the variable with the minimum
amount of scope possible.


C, always the inovator, soon added this twist. Anytime the compiler ran
across a '{' followed by a declaration it setup a new symbol table - added
to the stack. Which you destroyed when you came to a '}'. But it was often
discourage as a 'poor practice' even though the compiler and language rules
supported it.


It also doesn't make any sense to me why we have all the code to perform a
certain task in a block but with the dims elsewhere.


I agree. But old habits die hard, and of course like everything else - it
can get abused. Just because a language supports some syntax/puncuation
doesn't mean one should use it all the time. It is best to just occasionally
mentally step-back and look at the code and ask "Is this readable"?

-ralph







.



Relevant Pages

  • Re: FindFirstFile Possible Memory Leak
    ... It's interesting what you say about adding to the stack during ... Declaring all variables at the top is an artifact of how programming ... instructions were setup. ... Interpreted languages were not quite so constrained as their only ...
    (microsoft.public.vb.general.discussion)
  • Re: static allocation question...
    ... provide a stack. ... >{int a;} ... >to declaring a union. ... I have to <SNIP> now... ...
    (comp.lang.c)
  • Re: Stack Overflow
    ... "Igor Tandetnik" wrote: ... > Two common causes are 1) runaway recursion, and 2) declaring large ... > arrays as local variables. ... Specifically, more _stack_ memory. ...
    (microsoft.public.vc.language)
  • Re: Creating member vars on the heap, not the stack
    ... on the heap, not the stack. ... Other than declaring all the members of the class as static, ...
    (microsoft.public.vc.language)
  • Re: 406 Not Acceptable (was Re: "--All You Zombies--" title)
    ... Bill Snyder wrote: ... with code written in languages that do not (Python, PHP?). ... actually know the numbers here I'd be extremely wary of declaring (ha ...
    (rec.arts.sf.written)

Loading