I have my visualstudio vcproj file at c:\vsproj\example\test\test.vcproj
under this path i have some other files like e test.cpp file and also a dll test.dll is there.
so totally under tha path c:\vsproj\example\test i have
1) test.vsproj 2) test.dll 3) test.cpp
normally to get the cuurent folder path we use ".\" so i have applied the technique to get
the dll path which is reside where the test.cpp file is there
now in test.cpp some where else i have written
string str= ".\\test.dll" to get the test.dll path. But i am not getting the dll path into the
my idea is i have to get the path in the variable str="c:\vsproj\example\test\test.dll"
but i am getting ".\test.dll" wat is wrong can u correct me??
variable str; how to get the dll path that in this scenario...
string str= ".\test.dll" to get the
test.dll path. But i am not getting
the dll path into the
my idea is i have to get the path in
the variable
str="c:\vsproj\example\test\test.dll"
but i am getting ".\test.dll" wat is
wrong can u correct me?? variable str;
how to get the dll path that in this
scenario...
It's doing exactly what you're asking it to do. What you appear to want it to do isn't going to be achieved this way.
You'll need to get the current working directory and prepend it to "\test.dll", rather than just specifying "\test.dll".
check with Filemon program. it shows you where the code is trying to search and show you where you do wrong..
String has nothing to do with paths. How could it understand what you want? It is just a mere collection of letters.
As others suggested, try using _getcwd and appending "\test.dll" at the end of it.
The function you're looking for is GetFullPathName(). It works on C strings, not C++ strings though. Have a look at the examples in the linked article.
(You can safely ignore the panicky bits about multi-threaded applications. The same problem actually exists for single-threaded app too. If the current directory changes, ..\xyz\ changes too.)
you can use _getcwd(char* buf, int len) to get the current working directory:
Related
I already know how to set a relative working directory path and access resources inside of visual studio. However, when I build my solution and move the exe to a separate file I have to include all the resources in the same directory as the exe. I'd prefer to have a folder with said resources alongside the exe to keep things clean. Is there a macro I need to use? Is the working directory the right setting to change for this?
example
Sorry for this incredibly basic question, but I think I lack the vocabulary to accurately describe the issue.
For a Windows solution, GetModuleFileName to find the exact path of your EXE. Then a simple string manipulation to make a resource path string.
When you program starts, you can use this to ascertain the full path of your EXE.
std::string pathToExe(MAX_PATH, '\0');
GetModuleFileName(nullptr, szPathToExe.data(), MAX_PATH); // #include <windows.h> to get this function declared
On return, szPathToExe will be something like "C:\\Path\\To\\Your\\Program\\Circle.exe"
Then strip off the file name to get the absolute path
std::string resourceFolderPath = szPathToExe;
size_t pos = strPath.find_last_of("\\");
strPath = strPath.substr(0, pos+1); //+1 to include the backslash
Then append your resource folder name and optionally another trailing backslash.
resourceFolderPath += "res\\";
Then change all your I/O calls to open files relative to resourceFolderPath
You should probably add reasonable error checking to the above code such as validating the return code from GetModuleFileName and find_last_of calls.
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.
Related to this question.
We have a code generate tool (for cross platform C++ source files) and I need to correct the path returned by the ____FILE____ macro to have the correct case so that source files generated under Windows will still compile on case sensitive systems (eg. Linux and OSX).
I'm using Qt and have tried a few combinations of QFileInfo and QDir but they all seem to keep the lowercase path passed to it.
Any suggestions?
Thanks
I have a few suggestions, but I am not sure if it will work.
If you have not already tried this. Use QDir to search through the directories for the correct path.
Say for instance that you are looking to include the file "C:/Programming/myProject/oneSource.cpp", then you do the following: Split the incoming path into "c:", "programming", "myproject", "onesource.cpp".
Then you use QDir do search through "C:" for a folder that (ignoring case) matches "programming", but use the path returned from QDir. Rinse and repeat. This way you are not really passing any wrong paths to QT it will simply use the one it reads natively.
Try the exact same thing, but use a different library like dirent or even the native windows API.
You know the filename in your tool, so there's no reason at all to use the __FILE__ macro. Just emit the correct file name as a string literal.
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"
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