|
|
|
|
||||||
![]() |
|
|
LinkBack | Outils de la discussion |
|
|
#1 |
|
Messages: n/a
Hébergeur: |
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 |
|
|
|
#2 |
|
Messages: n/a
Hébergeur: |
On Jun 28, 8:39am, mathieu <mathieu.malate...@gmail.com> wrote:
> 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 |
|
![]() |
| Outils de la discussion | |
|
|