Handling external ressource (aka How can I find a process' executablefile)

[mathieu]

Hi,

This is slightly off-topic (not purely C++). But I was wondering how
do people handle ressources (input file) in their C++ applications in
a cross platform way ?
I tought first of using relative path from the current running
executable, but I could not find a portable way of doing other than
getcwd/_getcwd + argv[0] which may or may not always work.

My current implementation is to produce a C++ file that gets
compiled during the build:

http://gdcm.svn.sourceforge.net/view...xx?view=markup

Thanks for suggestions !
-Mathieu

[AnonMail2005]

On Jun 28, 8:39*am, mathieu <[e-mail]:

Hi,

* This is slightly off-topic (not purely C++). But I was wondering how
do people handle ressources (input file) in their C++ applications in
a cross platform way ?
* I tought first of using relative path from the current running
executable, but I could not find a portable way of doing other than
getcwd/_getcwd + argv[0] which may or may not always work.

* My current implementation is to produce a C++ file that gets
compiled during the build:

http://gdcm.svn.sourceforge.net/view...e/DataDictiona...

Thanks for suggestions !
-Mathieu

In the systems I've done, code in core libraries use fully qualified
path names and it's the job of the application to supply those names
to the libraries.

For apps, you can easily use environment variables which specify the
full path name or the path excluding the filename. If I'm not
mistaken
getenv is part of the C library which makes it cross platform.

But I found that sprinkling getenv calls around code can lead to a
maintenance headaches so what I did was put everything in a config
file
and have the app take the config file name as it's only command line
arg.

The config file is just name/value pairs and can be any format you
like. But the key point is that I allow values inside the config
file to be specified using environment variables. Inside my cofig
file processing I expand the environment variables myself.

This approach has the benefit of environment variables but has
everything
centralized in one place - the config file.

HTH