Ha, I knew it should be doing that (the overloaded operator). Otherwise it would never fail and I would never see the error.
As for the DATA folder path, no, there's no simple, cross-platform way of getting the executable directory. At most you can get the current working directory but even that isn't cross-platform, because getcwd() is the POSIX way of doing it but Microsoft decided it should change the name of its POSIX-compatible function to _getcwd() and leave getcwd() as-is in its libraries, so at the very least you have to check if you're running Windows or POSIX and use the correct funcion for that. This is something that I'd probably use a #define macro for.
It's such a simple and, I'd say, common operation, that I don't know why libraries such as SDL don't have a cross-platform way of doing it implemented already. Anyway, I gave it a try and managed to get it to work. I Attached the patch to this post, so you can try it.
The basic idea is to get the path to the executable from the program arguments (args[0]) and add the DATA folder to it. There are two possible scenarios for this: you can either launch the executable by specifying the full path (something like C:\Program Files\Games\OpenXCom\openxcom.exe or /usr/bin/openxcom), or by specifying the path relative to the current working directory (like ../bin/openxcom, assuming you were inside the src folder).
In the first case, we just need to strip the executable name from the path, append the DATA folder and we're done.
The second case requires a bit more tinkering but is quite simple; we just append the relative path used to launch the game, to the current working directory, use realpath() to get the absolute path from that, strip the executable name, add the DATA folder and there we go.
I made it just for testing, so there are a couple of things missing.
The first a is that I didn't include support for Windows but the changes should be minimal, such as checking for "C:" or equivalent, instead of checking just for "/", when determining if we have an absolute path to the executable.
The second is that this assumes that DATA will always be in the same folder as the executable, which is not the case if you want to package the game for distributing for most linux distributions, since the executable will be in /usr/bin or equivalent, and the data will be in /usr/share.
For now this solution works and allows me to do what I wanted, which is to launch the game from the src folder, because otherwise, I have to
cd ../bin
./openxcom
everytime I compile the game on the command line (this shouldn't be a problem if you're using an IDE such as CodeBlocks).
But later on, this needs to be thought of, if you want to allow the game to be distributed for Linux in a "correct" way.
