I moved from Windows to Mac and now I'm experiencing a problem with the file input/output classes: ifstream & ofstream.
In Windows when you run with g++/Code Blocks
ofstream out("output.txt");
out << "TEST";
out.close();
A new file "output.txt" will be created in the same directory.
However in MAC OS X, this file is created in my home directory: /Users/USER_NAME/output.txt
How can I have this file in the same directory together with the executable?
P.S. I'm using GCC and CodeBlocks. There are no projects - I'm just compiling a single source file.
The stream classes, like all other file-opening functions, use the current directory when you provide a relative path. You can control the current directory with a function like chdir, but a better solution is to use fully qualified file names. Then you remove your program's dependency on the current directory.
The file is simply created in the current working directory. Change working directory or provide full path.
The working directory is initially set when your program starts. When you start it from the command line, you inherit the current working directory from the shell. In CodeBlock, one of the project options is the execution working dir' for debug runs.
(See also http://www.gamedev.net/community/forums/topic.asp?topic_id=571206&whichpage=1�)
You'll need to provide a full, absolute path to the file you are trying to create.
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.
In my program, I have a button that I want to open a text file in a relative directory. I'm using QDesktopServices like this:
QDesktopServices::openUrl(QUrl::fromLocalFile("file:///stuff/block_settings.txt"));
When the button is pressed, nothing happens.
The file is in a folder named "stuff" that resides in the same location as my .exe. It is the same directory used for all my other tasks.
What am I doing wrong?
Thanks.
The file is in a folder named "stuff" that resides in the same location as my .exe. It is the same directory used for all my other tasks. What am I doing wrong?
Seems like your full path is an overcomplication. I would suggest to use this intead:
QString QCoreApplication::applicationDirPath() [static]
Returns the directory that contains the application executable.
For example, if you have installed Qt in the C:\Qt directory, and you run the regexp example, this function will return "C:/Qt/examples/tools/regexp".
On Mac OS X this will point to the directory actually containing the executable, which may be inside of an application bundle (if the application is bundled).
Warning: On Linux, this function will try to get the path from the /proc file system. If that fails, it assumes that argv[0] contains the absolute file name of the executable. The function also assumes that the current directory has not been changed by the application.
So, you would be writing this code:
QDesktopServices::openUrl(QString("%1/stuff/block_settings.txt")
.arg(QCoreApplication::applicationDirPath()));
I fixed the issue. Changed to:
QDesktopServices::openUrl(QUrl("file:stuff\\block_settings.txt"));
Not sure how that works because I don't see that configuration on any tutorial anywhere but w/e
I am working on figuring out how to use Xcode 4 to debug c++ projects.
I have basically copy pasted a working c++ executable that when compiled from the terminal ran fine.
However, i was thinking it might be nice to use Xcode for debugging. So I am trying to migrate the single .cpp file into Xcode as a command line tool.
I need to read in a file called numbers.txt (which I supply through a command line argument) which is located in my project directory, and then out put to a file (whose name I also specify as an argument.)
The problem I am running into is that the files that are supplied as command line arguments are failing to open.
ifstream in;
ofstream out;
in.open(argv[1]);
out.open(argv[2]);
I have checked to make sure that the arguments are being properly passed and are named correctly. The ifstream in is being supplied with `numbers.txt', which I want to open a text file that I already have.
However when I check to make sure the ifstream is open:
if(in.is_open() == false){
cerr << "Unable to open input file" << endl;
return 1;
}
I get the error.
I suspect this has something to do with how Xcode organizes the project.
my numbers.txt file is just sitting in the Xcode project folder, and I have only one .cpp class and one product, the executable.
anyone know what I am missing here?
The executable built by Xcode is in a different folder than the project. Passing in the name of the file without an absolute path before it will cause the executable to look for it in the wrong place, which is why it can't be found. Some of the possible solutions are to include the file as part of the build process (so it ends up in the same directory as the executable) or to pass the file to be opened by its absolute path. There are other ways to solve the problem, too, but hopefully that should be enough to get you started.
Old thread, but i have faced the same problem now, and it is easy to solve. Just copy the file in the build phase.
Here is an screenshot of the final result (note the destination, subpath and checkbox):
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