When writing a portable c/c++ program, what is the best way to consume external files?_问答_开发者

I'm pretty new to the c/c++ scene, I've been spoon fed on virtual machines for too long.

I'm modifying an existing C++ tool that we use across the company. The tool is being used on all the major operating systems (Windows, Mac, Ubuntu, Solaris, etc). I'm attempting to bridge the tool with another tool written Java. Basically I just need to call java -jar from the C++ tool.

The 开发者_高级运维problem is, how do I know where the jar is located on the user's computer? The c++ executables are currently checked into Perforce, and users sync and then call the exe, presumably leaving the exe in place (although they could copy it somewhere else). My current solution checks in the jar file beside the exe.

I've looked at multiple ways to calculate the location of the exe from C++, but none of them seem to be portable. On windows there is a 'GetModuleLocation' and on posix you can look at the procs/process.exe info to figure out the location of the process. And on most systems you can look at argv[0] to figure out where the exe is. But most of these techniques are 100% guaranteed due to users using $PATH, symlinks, etc to call the exe.

So, any guidance on the right way to do this that will always work? I guess I have no problem ifdef'ing multiple solutions, but it seems like there should be a more elegant way to do this.

I don't believe there is a portable way of doing this. The C++ standard itself does not define anything about the execution environment. The best you get is the std::system call, and that can fail for things like Unicode characters in path names.

The issue here is that C and C++ are both used on systems where there's no such thing as an operating system. No such thing as $PATH. Therefore, it would be nonsensical for the standards committee to require a conforming implementation provide such features.

I would just write one implementation for POSIX, one for Mac (if it differs significantly from the POSIX one... never used it so I'm not sure), and one for Windows (Select which one at compilation time with the preprocessor). It's maybe 3 function calls for each one; not a lot of code, and you'll be sure you're following the conventions of your target platform.

I'd like to point you to a few URLs which might help you find where the current executable was located. It does not appear as if there is one method for all (aside from the ARGV[0] + path search method which as you note is spoofable, but…are you really in a threat environment such that this is likely to happen?).

How to get the application executable name in WindowsC++/CLI?

https://superuser.com/questions/49104/handy-tool-to-find-executable-program-location

Finding current executable's path without /proc/self/exe

How do I find the location of the executable in C?

There are several solutions, none of them perfect. Under Windows, as you have said, you can use GetModuleLocation, but that's not available under Unix. You can try to simulate how the shell works, using argv[0] and getenv("PATH"), but that's not easy, and it's not 100% reliable either. (Under Unix, and I think under Windows as well, the spawning application can hoodwink you, and put any sort of junk in argv[0].) The usual solution under Unix is to require an environment variable, e.g. MYAPPLICATION_HOME, which should contain the root directory where you're application is installed; the application won't start without it. Or you can ask the user to specify the root path with a command line option.

In practice, I usually use all three: the command line option has precedence, and is very useful when testing; the environment variable works well in the Unix world, since it's what people are used to; and if neither are present, I'll try to work out the location from where I was started, using system dependent code: GetModuleLocation under Windows, and getenv("PATH") and all the rest under Unix. (The Unix solution isn't that hard if you already have code for breaking a string into fields, and are using boost::filesystem.)

Good solution would be to write your custom function that is guaranteed to work in every platform you use. Preferably should use runtime checks if it worked, and then fallback to ifdefs only if some way of detecting it is not available in all platforms. But it might not be easy to detect if your code that executes correctly for example argv[0] would return the correct path...