Subject: Re: [boost] [filesystem] Decomposition of filenames beginning with period?
From: Joshua Juran (jjuran_at_[hidden])
Date: 2011-05-01 05:58:05
On Apr 18, 2011, at 1:34 PM, Vicente BOTET wrote:
>> Message du 18/04/11 18:38
>> De : "Phil Richards"
>> A : boost_at_[hidden]
>> Copie à :
>> Objet : Re: [boost] [filesystem] Decomposition of filenames
>> beginning with period?
>> On Mon, 2011-04-18 at 00:05 -0700, Joshua Juran wrote:
>>> On Apr 9, 2011, at 12:56 AM, Phil Richards wrote:
>>>> I think the library should code against "normal" coding practise
>>>> - and
>>>> for that reason, I'd argue that .gitignore has stem .gitignore,
>>>> and an
>>>> empty extension.
>>> I'd argue that .gitignore doesn't have an extension at all, empty or
>>> otherwise. Nor does "foo.", unless you can associate the empty
>>> extension with an application which handles such files when opened.
>> I was referring to the usage of "extension" as used in the
>> Boost.Filesystem library, where the extension() call returns the
>>> In other words, I'd say any filename beginning or ending with a dot,
>>> or lacking one entirely, doesn't have an extension.
>> IMO, this is wrong - under Unix, anyway. The two files "foo" and
>> are different files. It would be odd if they both had the same stem
>> *and* the same extension (as well as every other bit of the paths
Your scenario of filenames with matching extensions contradicts my
stipulation that each filename doesn't have an extension in the first
place. You're responding as if I'd said ".gitignore has an empty
extension", rather than ".gitignore doesn't have an extension at all,
empty or otherwise."
> for me neither foo neither foo. has an stem and an extension. We can
> not have an stem without extension and vice versa. The best solution
> in these cases is that the stem extension functions throw an
This position is a refinement of my own. I agree that
extension( "foo" ) should throw, but I could see stem( "foo" )
returning "foo". I don't have an opinion on whether it should or not.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk