This is workig:
I have my exe in the same directory as Images folder;
Main:
|-Images
|-cross_ball
|-frame.bmp
|-game.exe
I'm refering to frame.bmp in my game.exe.
This path is workig good: "Images\\cross_ball\\frame.bmp"
This is not working:
Exe is in bin folder. bin folder is in the same folder as Images folder;
Main:
|-Images
|-cross_ball
|-frame.bmp
|-bin
|-game.exe
This path is not working: "..\\Images\\cross_ball\\frame.bmp"
If "Images\cross_ball\frame.bmp" is working, then your app's current directory isn't the Images directory like you think it is. It must be one dir up for that to work. That would also explain why moving the exe to the bin directory fails.
Are you starting your app from a shortcut or in a debugger? Shortcuts and debuggers specify the app's current directory, which isn't necessarily the same directory the exe is in.
As an experiment, replace each \ by \\ and test again.
Back slash is generally used for escape sequences like '\n'.
By putting two of them together, the run time ought to change them into one.
"Images\\cross_ball\\frame.bmp"
It appears that your logic is fine. Are you sure your process hasn't changed the current working directory - i.e. Main/bin/ might not be your working directory when you go to make this change in the executable.
Related
When I build, it succeeds with no errors. However, when I run from the IDE, I get an error (my image fails to load because it cannot find the directory).
However, if I go into the folder and run the program(.exe) it finds the image directory perfectly.
mTextures.Load(Textures::Background, "../GFX/Background.png");
^the line of code giving the directory.
I assume this is a problem with a setting I didn't enter correctly in my compiler?
I am using Code::Blocks on Windows.
Your debugger's current directory (i.e. the current directory used when you execute the application from within codeblock) is probably incorrect. Check your project settings, and fix the current directory to your target directory (the one which contains the executable itself).
Specific instructions are here.
It's because you're using a relative path in your file name:
"../GFX/Background.png"
the .. is saying "go up one directory form the current directory". If you want to be able to run your program anywhere, use an absolute path, something like:
"/home/me/GFX/Background.png"
Add the full path where the image exist with double slash.
mTextures.Load(Textures::Background, "C:\\Program Files\\..\\..\\GFX\\Background.png");
I'm quite confused about this weird behaviour of my .cpp project. I've got the following folder structure:
include/mylib.h
myproject/src/eval.cpp
myproject/data/file.csv
myproject/Makefile
In eval.cpp I include mylib.h as follows:
#include "../../include/mylib.h"
and compile it through Makefile:
all:
g++ -I include ../include/mylib.h src/eval.cpp -o eval.out
Now in my eval.cpp I'm reading the file.csv from data directory and if I refer to it like this
../data/file.csv
it doesn't find it (gets empty lines all the time), but this
data/file.csv
works fine.
So, to include mylib.h it goes two directories up (from src folder) which seems right. But it doesn't make sense to me that to refer to another file from the same piece of code it assumes we are in project directory. I suppose it is connected with Makefile somehow, but I'm not sure.
Why is it so?
EDIT: After a few thing I tried it seems that the path which is used is not the path from binary location to the data location, but depends on where from I run the binary as well. I.e., if I have binary in bin directory and run it like:
./bin/eval.out
It works with data/file.csv.
This:
cd bin
./eval.out
works with ../data/file.csv.
Now it seems very confusing to me as depending on where I run the program from it will give different output. Can anyone please elaborate on the reasons for this behaviour and if it is normal or I'm making some mistake?
It is so because (as explained here ) the compiler will search for #included files with quotes (not with brackets) with the current working directory being the location of the source file.
Then, when you try to open your .csv file, it's now your program that looks for a file. But your program runs with the current working directory being myproject/ which explains why you must specify data/file.csv as your file path, and not ../data/file.csv. Your program does not run in your src folder, it will run in the directory the binary ends up being invoked from.
You could have noticed that in your Makefile, your -I options specify a different path for your header file than your .cpp file.
EDIT Answer: It's quite simple actually and completely normal. When you invoke your binary, the directory which you're in is the current working directory. That is, if you run it with the command ./myproject/bin/eval.out, the current working directory is . (e.g. /home/the_user/cpp_projects). My post was a bit misleading about that, I corrected it.
Note: You can use the command pwd in a command prompt to know which is the current working directory of this prompt (pwd stands for "print working directory").
I have the following directory structure
(root)
/ | \
bin resources src
| | |
Debug dot.bmp .cpp
|
.exe
I would like the .exe file to use dot.bmp.
Here's the code from the .cpp file that loads dot.bmp
player_img = il->load_image( "dot.bmp" );
I feel like I need to modify this line of code, but after changing it to:
player_img = il->load_image( "../resources/dot.bmp" );
I still get an error saying that the image couldn't be loaded.
What do I need to change? Is this even possible, or should I just give up and put the image in the same directory as the .exe?
You need to go down one further level in order to get to the root.
../../resources/dot.bmp
Your executable is in bin/Debug but I think you coded under the assumption that it is in bin.
Assuming you are on Windows, the relative path will be relative to the current working directory rather than the directory where the executable resides. Often they are the same thing, but not necessarily.
I would be inclined to use fully-qualified paths and pre-pend the directory where the executable lives. You can obtain this by calling GetModuleFileName passing NULL as the hModule argument. This will return the full path to the executable so you will need to strip off the file name portion.
You will also need to think about deployment. This structure looks like your development structure but you may want a different organisation when you deploy the program. For example, I'd expect the executable to live in the bin directory when deployed.
One final thought. Assuming the images that your program needs is known at compile time it would be much easier to link them into the executable as resources. That way you simply don't have to worry about these issues at all and the executable can stand alone.
I have the following code (simplified)
int main()
{
ifstream myFile("input.txt");
if(myFile.is_open())
cout<<"test";
}
However myFile.is_open() is returning false;
why?
I'm using eclipse and the input.txt file is right in the src folder with the .cpp file...
Thanks!
Every executable is - by default - ran from the directory of your project. So for a tree like this:
project
|- src
| |- a.cpp
| |- b.cpp
| |- foo.txt
|
|- Debug
| |- a.exe
|
|- foo2.txt
You shall use the paths like src/foo.txt or foo2.txt. Your exe is located in Debug directory, but it will be ran from your project's directory anyway. In this way, every build configuration's executables are ran in the same way (from the same place).
You can change your working directory and arguments under Run configurations (pull-down menu next to the "run" icon). Switch to tab "Arguments", uncheck "use default" and set whichever you'd like if the default's not OK for you.
You have the input.txt in your source folder but the application is executed from the Debug folder; from the 'source', it's located at ..\Debug. Just put your text file there and it should work fine.
If you do not specify a full path, the program will search in the current directory, that probably in your case is the directory where the executable is built edit: it turns out that by default it's the project directory (thanks #Kos).
You can move input.txt in that directory, specify a full path (or a correct relative one) or instruct your IDE to start the executable with a different current directory (I don't know if with Eclipse it's possible, I suggest this because with VS you can do that).
By the way, in general you should avoid to hardcode paths in your sources.
Check the working directory Eclipse sets for you. It might be that of the binary. Try placing the input.txt file in the same directory as that of the binary Eclipse compiles from your code, and then run the application.
To find the working directory setting of your project look in the project's settings dialog.
That said, it's probably a good idea to code in a manner independent from your working directory. You might set the binary's install directory in preprocessor constant string, and have your install script (or configuration script) set that #define to the proper directory. Or, if that's not an option, then you might fetch the directory value at runtime.
You probably have to set up eclipse's working directory to your src directory. I have no idea what the default is.
Has anyone been successful doing this?
It should work by just calling make in the root directory if:
1) You have the GOROOT env variable set
2) You have access to the directory in which go is installed
I had neither. Point one can easily be solved by using gomake instead of make. The problem is that i haven't added the bin directory of the go directory to the root users PATH, so i had to start up a root termianl, export the go bin directory to the PATH and then call gomake in the Go-SDL directory.
My case seems to be pretty special though, but maybe it can help.