Re: [boost] [Filesystem V3] Filesystem Version 3 beta 1 availablefor download and comment

Subject: Re: [boost] [Filesystem V3] Filesystem Version 3 beta 1 availablefor download and comment
From: Beman Dawes (bdawes_at_[hidden])
Date: 2010-02-21 11:00:41

On Thu, Feb 18, 2010 at 2:54 PM, Gregory Peele ARA/CFD <gpeele_at_[hidden]> wrote:
> Some comments below from a random C++ developer who has written multiple cross-platform filesystem libraries for US military use.  Take them for whatever you want.  Hopefully they're useful.  :-)
>
> Beman Dawes wrote:
>> On Thu, Feb 18, 2010 at 10:35 AM, Stewart, Robert
>> <Robert.Stewart_at_[hidden]> wrote:
>> >
>> > "stem" means nothing to me.  I followed the Reference link to the
>> > path class documentation and find no description of it there.
>>
>> Added a direct link to the reference doc description. Added an example
>> to the reference doc description.
>
> Regrettably the terminology for this is remarkably nonstandard, but I've never heard of "stem" before and would not have had any idea what it returned.  Typically I've seen this called "base_filename" or even just "filename". Where did "stem" come from?

See http://article.gmane.org/gmane.comp.lib.boost.devel/177103

> One wrinkle that I never was able to decide how to handle was multiple extensions, like ".tar.gz".  Some use cases would want ".tar.gz", some would just want ".gz", and a few would even want just ".tar".  Does this library provide any direct support for managing chains of extensions like that?

The design decision for stem() to return just the last extension
rather than the entire chain allows a user to visit each element in
the chain. For example,

path p = "foo.bar.baz.tar.bz2";
for (; !p.extension().empty(); p = p.stem())
    cout << p.extension() << '\n';

displays:

.bz2
.tar
.baz
.bar

and variations on that would allow fairly easy composition of any
operation on the chain that you might like to perform.  OTOH, if
stem() returned the entire chain, composition of other operations
wouldn't be possible.

An extension chain iterator could be provided, but that seems overkill to me.

Thanks,

--Beman