find files or folders

[jbpelletier]

hi,

im looking for an equivalent of the "find files or folders" of Windows.

In fact, i need to find all *.somthing files located on a specific drive, then loop the list to process files returned by the search...

any help would be appriciate

jb

 

[towerbase]

Glenn9999,

I really don't understand what your point is. Accessing variables from the stack is no less efficient than accessing variables from the heap. I would suggest that your "non recursive" implementation uses the stack just as much as the recursive solution. I put non recursive in quotes because you have actually coded the recursion yourself instead of allowing the compiler to do it for you.

Why knowingly make a piece of bloatware that grabs 1MB for stack even for the simplest "Hello world" program?

Because it frankly isn't worth the bother. It simply doesn't matter in 99% of programs. Every change you make to a program increases the risk of a new error creeping in. There is no point in changing the Delphi default memory allocations unless you get a real benefit.

Run your Hello World program with a 1MB stack and then run it with a much smaller stack. Can you tell the difference? Did it run faster? Did your system run more efficiently? Was it really worth tweaking the memory allocations? It might make you feel better inside but it is really not worth bothering about.

Many years ago this kind of optimisation did matter. It doesn't now. I'm still staggered by the changes in computing technology since I started programming professionally in the 1960s. And I have to occasionally remind myself that my time is too important to worry about things that don't matter even though they might seem wasteful.

Andrew
Hampshire, UK

 

[whosrdaddy]

I think the point is that, when using recursive procedures, one must always take into account that a stack overflow is REAL risk. that's why I took the habit to first write the procedure recursivly (is fastest way), test it and then change it into a normal loop.

-----------------------------------------------------
What You See Is What You Get
Never underestimate tha powah of tha google!

 

[towerbase]

whosrdaddy,

When writing any code there is always a real risk of making an error and introducing a bug. That is one of the reasons why we test programs.

What is the point of writing and testing a recursive routine and then rewriting it and testing it again as a normal loop? The "normal" loop will probably contain more statements than the recursive routine, be more error prone and harder to test.

If the recursive routine has been tested and shown to work then I don't understand why you would want to rewrite it.

If you have a phobia of stack overflows then it would be sensible to take extra care in coding and testing the recursive routine to ensure that it terminates properly. But as far as I can see there's nothing special about stack overflows compared to all the other kinds of error that one comes across in program testing.

Andrew
Hampshire, UK

 

[whosrdaddy]

I'll give a small example :

i wrote a program that parses small script files and interacts via comport towards a pbx. the parsing routine was written recursive and worked well. but after a while the script files grew larger and larger and I began receiving stack overflows. It was not obvious to me that my parsing routine was at the base of the overflow because the app was complicated and did a lot of things at the same time (there were 3 concurrent threads). after a bit of debugging I saw that the error only occured with large script files, so I rewrote the parsing routine so that it was using a loop. I agree that a normal loop is more complicated than it recursive sibling. I like recursive routines very much because they are simple and very readable, but sometimes they can't be used because of the stack space limitation...

-----------------------------------------------------
What You See Is What You Get
Never underestimate tha powah of tha google!

 

[Glenn9999]

Thank you whosrdaddy.

Often we don't think of specific points sometimes as to why we do things the way we do. Like I said earlier I've run into stack overflow problems in properly functioning programs myself in numerous cases.

As for me, the key thing to me is to produce the most stable, efficient code I can. When a factor gets taken out of my control, that's something I don't like, and the stack overflow issue is definitely one of them. Just like I code I/O checks on files for existence, so do I want a control for this. Any error, neglectful or incidental comes back on the programmer. Ultimately the stack issue can't be countered any other way than to eliminate recursive processing. It's been said in another thread that someone thinks "I'm against the idea of recursion." I'm not. I'm against the idea of the risk of program error. Recursion has its place, but not when the ultimate price could be my program crashing for a stack overflow.

Then, though, people use recursion when it really is inefficient to do so. Of course, people getting the factorial example usually as their first example on recursion doesn't help matters either. If it can be done much easier with iteration, do it with iteration, and something like that is a prime example. Then there is the issue I mentioned before of tail recursions (quicksort being a prime example of where people usually use them). Those always should be eliminated in favor of iterative looping structures. And yes, doing these two things with code enhances the performance, too.

And speaking of quicksort too, there's another handy example of stack overflow problems. Code a standard fully-recursive quicksort and throw it against a huge array in memory and see what happens. Then tell me if recursion isn't an issue: I'll even help you:

{ Use {$DEFINE DEBUG for test writes/reads }
program qsrtoflw;

 { this program written to demonstrate a stack overflow }

 const
   L = 1;
   R = 43200;     
{ ~ >795 will cause stack overflow in default TP 7.0, 
  ~ >43200 will cause stack overflow in default Delphi 3.0}
 type
   datatype = array[L..R] of integer;
 var
   A: datatype;
   i, j: integer;

 procedure recursive_quicksort(var A: datatype; L, R: integer);
   var
     i, j, PIVOT, t: integer;
   begin
     if L < R then
       begin
         i := L + 1;
         j := R;
         PIVOT := A[L];

         repeat
           while A[i] <= PIVOT do i := i + 1;
           while A[j] > PIVOT do j := j - 1;
           if i < j then
             begin
               t := A[i];
               A[i] := A[j];
               A[j] := t;
             end
         until i > j;

         A[L] := A[j];
         A[j] := PIVOT;

         recursive_quicksort(A, L, j-1);
         recursive_quicksort(A, i, R);
       end;
   end;

 begin
   randomize;
   {$IFDEF DEBUG}
   writeln;
   write('UnSorted: ');
   {$ENDIF}
   j := L;
   for i := R downto L do
     begin
       A[j] := i;
       {$IFDEF DEBUG}
       write(A[j]:3, ' ');
       {$ENDIF}
       inc(j);
     end;
   writeln;
   recursive_quicksort(A, L, R);
   {$IFDEF DEBUG}
   write('  Sorted: ');
   for i := L to R do
     write(A[i]:3, ' ');
   writeln;
   {$ENDIF}
   writeln('Sort done.');
 end.

This is the classical quicksort as you find in the books. You can see it for yourself by changing values of R. Tell me what to do to take care of the RTE 202 in this code if I don't start making this routine iterative?

 

[Glenn9999]

(Since I don't know how to edit my last post)

I should add that one of my current projects involves a prototype much like this quicksort one with an R of around 2000000. Care to hazard a guess at how useful a recursion-based sort was for me?

 

[towerbase]

Tell me what to do to take care of the RTE 202 in this code if I don't start making this routine iterative?

Using Delphi 7 and your recursive quicksort routine I had no problem sorting 10 million integers (that's five times more than your large project). But then I haven't changed the memory allocation with the $M pragma ....

Anyway, this thread is about "find files or folders" not about QuickSort or script parsing routines which are red herrings.

My main comment is that you warn against using recursion because of the risk of a stack overflow but then show some "iterative" code which explicitly uses a stack - which can also result in a stack overflow if there is an error in the code.

The "iterative" code is more complex to code, read, test and understand than the equivalent recursive routine.

Andrew
Hampshire, UK