Method for abstracting filesystems in a C program

I'm starting out a program in SDL which obviously needs to load resources for the filesystem. I'd like file calls within the program to be platform-independent. My initial idea is开发者_如何学运维 to define a macro (lets call it PTH for path) that is defined in the preprocessor based on system type and and then make file calls in the program using it. For example

SDL_LoadBMP(PTH("data","images","filename"));

would simply translate to something filesystem-relevant.

If macros are the accepted way of doing this, what would such macros look like (how can I check for which system is in use, concatenate strings in the macro?)

If not, what is the accepted way of doing this?

The Boost Filesystem module is probably your best bet. It has override for the "/" operator on paths so you can do stuff like...

ifstream file2( arg_path / "foo" / "bar" );

GLib has a number of portable path-manipulation functions. If you prefer C++, there's also boost::filesystem.

There's no need to have this as a macro.

One common approach is to abstract paths to use the forward slash as a separator, since that (almost accidentally!) maps very well to a large proportion of actual platforms. For those where it doesn't, you simply translate inside your file system implementation layer.

Looking at the python implementation for OS9 os.path.join (macpath)

def join(s, *p):
  path = s
  for t in p:
    if (not s) or isabs(t):
        path = t
        continue
    if t[:1] == ':':
        t = t[1:]
    if ':' not in path:
        path = ':' + path
    if path[-1:] != ':':
        path = path + ':'
    path = path + t
  return path

I'm not familiar with developing under SDL on older Macs. Another alternative in game resources is to use a package file format, and load the resources into memory directly (such as a map < string, SDL_Surface > )

Thereby you would load one file (perhaps even a zip, unzipped at load time)

I would simply do the platform-equivalent version of chdir(data_base_dir); in your program's startup code, then use relative unix-style paths of the form "images/filename". The last systems where this would not work were MacOS 9, which is completely irrelevant now.