Re: FindFirstFile Possible Memory Leak

I see your point here, though in the end, I'm in agreement with Rick and Bob
on this one. It's interesting what you say about adding to the stack during
the execution of the procedure, as it has the advantage of only consuming as
many resources as necessary, but the obvious disadvantage that you have to
run code each time to allocate more memory, do whatever maintenance is
required, etc., instead of just doing it once at the beginning of the
function call. If you accidentally do this in a loop, there would be some
very significant performance hits, I would imagine.

Of course, as I've mentioned before, I really found Pascal to my liking
"back in the day"...the structure of it really appealed to me. So it
shouldn't be any wonder that I still tend to think and work in those terms.


Rob

"Ralph" <nt_consulting64@xxxxxxxxx> wrote in message
news:OnX8AEcrHHA.4180@xxxxxxxxxxxxxxxxxxxxxxx

"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
    ... Declaring all variables at the top is an artifact of how programming ... instructions were setup. ... creating a stack setup for the call. ... Interpreted languages were not quite so constrained as their only ...
    (microsoft.public.vb.general.discussion)
  • Re: C Expression Parsing in Forth?
    ... I've worked with enough different languages and methodologies over the years to know that *all* worthwhile programming is factoring, and that is completely independent of language. ... Any modern programmer who wants to remain relevant needs to understand the complete spectrum of factoring, not just low-level factoring in Forth, and not just the higher-level factorings the refactoring community has come up with. ... I do agree that the kind of factoring that happens in Forth is greatly facilitated by unnamed items on a stack. ...
    (comp.lang.forth)
  • Re: Static vs. Dynamic typing (big advantage or not)---WAS: c.programming: OOP
    ... 20% are spurious errors produced by the type system, ... I am not writing a Stack. ... We were talking about mainstream languages like C++ and Java. ...
    (comp.object)
  • Re: Static vs. Dynamic typing (big advantage or not)---WAS: c.programming: OOP
    ... 20% are spurious errors produced by the type system, ... I am not writing a Stack. ... We were talking about mainstream languages like C++ and Java. ...
    (comp.programming)
  • C Expression Parsing in Forth?
    ... What value is there in programming in Forth ... >> a position on the stack. ... >syntax over time to where it'll do the entire c file. ... >> solution is to come up with a call interface between the two languages. ...
    (comp.lang.forth)