- Feature Articles
- CodeSOD
- Error'd
- Forums
-
Other Articles
- Random Article
- Other Series
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
Yeah I'm lovin' the new foreach loops (new as in new to Java).
The only issue with them is that you don't know the index of the object within the Collection (and no indexOf(o) isn't guaranteed to work since ArrayList can contain a single object more than once, and the equals() method performs much the same). In that case it's back to the old for loop.
Admin
Ah just after I posted that I realised what it was for (removing newline).
Admin
Every example of using FindFirstFile/FindNextFile in this thread is broken. WTF?
FindNextFile may fail because it ran out of files, or for any number of other reasons. And if you're writing a robust app you need to distinguish failure from success.
Admin
Too bad standard C didn't provide directory reading routines.Using FindFirstFile will work but is unportable.
There are standard POSIX functions for reading directories.
#include <dirent.h>
DIR *opendir(const char *dirname);
struct dirent *readdir(DIR *dirp);
int closedir(DIR *dirp);
Admin
Here in the UK where we use DD/MM/YYYY we would still say that the date is November the 14th
Admin
Very close. It was/is an embedded language. The system was running out of memory. Someone (the person who wrote the above code, which should tell you alot about the language) said he could write a scripting language in two weeks for the code that was killing us. Investigating other solutions (tcl, - this was circa 2003, so there were plenty of good choices) and porting them would take 3 months. Of course getting their language to work took 6 months.
The 999 file limit was because of this line not shown (or submitted):
char File[999][200];
(I'm not sure from memory what the exact path length was, but 200 is close enough)
I think most of you have put more effort into understanding how this worked than I did. I gave up and fixed it. Now if I could just fix the 500,000 lines of code in the project the same way. Getting the code base down to 150,000 (a reasonable estimate) lines would probably make it possible to write all the scripts in C++ without either memory issues, or having to write shared library loading code.
Admin
Not that C really offers a good solution for this kind of thing, but it might have been a little more straightforward to use strchr() to find the newline character:
Of course, I realize that the right answer is to use the file management API and not parse the text output from a dir command.
Admin
[quote user="Goplat] The FindFirstFile/FindNextFile interface was based on DOS's findfirst and findnext system calls, which in turn were based on CP/M BDOS functions 17 and 18. In those days everybody wrote in assembly language, and the do/while loop is actually the easiest kind to write in assembly.[/quote]
Of course there is no "do/while" in any assembler dialect I am aware of (leaving out Macros, which themselves are replaced by a series OpCodes at compile time)
In assembler you're just doing conditional branch at the bottom of the loop (usually based on the Zero or Carry flags).
To your credit, such constructs do map rather nicely to the high level "do/while" construct.