To give a little context: I'm writing a program that uses text files and BMP files. For the text files I was provided with a class to manage them and I'm using EasyBMP for the BMP manipulation.
The problem I have is the files are being created in the wrong folder unless I provide the full path.
Example:
#include "EasyBMP.h"
int main(){
BMP picture;
picture.SetSize(640,480);
picture.WriteToFile("picture.BMP");
return 0;
}
Expected result: 640x480 BMP file created somewhere in my project folder (C:\Users[user]\Documents\C++\TP 1)
Actual result: 640x480 BMP file created in Eclipse folder (C:\Users[user]\Documents\Eclipse)
The same happens with any other file I write to disk.
It used to work fine on a different project so I'm guessing there's something silly I'm missing somewhere but I haven't been able to find a solution.
EDIT: The exact same code works fine on a different project.
If you don't specify a full pathname, files are stored in the process's current folder. You can change that in Eclipse (tell if which folder to run from when you run the process).
If you always want the files to be stored where your EXE is, or somewhere around the EXE, you can find the folder yourself(the first argument to main is the location of the EXE file).
The program will write the file in the working directory. That's because you used a relative path and relative paths are relative to the working directory.
Either specify a full path in your code, or ensure that the working directory is set to your desired value when running the program.
Related
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 have made a simple scoring system which upon correct answer, stores the numbers of the player in the file.
I have used the file name like this :
ofstream outfile ("C:\Aadam\Desktop\Project\Scores.txt",ios::app);
But the problem with this approach is that what if I move the program over to a USB and try to run it in another computer. Now it will look in the directory I specified above but there is no Scores.txt file in there.
What I want to do is to give it a path which is in the project folder. So when I move the program, it shouldn't make a difference because I will move the whole project folder.
Of course I can do this :
ofstream outfile ("Scores.txt",ios::app)
which will always look in the project directory and it will work fine as long as I run the program from the IDE but what if I run the program from the .exe file which is two directories down like
"C:\Aadam\Desktop\Project\bin\Debug\Project.exe"
Now in this case, it can't open the file.
So if you know a good way to open files and kindly, Show me the Way.....
You can parse argv[0] (it will contain path used to invoke your executable - absolute or relative) and replace executable name in it with "Scores.txt"
The easiest way is to pass the file path to program as an argument.
When you run a program from IDE, the project directory is considered as current working directory. If the program is run from the command line, the current working directory is from where the command is being run.
If you run the exe file,ofstream outfile ("Scores.txt",ios::app) will create a file named "Scores.txt" in the same directory as your program.
i have a problem of which i am not sure where it comes from. Please take a look at this function:
http://pastie.org/8200205
imread appears to return empty matrices.
To be clear, my images are in the directory ImageData which is directly where my program lies, and for each object type like apple, i have a directory that is called like the object type and inside are all the apple images (if that's the current object type)
Additionally, i'm working with cmake but i'm pretty sure that i don't have to include directories w/o any code.
So what's the problem here? Is my pathing wrong or does imread not work in subdirectories?
I appreciate any suggestions/solutions :)
Relative paths are relative to the process working directory. This is not necessarily the same as the directory in which the executable resides. So assuming you've got everything else right, then the most likely explanation is that your working directory is not the same as the directory in which the executable resides.
In any case, it sounds as though you want the program to locate the files in a directory relative to the executable. In which case you should not rely on the working directory and instead you will need to form the full path to the files. You'll just need to prepend the directory of the executable.
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/
I have written a c++ program and deployed it in say c:\my_app, and my executable's path is c:\my_app\my_app.exe. Say, my_app needs many files such as the_file.txt, which is located in c:\my_app\the_file.txt.
In my executable, I open the txt file as, xx.open("the_file.txt");
Moreover, I have associated my program with let's say .myp extension.
When I'm on Desktop, and want to open a file named example.myp, my program can not see the_file.txt. Because, it (somehow) assumes that it's currently working on Desktop.
Is there any easy way to handle this problem by changing shell command for open in HKEY_CLASSES_ROOT? The naive solution would be to change all file open operations with something like %my_app_location/the_file.txt". I don't want to do that.
Always use a full path name to open a file. In other words, don't open "foo.txt", open "c:\bar\foo.txt". To find the install directory of your EXE use GetModuleFileName(), passing NULL for the module handle.
These days you shouldn't add files to c:\my_app....
Instead use the ProgramData Folder and full paths.
Use SHGetSpecialFolderPathA with CSIDL_COMMON_APPDATA to get the ProgramData folder and the create your program directory and add your files.
You should set current directory for your app's folder with SetCurrentDirectory function. After that you can open file by name without full path