🔒 Locked

File I/O Quickie

Started by Omaha Oct 14, 2001 at 1:17 AM 4 replies 300+ views

Original Post

Oct 14, 2001 at 1:17 AM

Hhm... I just noticed even though I jumped to Win32 for development purposes well over a year ago, I''m still using all the same old standard library calls like fopen(), fgetc() and fscanf() for my file I/O needs. They were always useful in my DOS days... That''s ok, right? Riiiight? I noticed the CopyMemory() macro is just a wrapper for memcpy() (which I also still use) so my assumption was that if any "new" file routines existed they were just macroes that led to existing ones. Am I missing out on a remarkable new I/O library? I don''t like to depend on disk access too much at time critical points, so if speed is the major gain I should be ok for now. (I spent a bit too much time using an ancient Borland compiler under DOS...)

Shannon Barber

Oct 14, 2001 at 1:25 AM

There is a new way, it''s called overlapped IO and takes advantage of the the mutli-threaded kernel - I''d say it''s about 7x as difficult to work with as fopen and speed is the potential gain. You can do other stuff while waiting for the IO operation to complete, instead of just sitting there and waiting for it.

Imagine if you could issue a fread then process that last chuck of data returned by the previous call to fread, and then wait for the next chunk - which would be ready and waiting since you were busy doing other stuff.

Further optimization can be realized using Win2000/XP and IO completeion ports.

Dean Harding

Oct 14, 2001 at 4:54 AM

One other thing, it''s probably the other way around, that is, fopen() and chums would use the Win32 file I/O functions, not the other way around.

codeka.com - Just click it.

Arild Fines

Oct 14, 2001 at 8:34 AM

Dean is right. All the C/C++ file access functionality eventually maps down to the native Win32 file functions, such as ReadFile and WriteFile(On NT this might eventually map down to the native NT API...not too sure about that, tho).

"A society without religion is like a crazed psychopath without a loaded .45"

jwalker

Oct 14, 2001 at 9:09 AM

well, i prefer to not use the stdio simple IO.

i recently discovered this problem..

  

    FILE *input = fopen("IOR.ref","r");

    if(!input) 
     {
           perror("Corba IOR missing..please start repository");
           exit(0);
      }

    fseek(input,0,SEEK_END);

    char *lpszIOR = new char[ftell(input)];

    rewind(input);


    fscanf(input,"%s",lpszIOR);
    
    system(lpszIOR);

    fclose(input);

.. this is a snippet from my school assignment..
the lpszIOR is complete when i examine with the visual c++ debugger..

but the program crashes on the fclose()..I have no idea why a open file would crash on a fclose().

{ Stating the obvious never helped any situation !! }

Dean Harding

Oct 15, 2001 at 4:33 AM

Well, for one thing, if IOR.ref contains only one line, then the line where you allocate memory for the string is one character too short, you don''t have enough space for the terminating NULL.

Chnage the line to this:

  
    char *lpszIOR = new char[ftell(input) + 1];

and see if that helps.

codeka.com - Just click it.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.