• (cs) in reply to Earl Purple
    Anonymous:

    That is the wrong way to loop through a collection in STL though. The correct way is to use an algorithm.

    std::for_each( m_sessions.begin(), m_sessions.end(), functor );

    It took Java up to version 5 to add Generics, finally realising that it's a good idea. It even optimises the bounds checking, since if iterating through a Java collection like:

    for( Obj o: myContainer )

    {

     // do whatever

    }

    there is no need to bounds-check your way through.

    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.

  • (cs) in reply to Samah
    Samah:

    Is it just me, or does this chop off the last character of the string?

    j = strlen(tmpstr); tmpstr[j-1] = 0;

    Seems to me he's trying to null-terminate an already null-terminated string, and in the process removing the last character.

    Maybe I just read it wrong (not enough coffee this morning). 

    Ah just after I posted that I realised what it was for (removing newline). 

  • Confused of Birmingham (unregistered)

    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.

  • Teschi (unregistered) in reply to darin
    darin:

    Too bad standard C didn't provide directory reading routines.Using FindFirstFile will work but is unportable.


    #include <dirent.h>
    DIR *opendir(const char *
    darin:

    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);

  • Oliverthered (unregistered) in reply to MET

    Here in the UK where we use DD/MM/YYYY we would still say that the date is November the 14th

  • Hank Miller (unregistered) in reply to darin
    darin:
    This is quite common. It's often hard to find a suitable embedable scripting language. Especially in the past. I worked at a company once that did this, and the language was intended for end users to add simple code to forms.So the language couldn't be too complicated, we added our own sanity checks, and it was tied to the capabilities of our project.  Someone today would say "dude, just use TCL" (or VB or whatever), but none of those would really have fit the bill, even if they had existed.

    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.

  • BtM (unregistered) in reply to Samah
    Samah:
    Samah:

    Is it just me, or does this chop off the last character of the string?

    j = strlen(tmpstr); tmpstr[j-1] = 0;

    Seems to me he's trying to null-terminate an already null-terminated string, and in the process removing the last character.

    Maybe I just read it wrong (not enough coffee this morning). 

    Ah just after I posted that I realised what it was for (removing newline). 

    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:


    char *newlineChar;
    ...
    if ((newlineChar = strchr(tmpstr, '\n')) != NULL)
        *newlineChar = 0;

    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.

  • wade b (unregistered) in reply to Goplat

    [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.

Leave a comment on “Please Select Fewer Files”

Log In or post as a guest

Replying to comment #:

« Return to Article