Boost logo

Boost :

From: mfdylan (dylan_at_[hidden])
Date: 2002-02-21 22:30:08

I'm interested in getting feedback on whether something like the
following is a workable design:

template <class E, class T = platform_dependent_default>
class basic_pathname
        typedef std::basic_string<E> string;

// constructors etc.
        basic_pathname(const string& name);
        basic_pathname(const E* name)
        template <class U>
        basic_pathname(const basic_pathname<E, U>& other);
        pathname& operator=(const pathname& other);

// full name as a string
        const string& str() const;

// everything up to and including the last '/', "." if none
        pathname dirname() const;

// everything from the first '.' after the last '/' onward
        pathname suffix() const;

// everything after the last '/', stopping at the first '.'
        pathname basename() const;

// everything after the last '/'
        pathname filename() const;

// everything after the last '.' after the last '/'
        pathname extension() const;

// everything up to and include the first '/', "" if none
        pathname rootname() const;

// true if any part of the filename ends with this pattern
        bool suffix_is(const string& pattern);

// sets the dirname as defined above, adds '/' if needed
        void dirname(const string& name);

// sets the suffix as defined above (should begin with '.')
        void suffix(const string& name);

// sets the basename as defined above
        void basename(const string& name);

// sets the filename as defined above
        void filename(const string& name);

// sets the extension as defined above, adds '.' if needed
        void extension(const string& name);

// sets the rootname as defined above
        void rootname(const string& name);

// platform-dependent check whether dir is fully specified
        bool is_absolute() const;

// inverse of above
        bool is_relative() const;

// generate an absolute path relative to wd
        pathname absolute(const pathname& wd) const;

// generate an absolute path relative to OS's cwd
        pathname absolute() const;

// determine relative path given wd
        pathname relative(const pathname& wd) const;

// determine relative path using OS's cwd
        pathname relative() const;

// true if path is empty
        bool empty() const;

// platform-dependent comparison
        int compare(const basic_pathname& other) const;
typedef basic_pathname<char> pathname;
typedef basic_pathname<wchar_t> wpathname;

// also allow operator==, operator!=, maybe >, >= and <, <=

The template parameters are E = char type (either char or wchar_t)
and T = platform-specific traits. An example:

template <class E>
struct pathname_style_win32
// path delimiters { \, / }
        static const E* delims();

// check if name starts with x:\ or \\ (x = any alpha)
        static inline bool is_absolute(const E* name);

// case insensitive comparison (maybe based on locale?)
        static inline int compare(const E* left, const E* right);

Currently the suffix separator '.' isn't parameterized but this is
obviously trivial. Path delimiters are restricted to one character,
although you can specify multiple legal delimiters, the first being a
default when, for instance, setting the dirname of a plain filename,
or making a pathname absolute. I'm not pretending to be able to
support every possible filesystem (and certainly not VAX!) - my main
concerns are Win32 POSIX and MAC, the latter of which I know nothing

Some sample usage:

        pathname pname("./test.cpp");
        pathname s = pname.suffix(); // == ".cpp"
        s = pname.dirname(); // == "./"
        s = pname.basename(); // == "test"
        s = pname.filename(); // == "test.cpp"
        s = pname.extension(); // == "cpp"
        s = pname.rootname(); // == "./"
        bool b = pname.suffix_is(".cpp"); // true
        pname.suffix(".cxx"); // pname = "./test.cxx"
        pname.basename("file"); // pname = "./file.cxx"
        pname.dirname("c:\\temp"); // pname = "c:\\file.cxx"
        pname.rootname("d:\\"); // pname = "d:\file.cxx"
        pname.extension("cpp"); // pname = "d:\file.cpp"
        pname = "test"; // pname = "test"
        pname.extension("cpp"); // pname = "test.cpp"
        pname.dirname("."); // pname = ".\test.cpp"

Some rationales:

Why suffix() & extension()? Mainly because in the POSIX world
suffixes are generally considered to include the '.' and are
potentially multi-part (file.cpp.1), whereas Windows generally only
cares about what is after the last '.' (Explorer calls file.cpp.1
a '1' file). However they are both useful concepts regardless of
platform. Also suffix allows you to distinguish between 'file.'
and 'file', whereas extension doesn't.

Why suffix_is? Mainly so you can call
pathname("file.cpp.1").suffix_is(".cpp.1") and
pathname("file.cpp.1").suffix_is(".1") and

and get what you (probably) expect (true in all cases).
But this is certainly a close call, and removing it would be no great

Why doesn't basename work like POSIX basename()? POSIX basename
returns the whole filename portion unless you explicitly give it a
suffix to remove, so

basename("/home/dylan/file.txt", "") == "file.txt"
basename("/home/dylan/file.txt", ".txt") == "file"
I was originally going to have pathname::basename do the same thing
but I honestly couldn't think of a single case where I wanted this
functionality, at any rate it's easy to do:

pname.suffix() == ".txt" ? pname.basename() : pname.filename();
It's true however this won't let you strip off ".txt" if part of a
multi-part suffix:


Currently the only way to do this is to use extension(""), which will
strip off the last suffix and '.' I agree this may not be entirely

Why do dirname() etc return a pathname instead of a string?
Mainly to allow

pname.dirname().dirname().dirname() etc.
pname.suffix().suffix() etc.


pathname p("/home/dylan/file.txt");
p = p.basename().dirname("/tmp");

and get "/tmp/file"

Of course it would simple to do even if these functions returned
strings instead:

pathname p("/home/dylan/file.txt");
p = p.basename();

But perhaps the clincher is being able to do

p.suffix() == ".cpp"

and be sure that it will use the supplied comparison function, which
might be case insensitive.

I've basically designed the class around pathname manipulations that
I have needed to do, usually repeatedly, in my own work.
Unfortunately it's hard to judge whether others have similar needs
and whether this particular design makes it awkward to do common

One thing I have (experimentily!) also added is automatic conversion
to const char* AND const wchar_t* regardless of the templated char
type. This is because one would expect to be able to pass a pathname
into filesystem manipulation functions, which may only be available
in one particular flavour (usually ASCII only, but wchar_t* only if
an NT/2000 unicode app). I'm not convinced this is the way to do it,
but the conversions definitely need to happen automatically in a
library somewhere.

Any thoughts comments suggestions etc. etc. are most welcome.


Boost list run by bdawes at, gregod at, cpdaniel at, john at