Re: [boost] [1.44] [filesystem] operator +

Subject: Re: [boost] [1.44] [filesystem] operator +
From: Lars Viklund (zao_at_[hidden])
Date: 2010-08-25 08:35:22

On Wed, Aug 25, 2010 at 11:22:51AM +0200, Jochen Wilhelmy wrote:
> > Note that Boost.Filesystem contains functions to retrieve and modify
> >file extensions.
> >
> >In my opinion, introducing such a free + operator would be quite bad, as
> >it would encourage use of it to glue on path segments in ways that may
> >violate the format of paths for a platform, as in your example of an
> >unconditional +"/bar", which would be horribly wrong for any platform
> >that didn't use / as separator.
>
> I know that I can exchange the current extension, but how can I add one
> to a path that soes not have one? The current filename may already contain
> dots therefore the addition of an extension should not check if there is  
> already one.
> (e.g. "foo/bar.xy" + ".zw" -> "foo/bar.xy.zw")
>
> I don't see any technical problem with + "/bar" since "/bar" is the  
> platform independent
> notation and should therefore work on any platform. so far it is also  
> allowed
> to do fs::path("foo/bar") where '/' is also the platform independent  
> separator.
> therefore it should be equivalent to fs::path("foo") + "/bar".
> but it would be ok to prevent this e.g. by throwing an exception.
> something like path.add_extension(".bar") should be ok too.

Any particular reason you made a new thread?

On Windows, a \ is the proper path separator. Any functions
accepting / are doing it out of tolerance. Saying that / is standard
everywhere is completely bogus, especially on platforms like classic
MacOS, VMS, etc.

Anyway, if you want to operate on individual path components as strings,
you can extract them with leaf() and friends. Opening up such a massive
hole in path integrity just because you can't be bothered to use the
fine member functions available sounds a bit silly.

In any way, there's no-one stopping you from creating free functions to
do whatever perverted things you want to paths, but I sure oppose adding
such things to the library.

-- 
Lars Viklund | zao_at_[hidden]