Acmlm's Board - I2 Archive - Programming - Program crashing when trying to open file...
| User | Post |
Parasyte
Posts: 489/514 |
Originally posted by X-Grade
As a quick and simple exemple, when using printf, the application analyse the format during runtime, while cout analyse the format during compilation time (It also greatly reduce the risk of errors). Also, iostream use a "uniform" syntax. You can, for exemple, take the above code, change one type, add one line, and you're application writes to a buffer before writting everything to the console. A really appreciated functionality when working on huge mainframe.
It also greatly reduces the chance of writing dynamically-formatted strings, which is something I found a need for on a few occasions. Furthermore, it's equally possible to write formatted strings to a buffer before sending them to stdout using only printf() and adding a call to freopen(), but there is little use for it. You would be hard-pressed to find a situation where buffering text before spewing to the console makes for great advantages. |
X-Grade
Posts: 8/8 |
Originally posted by Disch
Originally posted by X-Grade
Bleh! Why use old C functions when newer C++ functions are much faster.
How do you figure?
Besides... perhaps he's coding in C and not C++? ;P
I'm a C/C++ hybrid guy myself -- but I still prefer to use stdio.h for file i/o. Much cleaner/simpler more straightforward. Some C++ additions are good... some are just downright silly (like iostreams)
As a quick and simple exemple, when using printf, the application analyse the format during runtime, while cout analyse the format during compilation time (It also greatly reduce the risk of errors). Also, iostream use a "uniform" syntax. You can, for exemple, take the above code, change one type, add one line, and you're application writes to a buffer before writting everything to the console. A really appreciated functionality when working on huge mainframe. |
Parasyte
Posts: 482/514 |
The working directory for any win32 console program (regardless of which compiler was used) is actually the same for all programs -- it's whatever you have it set to. If you actually use the console to run console apps (like all good boys and girls) then you should cd into the directory containing the program to run. This directory will be the working directory. If, instead, you run the program from your root directory py passing the path and executable name on the command line, your will find that the root directory is now the working directory. As I said, it's whatever you set it to!
If you are running console programs from explorer, like a less intelligent computer user, you will find the working directory defaults to one of the following:
C:\
C:\Windows\
(... or the current user's "My Documents" directory, which changes depending on the version of Windows, and the username.)
It could also default to any number of directories, using any number of various methods, such as having a certain environment variable set.
The moral of this excrusiatingly bad story is: Always run your console programs from a real console!
P.S. I use GCC 3.4.2 (mingw-special) as well. |
Dish
Posts: 374/596 |
Originally posted by X-Grade
Bleh! Why use old C functions when newer C++ functions are much faster.
How do you figure?
Besides... perhaps he's coding in C and not C++? ;P
I'm a C/C++ hybrid guy myself -- but I still prefer to use stdio.h for file i/o. Much cleaner/simpler more straightforward. Some C++ additions are good... some are just downright silly (like iostreams) |
X-Grade
Posts: 5/8 |
Bleh! Why use old C functions when newer C++ functions are much faster.
#include <fstream>
#include <iostream>
using namespace std;
int main()
{
int key;
ifstream in;
in.open("junk.txt", ifstream::in | ifstream::binary);
if (!in.is_open())
{
cerr << "Unable to open the file" << endl;
}
else
{
while(!in.eof())
{
in >> key;
cout << key;
}
cout << endl << "End of file" << endl;
}
in.close();
return 0;
}
Also, instead of writing each caracters one by one, putting them in a buffer,
and writing the buffer to the console would be much more efficient. |
HyperLamer
Posts: 4298/8210 |
I think the working directory would be MinGW's \bin directory (where the compiled EXE gets placed). That's where it is for me but I can't remember if I maybe changed some setting or hacked something up to make it that way.  |
neotransotaku
Posts: 2950/4016 |
Originally posted by windwaker
Edit: Yesssss... evidently, it wasn't looking for the file in that directory, junk.txt, it was looking for C:\junk.txt. Is there any way to tell it to look for junk.txt in it's own directory?
Where do you run the program from? If you double click it from explorer, the working directory should be the folder the executable is in. If you do it from an IDE, then something in the IDE should make you start in the working folder. I had similar problems when I was using visual studio in trying to open files because the executable was loaded from [project path]\DEBUG directory and all the files were being read/written in the [project path] |
Kyoufu Kawa
Posts: 1498/2481 |
I spy another problem here... you're hiding extensions. BAD WINDWAKER! Go stand in the corner.
Yeah, that's right. Right next to the bad command or filename. |
sloat
Posts: 45/85 |
".\\junk.txt" |
windwaker
Posts: 1444/1797 |
*bumps because he's started this up again*
gcc.exe (GCC) 3.4.2 (mingw-special)
That's my version, and I compiled using gcc -O2 -s -o x.exe x.c.
x.c (actually fopen.c) contains:
#include <stdio.h>
int main()
{
FILE *in;
FILE *dude;
int key;
in = fopen("junk.txt", "r");
if (!in)
{
puts("Unable to open the filez");
return 0;
}
while ((key = fgetc(in)) != EOF)
{
putchar(key);
}
fclose(in);
return 0;
}
Now, when this is compiled, and run in command prompt, it prints "Unable to open the filez". As you can see, unfortunately, there is a file named junk.txt in this folder. Is there a problem with the code?
Edit: Yesssss... evidently, it wasn't looking for the file in that directory, junk.txt, it was looking for C:\junk.txt. Is there any way to tell it to look for junk.txt in it's own directory? |
Parasyte
Posts: 343/514 |
Run gcc --version from the command line, and post the version information printed. You may have an instable version of gcc. I just compiled it with my copy of MinGW, and it works great.
gcc (GCC) 3.4.2 (mingw-special)
I did make a change to the source, however:
while ((key = fgetc(in)) != EOF)
{
putchar(key);
}
Finally, I compiled it with the following:
gcc -O2 -s -o x.exe x.c |
windwaker
Posts: 1266/1797 |
Well, I compiled it with MinGW, and I used -o whilst compiling; perhaps it's the compiler, or my copy of windows (x.exe has caused an error [close]).
 |
Parasyte
Posts: 341/514 |
You are missing a bracket in your while loop, Euclid:
while ((key = fgetc(in)) != EOF)
As Disch stated, the code is fine. You should probably change your optimization level. Bugs are known to occur in levels greater than 2. (EG, always use -O2 or less) |
Euclid
Posts: 138/193 |
while (!feof(in))
{
key = fgetc(in);
....
}
wow you sure there's feof?
i would do something like this instead
while ( (key = fgetc(in) != EOF )
{
putchar(key);
}
or something like that, i forgot if you use EOF or NULL.... |
Dish
Posts: 292/596 |
Your code is fine. I copy/pasted and built my own version. It works as expected without problems. |
Lenophis
Posts: 407/830 |
Originally posted by windwaker
#include
int main()
{
FILE *in;
int key;
if ((in = fopen("junk.txt", "r")) == NULL)
{
puts("Unable to open the file");
return 0;
}
while (!feof(in))
{
key = fgetc(in);
if (!feof(in))
putchar(key);
}
fclose(in);
return 0;
}
I didn't write the main code for this, though I did mess around with it a bit, and created junk.txt, though every time I compile it with MinGW, it crashes.
Change the "if((in = fopen...))" line to:
in = fopen("junk.txt", "r");
then
if(!in)
{
puts("Couldn't open! Thou sucks!");
}
See if that helps |
windwaker
Posts: 1260/1797 |
#include
int main()
{
FILE *in;
int key;
if ((in = fopen("junk.txt", "r")) == NULL)
{
puts("Unable to open the file");
return 0;
}
while (!feof(in))
{
key = fgetc(in);
if (!feof(in))
putchar(key);
}
fclose(in);
return 0;
}
I didn't write the main code for this, though I did mess around with it a bit, and created junk.txt, though every time I compile it with MinGW, it crashes. |
|
