[C++] Execute from command line with path to file

This article explains it pretty well, http://www.cplusplus...articles/13355/

In short, assuming a main function that looks like int main(int argc, char* argv[]) { /** ... **/ } the argc integer contains the size of the argv array which contains all the values passed by the command line. Doing myprogram.exe -f myfile would mean that myfile is the second value of the argv array, the first value is -f.

This article explains it pretty well, http://www.cplusplus...articles/13355/

In short, assuming a main function that looks like int main(int argc, char* argv[]) { /** ... **/ } the argc integer contains the size of the argv array which contains all the values passed by the command line. Doing myprogram.exe -f myfile would mean that myfile is the second value of the argv array, the first value is -f.

Thank you very much. I intend to use this file path as an argument for loading files.
I seem to recall somebody mentioning that C++ cannot see outside of the current directory the application is running from. This might be a problem I guess even though I can pass an absolute path via the command line to the starting program

Is this true?

This article explains it pretty well, http://www.cplusplus...articles/13355/

In short, assuming a main function that looks like int main(int argc, char* argv[]) { /** ... **/ } the argc integer contains the size of the argv array which contains all the values passed by the command line. Doing myprogram.exe -f myfile would mean that myfile is the second value of the argv array, the first value is -f.

actually myfile is the third value, -f the second , the first is normally the path and name of the executable itself.

Thank you very much. I intend to use this file path as an argument for loading files.
I seem to recall somebody mentioning that C++ cannot see outside of the current directory the application is running from. This might be a problem I guess even though I can pass an absolute path via the command line to the starting program

Is this true?

No , C++ can access things outside its current directory aswell unless the platform it runs on prevents it. (AFAIK no commonly used desktop platform does this atleast)

I seem to recall somebody mentioning that C++ cannot see outside of the current directory the application is running from.

It isn't really anything to do with C++. Most OS's have the concept of a current working directory. Under Windows, for example, if you run an executable from the command line, the current working directory is set to whatever directory the console is currently in. If you run an exe by double-clicking it in an explorer window, the working directory is set to that particular folder.

If you right-click a shortcut in Windows and go to Properties, you can see a Start In edit box which is set, by default, to the same folder as the target of the shortcut. When the target is launched via the shortcut, the working directory is set to this path.

Normally a command line program will just use the folder the console is currently in as the current working directory. If you actually need to get the folder that the exe is installed into, AFAIK there is no standard way to do this. Under Windows, GetModuleFileName() will return the fully qualified path to the exe, regardless of the current working directory.

I seem to recall somebody mentioning that C++ cannot see outside of the current directory the application is running from. This might be a problem I guess even though I can pass an absolute path via the command line to the starting program
[/quote]
This has nothing to do with C++, and everything to do with the OS and runtime implementation. C++ doesn't really have a concept of the filesystem. Even with just relative paths, you can pass a path that includes ".." to jump out of the working directory. This is often simpler than building an absolute path.

actually myfile is the third value, -f the second , the first is normally the path and name of the executable itself.

That depends on your definition of "normally". Not only is the contents of argv[0] OS dependent, it's also shell dependent, or rather dependent on the program used to launch the program. One shell can supply the full path to the executable and another shell on the same OS might only supply the file name. For that matter, if the executable is launched through a symlink, the name of or path to the symlink might be used as argv[0] instead. Some programs actually depend on this behavior and do different things based on the symlink name.

On the machine I'm on now, I have the standard Windows 7 explorer and cmd.exe shells. If I create a program with MSVC 2010 that dumps argv[0] to the console, when I start that program with explorer or the IDE (at least with default debugger settings), it prints out the whole path to the file name. However, with cmd.exe it prints out the string used to launch the file (minus any arguments). That is, if I type "temp.exe" into cmd.exe the program displays "temp.exe". If I launch it with just "temp" it displays just "temp". If I type "../Debug/temp.exe" it displays that instead. Of course, I specify MSVC 2010 for a reason. argv isn't something Windows parses and hands to the program; it just hands the program the command line used to launch the program. It's up to the standard library implementation to parse that into argv, and according to the C++ standard argv[0] is 'the name used to invoke the program or ""'. A fully conforming standard library implementation is free to strip the path or even always return "" (though that would be a crappy implementation). With (im)proper use of CreateProcess() I can get this program to run with an argv[0] of "deep fried *tofu*", though that falls out of most definitions for "normally".

Even with just relative paths, you can pass a path that includes ".." to jump out of the working directory.

...assuming the OS has a *nix or DOS lineage, which thankfully comprise most of the PCs out there now. If you have the unlikely misfortune of developing for Classic Mac then you would use initial colons to reach parent folders with "::" being the parent and more colons specifying higher up the directory tree. Other less common platforms can have similarly idiosyncratic methods of specifying relative directories.