I am using C++ and using the G++ compiler to compile my game. It compiles fine, but I'm linking to images, and they aren't showing up in-game. I tried using local links and full links but I couldn't get either one to work. Is there a special way to link to a file in Linux?
Code Example:
StatBack.load_image("\\Dropbox\\Pirate_Entertainment\\images\\hud_thumbnails\\backdrop.png");
StatBack.apply_image_surface(nCurrentX - 180,nCurrentY-230,0);
StatBack.v_DeleteImages();
Unless you are using some kind of portability wrapper which transforms your backslashes to forward slashes, you probably want to use forward slashes:
StatBack.load_image("/Dropbox/Pirate_Entertainment/images/hud_thumbnails/backdrop.png");
or, more likely, using a relative path:
StatBack.load_image("Dropbox/Pirate_Entertainment/images/hud_thumbnails/backdrop.png");
In fact it is safe to use a forward slash in windows as well. The ANSI C standard allows forward slashes to be used in file names as the path separator.
you should use / as a path separator instead of \ (that C++ reduces to ).
Related
Whenever I do any sort of file read or write, I always use the '/'
but I've seen some examples where the value of the given filepath is '\\' instead.
So what's the difference?
Am I doing it wrong or introducing bugs if I use '/'?
There's nothing wrong with using / on systems that support it. In fact, on UNIX systems it's the only thing that works.
Windows supports both / and \ as path separator in most situations.
Note that a platform agnostic option is available in the form of std::filesystem::path.
The common convention used for managing paths in Windows is just reciprocal of Linux. It's formatted something like: C:\abc\abc.txt, although it's your own choice which method you would prefer to access/write the file or folder.
This \\ is an escape sequence to print a common backslash to read or write the file. Note that you won't able to use a single backslash between string value since it reads next character as an escape sequence (e.g. \n, \b, etc.)
That's it.
I came across this in a source code:
#define DEFAULT_PATHNAME "#SDK_DEFAULT_PATHNAME#"
what does the # symbol denotes in this case ?
Edit:
Camke was used to generate this project.
This value is used as a path to a file
CMake has this wonderful command configure_file which allows your build system to generate a file used in the build where the content (i.e. value) of the variable SDK_DEFAULT_PATHNAME will be put in the location of #SDK_DEFAULT_PATHNAME# in the "configured file".
In this case it's part of the string, nothing special.
On Windows for example, you could have the following string:
#define DEFAULT_PATHNAME "%PATH_TO_SDK%"
with the % character playing the same role. In C++ and in strings in general, it has no meaning (unlike \ which is used to escape characters).
EDIT:
To clarify, esp. with regards to your comment:
that value is used as a path to a file for the program to open, when removing the # the program broke
The operating system may need to read this character, as I mentioned it with the % example on Windows, to consider the path as something to look up in the environment variables for example. Once again, it has no special meaning in C++ or strings in general, but may have for other programs.
I use the __FILE__ macro for error messages. However, sometimes the path comes back as E:\x\y\/z.ext. It does this for specific files.
For example, E:\programming\v2\wwwindowclass.h comes back as E:\programming\v2\/wwwindowclass.h and E:\programming\v2\test.cpp comes back as E:\programming\v2\test.cpp. In fact, the only file in the directory that works seems to be test.cpp.
To work around this, I used jmucchiello's answer to this question to replace any occurrence of "/" with "\". This worked fine, and the displayed path changed to a normal one.
The problem was when I tried it on Windows 7 (after using XP). The string came up as (null) after calling the function.
Along with this, I sometimes get some seemingly random error 2: File not found errors. I'm unsure of whether this is related at all, but if there's an explanation, it would be nice to hear.
I've tried to find why __FILE__ would be returning the wrong string, but to no avail. I'm using GNU g++ 4.6.1. I'm not actually sure yet if the paths that were wrong in XP were wrong in Windows 7 too. Any insight is appreciated.
The function in the linked question appears to return NULL if there are no changes to make. Probably Windows 7 doesn't suffer from the \/ problem (in some cases).
As per MSalters's comment:
Typically, the compiler does so when you pass #include "v2/wwwindowclass.h" to the compiler.
Since every file has its own include statements, you can (but shouldn't) mix the two styles.
This was the case. My compiler automatically adds a forward slash.
What is the correct way to include files
#include "../myDirecoty/myFile.h"
or
#include "..\myDirecoty\myFile.h"
the difference is the direction of "/" or "\".
This is the correct way:
#include "../myDirecoty/myFile.h"
There is no difference, but the first form is more "clear" because sometime people thinks to \ as an escaping character in string (but include path are not strings)
normal slashes "/", best compatible
From what I've seen looking through the code on my computer, you should use forward slashes ('/').
The backslash \ is used on Windows and DOS, while the slash / is used on all UNIX/POSIX compatible systems (like Linux and Mac OS X). So the later can produce a file-not-found error on non-Windows systems. AFAIK all Windows compiler do support the slash /, so this is one to use.
Edit: See also this SO question.
In building a C++ project with the GNU tool chain, make tells me ~
src/Adapter_FS5HyDE.d:1: *** multiple target patterns. Stop.
Search, search, search, and I found out that make thinks that it has multiple targets because the path to my included headers has spaces in it. If you've got your headers stored in some sane place like C:\Program Files then you can take care of this by using the old DOS paths (e.g. C:\PROGRA~1). However, when you have your headers in a truly insane place like My Documents you can get around the problem with MY DOC~1 because there's still a space.
Any idea how to tell my compiler to look in My Documents for headers without make confusing the path as two objects?
(Note: Feel free to throw tomatoes at me for putting header files in My Documents if you'd like, but there is a little rationale for doing that which I don't feel like explaining. If the solution to this question is easy, I'd rather keep it the way it is.)
You can figure out what the old path is by doing a DIR /X in your command prompt.
Or, most of the time you can fake it with the first 6 characters - spaces + ~1 + extension (8.3 paths won't have spaces).
Or, you can use quotes: "C:\Documents and Settings\Administrator\My Documents".
I don't know about make specficially, but the normal way around this is to put quotes around the path i.e.
cd "C:\Program Files\"
does that work?
Side note: the short name (8.3) for the same folder might not be the same on different OS installations. Thus, you can't be sure that C:\Program Files will always be C:\PROGRA~1.
Short names can't contain spaces in them either, so the usual short name for My Documents is MYDOCU~1, not MY DOC~1.
You can find the exact short name for any folder or file (including My Documents) using dir /x <filename>.
If you are using the GNU toolchain from Windows command line (cmd.exe), you should be able to use quotes (") around the folder/file names to work around this problem.
For some folders, including My Documents, you can specify an alternative location. To do this, right-click the folder, select Properties, select Location tab, and away you go. I use this to put my downloads and music on another drive (D:).
Write a wrapper script (e.g. batchfile) to translate the path names to short form.
I have a script "runwin" that does stuff like this - instead of, e.g. gcc <args> I can call runwin gcc <args>;
runwin will make heuristic guesses as to which arguments are filename paths and translate them, then call gcc on the resulting string of arguments.