Opened 10 years ago

Last modified 10 years ago

#8342 new Bugs

[filesystem] v3 path interface is no longer an abstraction

Reported by: alexander.lamaison@… Owned by: Beman Dawes
Milestone: To Be Determined Component: filesystem
Version: Boost 1.49.0 Severity: Problem
Keywords: Cc:

Description

Some of the changes to Boost.Filesystem in v3 have made it into a string class with utility methods rather than the path abstraction that it used to be.

Consider:

path p("/a/b"); p /= "c"; cout << p.string();

In version 2 this would output "/a/b/c" on Windows but now it produces "/a/b\c".

Had the behaviour simple changed from using generic path to always using OS path, this would not be a problem; the change would be consistent and the chosen string() method would be the only deciding factor deciding in what format the path was returned.

But the behaviour has, instead, changed to return a chimera of generic and OS paths which means the output of the string function is now dependent on the format of the input string and the modifications that were made during its lifetime. The abstraction has been lost.

My suggestions:

  • change boost::filesystem::path to have only two string functions: one that returns entirely generic paths, the other entirely OS paths
  • make string() be the generic one
  • let no part of the path interface betray the exact separators that happen to have been used to construct the string as that is a leaky abstraction.

See original discussion here: http://thread.gmane.org/gmane.comp.lib.boost.devel/239446

Change History (1)

comment:1 by alexander.lamaison@…, 10 years ago

And this time with formatting:

path p("/a/b");
p /= "c";
cout << p.string(); 
Note: See TracTickets for help on using tickets.