Boost logo

Boost :

From: David Abrahams (dave_at_[hidden])
Date: 2008-05-25 01:50:25

on Wed May 21 2008, Beman Dawes <> wrote:

> David Abrahams wrote:
>> on Tue May 20 2008, Beman Dawes <> wrote:
>>> David Abrahams wrote:
>>>> I was just reviewing the filesystem docs and came across "leaf()". I'm
>>>> sure this isn't the first time I've seen it, but this time I picked up a
>>>> little semantic dissonance. Normally we think of "leaf" in the context
>>>> of a tree as being a thing with no children. An interior node like a
>>>> directory that has files or other directories in it is usually not
>>>> called a "leaf."
>>> Right. And "leaf" never returns an interior node of a path.
>> What is an "interior node" of a path? Would you talk about "interior
>> nodes" of a std::vector<string>?
>>>> I wonder if this is the best possible name?
>>> The names used by the filesystem library were carefully chosen as a
>>> matched set. So you can't change a single name without making a
>>> corresponding change to the other names (like "branch") it is related
>>> to.
>> I understand that a change may upset the apple cart, but the fact that
>> the names are interdependent doesn't mean we shouldn't consider
>> different ones.
> Sure. But given that the current names were widely discussed at the time
> of adoption, have been in use for quite a few years, and "basename" is
> already used by the library for a function with different semantics,
> change would be difficult.

Well, I did bring this up almost five years ago:

>>>> Is there a precedent we can draw on in some other language/library? In
>>>> python, it's os.path.basename(p). Perl, php, and the posix basename
>>>> command seem to do something similar.
>>> The filesytem names were chosen to be an improvement over the naming
>>> used by other libraries and/or languages, which always seemed to me to
>>> be misleading. For example, my intuition is that basename("")
>>> should yield "foo", not "".
>> I don't know why -- basename seems like one of those names that would be
>> semantically void except for the precedent provided by other languages
>> trying to do the same thing. On the face of it, it doesn't suggest
>> anything about the extension part of the name one way or the other. In
>> any case, the 2-argument version of basename does something like what
>> you want in many of those other languages.
>> I'm certainly open to persuasion, but so far, a pathname doesn't seem to
>> resemble a tree in any conceptually useful way, and there seems to be no
>> compelling advantage to inventing our own terminology here.
> If you have a better set of names, why don't you suggest them?

You asked for it. I'm going in the order given by because that's
reasonably comprehensive and readable even though it looks like it may
have some serious errors. Don't have time to pore through the full
reference right now.

  path members:

    const std::string& string( ): OK
    std::string root_directory( ): OK, but maybe should return
        boost::optional<path>. I wonder why we decay to std::string
        so eagerly.

    std::string root_name( ): OK, but maybe should be called "root" and
        return boost::optional<path>

    std::string leaf( ): should be basename(). back(), tail() and
                          p.split()[1].string() are viable alternatives

    std::string branch_path( ): should be dirname()

    bool empty( ): OK, although this seems like a really uninteresting
        question to ask.

    iterator: OK

    operator/: I've liked that one ever since I came up with it ;-)

The rest of the names look OK to me except for is_regular, which should
be is_file. That name seems overthought and "regular" has all kinds of
other connotations.

Dave Abrahams
BoostPro Computing

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