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@acc.umu.se