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. -Jochen
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
Lars Viklund wrote:
On Wed, Aug 25, 2010 at 11:22:51AM +0200, Jochen Wilhelmy wrote:
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.
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.
He was referring to the "portable pathname format" supported by Boost.Filesystem.
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.
Your vehemence is misplaced. The OP's asking for an operator that understands the portable pathname format just as the constructor does, with the succinctness that operator syntax can provide. The suggestion is that this code: fs::path("foo/bar") and the following produce the same result: fs::path("foo") + "/bar"; That would, IOW, be equivalent to having done something like the following without first having to build a string: std::string s("foo"); s += "/bar"; fs::path(s); Presumably, this would also be desirable: fs::path p("foo"); p += "/bar"; If those operators only support the portable pathname format, they seem at least interesting, and certainly not a "massive hold in path integrity." _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
participants (3)
-
Jochen Wilhelmy -
Lars Viklund -
Stewart, Robert