When I run the Debug in Visual Studio for a project, fopen function works fine. It tries to open a file contained in the project and that I added in the filter "Resources".
But when I run .EXE file of my project, I get the null pointer exception: 0x000005c.
When I added the file to be in the same directory as my .EXE file, the exception disappeared.
This is the instruction I use :
fopen(&filename, "rb");
I know it is adviced to use fopen_s instead, but the file is not found anyway...
Apparently, the file is searched always in the current directory...
So, how to include the file in .EXE and make the path of the file relative to the .EXE, at a way it will be contained in the .EXE and not added to the directory where there is .EXE?
You can't include the file in the .exe. You just need to make sure that the file is in the same directory as the .exe.
If you really, really want to only use one file, you could either:
Zip the .exe and the text file together and make sure you include in a readme that the text file needs to be in the same location as the .exe
Use an array/struct/some other way of storing the contents of the file in the program itself, and reference that instead of using a file (I assume you don't care about users being able to edit this data outside of an instance of the program since you wanted it bundled with an executable, so the file is unnecessary in that case)
The reason the program only works when you put the file in the directory of the .exe is because the path to the file is defined in the program as something like .\file.txt or file.txt. When the file isn't in the same directory as the .exe, the program will try to find it, and will be unable to, which is why you get the error. It works when you debug because you have a copy of the text file in the same location as the debug .exe.
EDIT: I would also ignore the warnings about fopen_s and other variant's that append a _s to the end of a command - these are windows specific, non-standard, and in most cases, pointless. If you know this program will only be used in windows environments and you're not doing something for school where you are required to write standard code, I suggest you use the _s variants for the sake of security, but it will reduce portability of your code.
Related
I have a C++ program compiled with MinGW on Windows 7 that calls fopen(), specifying a file with a relative path. The program works fine if you run the executable in it's own directory, but I've noticed that fopen() will not find the specified file if I were to run the program with command line in a different directory. For example, if my executable "foo.exe" and specified file "bar.txt" are located in "C:\project\build\" and I run the exe while in "C:\project\", fopen() will not find the file. Is there some workaround for this using the code or compiler flags?
I can see this being necessary to access resources which are in a specified location relative to the executable, though without the absolute path of the executable file itself being known. I would suggest getting the absolute path to the executable file, probably using one of the methods described in Get path of executable, and then either changing the process's working directory to the parent directory of the executable, or constructing an absolute path to the file you want to open by resolving the relative path you have against that directory. Then you can pass the result to fopen().
I have a c++ project that I would like to send to someone in executable form. The issue is the program must read from a .txt that I created (specific deliminators). Currently my program reads from a file path that is specific to my computer,
parseFile("/Users/David/Desktop/FinalProject/Store.txt");
How could I package the .txt file and the executable file together, where the exec. reads specifically from the that .txt on anyone's machine?
Note: I am using Xcode
Change your programs to receive 'file path' as a parameter. Write a note(ReadMe) with the program to specify the file format and added a sample data file with the package
tl;dr: if you just put the text file in the same folder with your executable, you can open it with parseFile("Store.txt");
In most runtime implementations, there is a notion of a "working directory." When you open up an executable via the graphical shell (by double clicking it or something to that effect) the working directory is the same as the directory the executable is in.
Now, if you try to open a file in your program via a path that isn't fully qualified, then the path that gets used will be relative to the working directory.
A fully qualified path is a discrete path that points to a single entity in your filesystem. "/Users/David/Desktop/FinalProject/Store.txt" is one such example, as it starts at root (/ on *nix, DriveLetter:\ on Windows) and says exactly which directories you need to traverse to get to your file.
A path that is not fully qualified (which basically means that it doesn't start at the root of your filesystem) can be used to perform relative file addressing. Most runtimes will assume that any path that is not fully qualified is meant to be relative to the working directory, which basically means that the path that actually gets opened is the result of concatenating your provided path to the end of the working directory.
As an example, if you opened your binary, which is stored as /Users/David/Desktop/FinalProject/a.exe, then the working directory would be set to /Users/David/Desktop/FinalProject/. If your program then tried to open "Store.txt", the runtime would see that you're trying to open a path that isn't fully qualified, so it would assume you meant to open a file relative to the working directory, which would then be /Users/David/Desktop/FinalProject/ + Store.txt, which would be /Users/David/Desktop/FinalProject/Store.txt.
The nice thing about this is that if you move your binary, the working directory moves too. if you move a.exe along with Store.txt to /Users/David/Desktop/FinalProject(copy)/, then when you open /Users/David/Desktop/FinalProject(copy)/a.exe, the working directory will be /Users/David/Desktop/FinalProject(copy)/ now, and now when you call parseFile("Store.txt"), it will instead open up /Users/David/Desktop/FinalProject(copy)/Store.txt. This holds true when moving to other computers, too.
It's worth noting that if your binary is run from a command line utility, the working directory will often be the directory the command line shell is in, rather than the executable's directory. It is, however, a part of the C standard that the first command line parameter to main() should be the name of the executable, and most implementations supply you with the fully qualified path. With some minimal parsing, you can use that to determine what path to use as a base for addressing files.
I am trying to use a resource file (*.rc) in a command line compiled application, using a make file. I discovered that even though the current directory was the output directory, and that cl seems to be building its object files to this output directory, that the rc compiler will only put its output .res file in the same location as the .rc file. How can I, with some flexibility, tell rc to put its output file in a different location without a manual 'move' operation?
i.e.:
This will put source.obj file in the (current) c:\foo\bar\ directory:
c:\foo\bar>cl c:\foo\src\source.cpp
Whereas this will put a .res file in the c:\foo\res\ directory:
c:\foo\bar>rc c:\foo\res\resource.rc
The main problem is it is awkward to find a way to have the make file script do the post-compile move of the res file. Is there a way to change the output folder?
Probably an answer to your question:
MSDN specs for RC
This is the NMAKE line I have for resource compiler:
$(RC) -fo$# $**
It puts the resource file where I direct it.
It seems, however, that the directory has to exist beforehand, or RC throws its hands up in the air in dismay. Maybe I've misunderstood this problem, but I'm right about that, it's pretty lame behavior. And in that case, depending on the order of execution, you may need a MKDIR command in your makefile.
I am new to c++ and am making a very simple program. All my program does is call a function from the main function, which reads in a text file and returns. To check that I am reading in the file correctly, I am trying to print out the strings I have read in. The print out (cout) works properly when I run from Visual Studio (f5). However, when I run the executable from command line, none of the print outs from my function show up. Only print outs directly in the main function appear. I cannot find a similar question elsewhere. Any help would be appreciated.
When you run a program from within VC++ the current directory is set to the project directory by default, but the application is by default in a different folder.
E.g. the application may be:
D:\Work\MyApp\Debug\MyApp.exe
But the project directory may be:
D:\Work\MyApp\MyApp\
When you start the program from outside of VC++ you need to take steps to make sure the current directory is correct, or that the executable and any data files it refers to are in the same folder.
The default working directory for an IDE-launched project in Visual Studio is the project folder. This is the folder where you project file resides (the .vcproj or .vcprojx file is the project file).
If the data file you are reading is in the same folder, code like this:
std::ifstream inf("datafile.txt");
will succeed because the current working folder and the folder where the data file resides are the same.
However, if you switch to where the executable was written (typically this is the project-dir/Debug or project-dir/Release folders) and run the same executable from a command-shell, the data file will not be found.
To test this is the case. Do the following:
Open a command prompt.
Switch to the project folder where your data file resides.
Run the executable with a specified path: ./Debug/YourProgram.exe, for example.
Note: you can avoid this by having the program take the data file name as an argv[] parameter. Then your program will simply use whatever file you tell it to at launch-time.
I am required to parse a text file in my VS project in mfc in c++. The text file is supposed to be a part of the entire exe product. For that purpose, I placed the text file in my resources folder and set the path in my code as:
char fileName[] = "../myFile.txt";
The problem I'm facing is that VS doesn't find this file in its Resources folder. I added the file in the project file, but that just gave me a corrupt file error. However, the file access works if I provide the absolute path to the file in my code i.e. "C/abc/myFile.txt"
I need the code running on all machines, hence need some method to get VS to read this file using a relative path. Can anybody please provide some assistance? I am a newbie and have tried all that's in my knowledge.
Actually, if it's a resource file it should be copied over to the bin folder, which means your fileName should just be:
char fileName[] = "myFile.txt";
if that doesn't work then, you might need to change the properties of your myFile.txt to ensure it does get copied over with the build process.
Here you can find an answer for your question: http://www.cplusplus.com/forum/general/54255/