22:00
Tue
12
Jan 2010

Paths to files and directories are special kind of strings. Sometimes they have to be processed, e.g. merged or splitted into some parts like drive letter, directory, file name and extension. Standard C library provides two function for this: makepath and splitpath. They use char* strings and operate always on all possible parts (drive, dir, fname, ext). In my opinion they are not very convenient. On the other hand, modern programming languages have more functionality in this field. For example, .NET has System.IO.Path static class with methods like GetExtension, GetFileName, GetDirectoryName.

To make operations on file paths convenient in C++, I've developed some time ago my own functions for that which operate on std::string strings. I've included them in my CommonLib library. They are similar a bit to these from Delphi :) Here is how I approach this topic: First, a common task is to extract part of a path (e.g. "C:\Windows\notepad.exe"). My functions for this are:

• ExtractFileDir returns path without final name ("C:\Windows"). It does not include trailing delimter unless returned path is a root directory, like "C:\".
• ExtractFileName returns only the final name, without preceding path ("notepad.exe"). Result is the full name including extension.
• ExtractFileExt returns only the extension of final name (".exe"). It's good to treat the dot as part of an extension because we sometimes need to strip or add an extension to an existing file name.
• ExtractPathPrefix returns only the starting point of an absolute path. For local Windows paths it looks like "C:\", but there is a second possibility - a network share like "\\ComputerName\ShareName\".

I also have some functions for processing paths:

• IncludeTrailingPathDelimiter and ExcludeTrailingPathDelimiter address a problem that sometimes paths to directories end with trailing backslash. These functions can be used whenever you want to ensure that your path ends or doesn't end with the '\'.
• ChangeFileExt is maybe a misnomer as it doesn't change an extension of a real file. It only changes file extension inside a path. For example, you can pass ".txt" to get "C:\Windows\notepad.txt". Thanks to requiring dot in the extension you can also use this function to strip extension from the path by passing empty string "" as the new extension.

Path can be absolute or relative. In Windows, absolute paths start with drive letter like "C:\" (which we can recognized by looking for colon) or network share (paths that begin with "\\"). Relative paths (where most basic example is a single file name) make sense only in some context. When we use relative paths to open real files, we address them relative to the "Current Directory" (which is a separate topic, I will write about it another time). To deal with absolute and relative paths, I've coded functions such as:

• PathIsAbsolute - tells whether a path is absolute
• RelativeToAbsolutePath - that's the most important function for me. Given base path (like "C:\Windows") and relative path (like "notepad.exe") it combines them into full path. This function is equivalent to System.IO.Path.Combine from .NET. There are many possibilities here. Base path can be relative or empty. Second path can be absolute (function directly returns second path in such case). It also automatically adds '\' separator between paths if needed.
• AbsoluteToRelativePath - does the opposite: Given full path and a base path to some drive or directory, it returns a path that points to the same file/directory relative to the base directory.

NormalizePath function preprocessess all the . and .. drectories in the path. A single dot used as directory name means "my own directory" (just does nothing) and two dots mean going up one level to the parent directory. So the path we consider here is logically equal to "C:\Windows\.\system32\..\notepad.exe". Paths like this still work, but they can look a bit unclear, so you can use NormalizePath function to clean them.

Paths in Linux are quite different. My functions also support them, although I didn't test this case in real situations yet. First of all, there are no drive letters in Linux, so absolute paths just start with '/', like "/etc/passwd". Second, a slash sign is used as a separator instead of backslash (it's interesting that slash also works in Windows). It's also more common in Linux than in Windows to meet files that don't have extension or have double extension (like "MyFile.tar.gz"). A question arises here whether what we call "extension" starts from the first or from the second dot :)

Comments (1) | Tags: algorithms c++ commonlib

Comments

Post comment