Re: FindFirstFile, how much faster than FindNextFile?

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

From: John Doe (jdoe_at_usenet.is.the.real.thing.com)
Date: 02/11/05 

Date: Fri, 11 Feb 2005 20:29:16 GMT

Joseph M. Newcomer <newcomer@flounder.com> wrote:

>You have many issues here. There's nothing wrong with your code
>that a complete rethinking and rewrite won't solve.

I apologize if my code isn't clear. If you point out where the
problem is, I will happily clarify (of course I will, I'm asking for
help). That's one reason I keep re-including my code in the reply.

>First, you are presuming the files are in the root directory. This
>would at best be a horrible assumption;
...

I know exactly where the files will be. This is the folder as
planned.

C:\Program Files\Shortcuts\Scripts

All of the files will be in that folder, nowhere else.

>Next, you say you want an arbitrary substring of the filename, but
>that's not what your patterns are suggesting. If I want to find any
>file that contains "KeyA" anywhere in it, the correct pattern is
>not
> *KeyA.txt
>but
> *KeyA*.txt
...

There is no second asterisk because there is no space between the
capital letter A and the ".txt"

>... where do you get the strings for comparison? You erroneously
>answered where you got the filenames for the other half of the
>comparison;

Oh, okay. The strings for comparison include "Key" or "Pad" and the
regular keyboard letter and number keys (A-Z and 1-9), and the
keypad keys 1-9, plus the TXT extension.

The ends of the filenames will look like this.
...KeyA.txt
...KeyB.txt
...KeyC.txt
...Key1.txt
...Key2.txt
...Key3.txt
...Pad1.txt
...Pad2.txt
...Pad3.txt
... and so on

I know that because earlier in the program I generate the filenames.

Trying to keep track of the filenames probably won't work since they
can be edited from within Windows Explorer (the last part remains
intact). My program relies on that editing to do significant
programming work.

>I knew that you got them from FindFirstFile. But why do you need a
>case at all?

Because the cases allow searching directly for the specific last
part of a filename like "*KeyB.txt" or "*Pad7.txt" where the wParam
search criteria is one of the 45 user input symbols/codes.

>Just do
> FindFirstFile( strings[i], ...)
>
>and you don't need something as silly as 50 cases to handle a
>trivial problem. Just an array of 50 strings!

Using only one FindFirstFile()?

>so the whole discussion about whether a switch statement is
>"faster" is irrelevant.

If I didn't favor efficiency, it might be irrelevant. I tend to
dwell on efficiency. It's not a big deal.

I appreciate your effort.

>Since it is clear the table is compile-time constant,
>
>static const LPCTSTR strings[] = {
> _T("*KeyA*.txt"),
> _T("*KeyB*.txt"),
>...
> NULL // end of table
>};

Except maybe without the second asterisk. There is no space between
the capital letter and the ".txt"

>Why are you using strcpy?

Your guess is as good as mine.

>... you are begging for some serious bug to arise.

I will be the first to know since I use the program all day long.

>Lose the switch statement. Rethink the problem and if the answer
>does not seem obvious, ask it in terms of a program construct that
>would make sense.

This is my current signature:
To participate in an open-source Windows macro recorder project,
please see the unmoderated group (comp.windows.open-look). Coding
help is needed. Using VC++ 7. The project files or the program files
will be provided to programmers or expert Windows users, just ask.

That's where the code will be, for anyone who was afraid to ask.

>In fact, when I re-read your message, the actual solution is even
>simpler, if the ? is unique.
>CString suffix = _T("ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789"); // for
>example FileHandle = FindFirstFile( MakePattern(keybase +
>suffix[i]), &FindData); FileName = keybase + suffix[i] +
>extension;
>CString MakePattern(const CString & keybase)
> {
> return basedirectory + _T("*") + keybase + _T("*") +
> extension;
> }
>And PLEASE do not suggest that this is "inefficient";

Do you want me to lie?

>In rereading the code once more, I see that you really DIDN'T mean
>case 65; you almost certainly meant case 'A', which is what you
>should have written. In this case, the code is even more trivial:
>you just concatenate the character you would have used in the
>switch statement!
>TCHAR value;
>FileHandle = FindFirstFile( MakePattern(keybase + value),
>&FindData); FileName = keybase + value;

I guess, if those possibilities use only one FindFirstFile().

>A good refresher on basic principles of the C language seems a good
>investment of your time. If you want to represent the value of the
>character 'A', the value 'A' is a much better choice than the value
>65. So if you wanted a case based on letter values, the preferred
>way of writing it would be
> case 'A':
> ... something here
> break;
> case 'B':
> ... something for the B case
> break;
>
>Note that if you had actually indicated this by something as
>obvious as using the value you meant, 'A', instead of some bizarre
>numeric encoding of the character, the code would have been more
>obvious. The fact that it took me three careful readings of your
>code to try to make sense out of it--that you had written code so
>convoluted and obscure that its meaning was not obvious on first
>reading--already suggests so many failures of the coding process
>that you need to scrap this entirely and rewrite it.

You are too kind [kidding].

Since I'm going to also use keypad numbers, I doubt that the graphic
representation is better than the simple ASCII character
representation for the case labels.

>Why write a switch statement with 4 lines of code for each of 50
>cases (the case plus the three lines of executable code--that's 200
>lines of code!) when you can write the whole thing in about three
>lines of code? And have it more robust

Not that it matters, but arguments so far have not convinced
me that using the switch statement is less robust. Yes, it's a lot
more code, especially considering your refinements to the other
possible method. That's why I posted.

>I've just reduced 200 lines of code to 3 lines of code, which is
>66:1 compression.
...
>I think you need to focus less on what is "efficient" in terms of
>the API interactions and more on basic principles of constructing
>code that is easy to write, read, understand and maintain, and is
>robust and correct under actual user scenarios. Your example meets
>none of the previous criteria.

I'm the user, all day long.

>efficiency. And "right" does not simply mean "computes the result I
>want".

It could be worse.

Relevant Pages

  • Re: why do files in lower case show up in upper case in Front Page?
    ... It is caused by you typing a capital letter in the filename. ... You should use all lowercase. ... Also remember not to use spaces in filenames. ... why do files in lower case show up in upper ...
    (microsoft.public.frontpage.client)
  • Re: using std::system
    ... In article, Edo ... > I should rewrite this... ... I understand what the system rutine takes, ... > how can I pass variables as filenames here. ...
    (alt.comp.lang.learn.c-cpp)
  • Iterations
    ... I'm building a script to find and log specific file names on a PC. ... would do it now is just to rewrite the logging portion. ... So if the filenames were "filename1, filename2, filename3 etc.", it may use ...
    (microsoft.public.windows.server.scripting)