I am developing a prototype for a game, and certain gameplay rules are to be defined in an ini file so that the game designers can tweak the game parameters without requiring help from me in addition to a re-compile. This is what I'm doing currently:
std::ifstream stream;
stream.open("rules.ini");
if (!stream.is_open())
{
throw new std::exception("Rule file could not be opened");
}
// read file contents here
stream.close();
However, my stream never opens succesfully. Diving deep into the STL source during debugging reveals that _getstream() (as defined in stream.c) keeps on returning NULL, but I just can't figure out why this is. Help, anyone?
Edit: Rules.ini is in the same directory as the .exe file.
You are assuming that the working directory is the directory that your executable resides in. That is a bad assumption.
Your executable can be run from any working directory, so it's usually a bad idea to hard-code relative paths in your software.
If you want to be able to access files relative to the location of your executable, you should first determine the path of your executable and create a fully qualified path from that.
You can get the name of your executable by examining the argv[0] parameter passed to main(). Alternatively, if you're on Windows, you can get it with GetModuleFileName() by passing NULL as the first parameter.
Is the scope of your open stream correct.
"rules.ini" isn't a full path so it has to be relative so what is it relative to. Or do you need to use full path there.
(wild assumption here) you are using visual studio. During debug, your program is going to search the project directory for "rules.ini"
However, if you try executing your program from "myproject/debug/myexe.exe", it should run fine because it is going to search "/debug" for rules.ini
Like its been mentionned you should specify the full path because relative path tend to lead to errors
Related
I'm trying to use Mac Instruments Time Profiler to optimize my code for building a MandelBox. I found how to make my executable my target process, but when the program runs, it gives me an error in the Console window saying it cannot find the .txt file associated with the program.
Do I need to tell the profiler where to look to find the file? The text file is already in the same directory as the executable. Any thoughts? Thanks.
This problem is not unique to Instruments. The same thing would presumably happen if your current working directory was something other than the location of your program. For example, if you were to do cd / ; /path/to/yourprogram.
You either need to make your program find its own location and then find its text file as a sibling in the containing directory or take the path of the text file as an argument. Or, you will always have to set the working directory to your program's location before invoking it.
That last approach is an immediate workaround for the problem with Instruments. On the panel where you choose the target executable, you can also configure various parameters, such as arguments, environment variables, and the working directory. Set the working directory to the directory that contains the text file and it should work.
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 accidentally made a big blunder:
In my C++ program, I did:
std::string oldFilePath = "/Users/blah/somepath/foo.xml";
std::string newFileName = "foo.xml" //Blunder! Forgot to prefix the new path!
int status = rename(oldFilePath.c_str(), newFileName.c_str());
I forgot to prefix the new path, and just put the filename (without a path) for the new name that the file should be renamed to. As a result the file has vanished from the old path, and I don't know where its gone to!
Where is the file ? Is there a way to recover it ? (Time Machine is disabled for this folder, so I can't do that!)
EDIT: Where would the compiled file generated by Xcode for a C++ application be ?
EDIT: If you're running the program through xcode, it should be in:
~/Library/Developer/Xcode/DerivedData//Build/Products/Debug/
Don't forget the ~ in the above path!
If the operation succeeded (status == 0), the file would be in the current directory of the process when it was run. It is hard to predict where that might be, but $HOME is one plausible candidate (maybe /Users/blah/foo.xml). You should be able to find it, either with the find command or with Spotlight.
I don't use the XCode UI (or other IDEs), in part because I don't like the lack of control over things like 'where the program is put' and 'what is the current directory when I run the program' (and for the rest because I'm a dinosaur). AFAIK, the executable should be in a directory underneath the folder where you created the project. Again, Spotlight or find should be able to help you, at least if you chose a distinctive name for the program. The project directory is another place to look for the foo.xml file too.
Our Computer Science teacher has given us a project to make a fully functioning console application using C++. And I have started to make it. But I got stuck at some point. I want to open an editable text (.txt) file using the open() function. But I made a separate folder for all the text files. Usually I have to provide a full directory path in the open() function, which is F:\Work\C++\SchoolProject\TextFiles in my case. But what if I copy the SchoolProject folder in a portable drive and take it to my friend's home and try to run the program in their computer. Will it work? I'm asking because it is not necessary that they will have the Work folder in the F directory or maybe they may not have the F disk at all. So in that case the path will change. So what path I have to type in the open() function so that the program works in each and every computer without changing the address in the open() function every time I try to run the program in some other computer. A source code may be helpful with explanation. Thank You!
Instead of using absolute paths, you should use relative paths. When you run your program from a folder, this is your working path. You can then open files inside this folder or subfolders of this folder by passing only the file name or folder and file name to the open function. So instead of opening C:\... simply open someFolder\someFile.txt.
You could consider having the filename that you parse in as part of a command line argument, like this:
int main(int arg, char* args[]) {
FILE *newfile = fopen( args[1], "r");
}
You can not be sure all computers have the F: drive mapped correctly so it is better to use
Universal Naming Convention (UNC) names i.e. "\server\share\path\file".
A nice way to achieve the same is by using Boost Filesystem, but this makes your code more complicated since you are depending on an external library (read: the students might be confused). The documentation for Boost Filesystem is found here: http://www.boost.org/doc/libs/1_43_0/libs/filesystem/doc/index.htm
I have not yet found a definitive answer about this. I am trying to have access to files in subfolders from my .EXE. When I have asked before, people tell me to use the absolute location i.e. "c:/game/info/" if I wanted to access something in /info/
But it is completely unreasonable for me or anyone to assume that someone is going to use their program from the same directory. What if the user only has a D drive? That sort of thing.
So my question is: how can I access a file in a subdirectory from my executable without relying on the entire path?
Your title says "Windows", so I'll give a WinAPI-specific answer.
On Windows, you can find your application directory with GetModuleFileName(NULL, ...), and PathRemoveFileSpec. Then PathAppend will make the full path to your data files.
Or you can store the data inside you .exe file as Win32 resources, so they never get separated.
Please note that this approach generally works only for read-only access to data files. If you try to write files in your application directory, you might be blocked by ACLs (depending on install location and local security settings of the computer).
Use GetModuleFileName (Retrieves the fully-qualified path for the file that contains the specified module. The module must have been loaded by the current process.)
char strExePath [MAX_PATH];
GetModuleFileName (NULL, strExePath, MAX_PATH);
You'll then need to extract the folder path (someone has already posted how to do that), and combine your path.
Make or use an installer that asks the user where to install the executable and writes that path to the registry in a well-known location for later reference.
if you use:
#include <fstream>
ifstream stream("file");
it will be working. "file" is file in directory with your exe. Of course if you want go up or down in folders hierarchy use "..\file" or "folder\file"