Register | Login
Views: 19364387
Main | Memberlist | Active users | ACS | Commons | Calendar | Online users
Ranks | FAQ | Color Chart | Photo album | IRC Chat
11-02-05 12:59 PM
0 user currently in Programming. | 3 guests
Acmlm's Board - I2 Archive - Programming - Program crashing when trying to open file... | |
Add to favorites | "RSS" Feed | Next newer thread | Next older thread
User Post
windwaker

Ball and Chain Trooper
WHY ALL THE MAYONNAISE HATE
Level: 61

Posts: 1260/1797
EXP: 1860597
For next: 15999

Since: 03-15-04

Since last post: 4 days
Last activity: 6 days
Posted on 03-07-05 06:09 AM Link | Quote
#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.


(edited by windwaker on 03-06-05 09:10 PM)
Lenophis

Super Koopa
Level: 44

Posts: 407/830
EXP: 584360
For next: 26925

Since: 03-15-04
From: Duluth, MN

Since last post: 4 hours
Last activity: 3 hours
Posted on 03-07-05 09:12 AM Link | Quote
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
Dish

Spiny
Level: 38

Posts: 292/596
EXP: 355646
For next: 14801

Since: 03-15-04
From: Disch

Since last post: 18 days
Last activity: 18 days
Posted on 03-07-05 09:19 AM Link | Quote
Your code is fine. I copy/pasted and built my own version. It works as expected without problems.
Euclid

Cheep-cheep
Level: 23

Posts: 138/193
EXP: 65528
For next: 2195

Since: 03-15-04
From: Australia

Since last post: 24 days
Last activity: 7 days
Posted on 03-07-05 02:51 PM Link | Quote

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

Bullet Bill
Level: 35

Posts: 341/514
EXP: 267348
For next: 12588

Since: 05-25-04

Since last post: 104 days
Last activity: 32 days
Posted on 03-07-05 04:29 PM Link | Quote
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)
windwaker

Ball and Chain Trooper
WHY ALL THE MAYONNAISE HATE
Level: 61

Posts: 1266/1797
EXP: 1860597
For next: 15999

Since: 03-15-04

Since last post: 4 days
Last activity: 6 days
Posted on 03-08-05 01:54 AM Link | Quote
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

Bullet Bill
Level: 35

Posts: 343/514
EXP: 267348
For next: 12588

Since: 05-25-04

Since last post: 104 days
Last activity: 32 days
Posted on 03-08-05 03:54 AM Link | Quote
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

Ball and Chain Trooper
WHY ALL THE MAYONNAISE HATE
Level: 61

Posts: 1444/1797
EXP: 1860597
For next: 15999

Since: 03-15-04

Since last post: 4 days
Last activity: 6 days
Posted on 04-26-05 05:27 AM Link | Quote
*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?


(edited by windwaker on 04-25-05 12:28 PM)
(edited by windwaker on 04-25-05 01:25 PM)
sloat

Level: 16

Posts: 45/85
EXP: 18044
For next: 2212

Since: 05-21-04
From: South Central Delaware

Since last post: 19 days
Last activity: 5 hours
Posted on 04-26-05 09:39 PM Link | Quote
".\\junk.txt"
Kyoufu Kawa
I'm not bad. I'm just drawn that way.
Level: 70

Posts: 1498/2481
EXP: 3008456
For next: 7355

Since: 03-19-04
From: Catgirl Central

Since last post: 14 hours
Last activity: 13 hours
Posted on 04-29-05 03:41 PM Link | Quote
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.
neotransotaku

Baby Mario
戻れたら、
誰も気が付く
Level: 87

Posts: 2950/4016
EXP: 6220548
For next: 172226

Since: 03-15-04
From: Outside of Time/Space

Since last post: 11 hours
Last activity: 1 hour
Posted on 04-29-05 11:17 PM Link | Quote
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]
HyperLamer
<||bass> and this was the soloution i thought of that was guarinteed to piss off the greatest amount of people

Sesshomaru
Tamaranian

Level: 118

Posts: 4298/8210
EXP: 18171887
For next: 211027

Since: 03-15-04
From: Canada, w00t!
LOL FAD

Since last post: 2 hours
Last activity: 2 hours
Posted on 04-30-05 05:16 AM Link | Quote
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.
X-Grade
Newcomer
Level: 6

Posts: 5/8
EXP: 533
For next: 374

Since: 04-24-04

Since last post: 184 days
Last activity: 132 days
Posted on 04-30-05 06:30 AM Link | Quote
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.


(edited by X-Grade on 04-29-05 01:34 PM)
Dish

Spiny
Level: 38

Posts: 374/596
EXP: 355646
For next: 14801

Since: 03-15-04
From: Disch

Since last post: 18 days
Last activity: 18 days
Posted on 04-30-05 06:54 AM Link | Quote
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)


(edited by Disch on 04-29-05 01:56 PM)
Parasyte

Bullet Bill
Level: 35

Posts: 482/514
EXP: 267348
For next: 12588

Since: 05-25-04

Since last post: 104 days
Last activity: 32 days
Posted on 04-30-05 02:36 PM Link | Quote
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.
X-Grade
Newcomer
Level: 6

Posts: 8/8
EXP: 533
For next: 374

Since: 04-24-04

Since last post: 184 days
Last activity: 132 days
Posted on 05-02-05 07:13 AM Link | Quote
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.


(edited by X-Grade on 05-01-05 02:14 PM)
Parasyte

Bullet Bill
Level: 35

Posts: 489/514
EXP: 267348
For next: 12588

Since: 05-25-04

Since last post: 104 days
Last activity: 32 days
Posted on 05-02-05 09:58 AM Link | Quote
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.
Add to favorites | "RSS" Feed | Next newer thread | Next older thread
Acmlm's Board - I2 Archive - Programming - Program crashing when trying to open file... | |


ABII


AcmlmBoard vl.ol (11-01-05)
© 2000-2005 Acmlm, Emuz, et al



Page rendered in 0.011 seconds.