https://svn.boost.org/trac10/ticket/8342 <p> 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. </p> <p> Consider: </p> <p> path p("/a/b"); p /= "c"; cout &lt;&lt; p.string(); </p> <p> In version 2 this would output "/a/b/c" on Windows but now it produces "/a/b\c". </p> <p> 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. </p> <p> 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. </p> <p> My suggestions: </p> <ul><li>change boost::filesystem::path to have only two string functions: one that returns entirely generic paths, the other entirely OS paths </li><li>make string() be the generic one </li><li>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. </li></ul><p> See original discussion here: <a class="ext-link" href="http://thread.gmane.org/gmane.comp.lib.boost.devel/239446"><span class="icon">​</span>http://thread.gmane.org/gmane.comp.lib.boost.devel/239446</a> </p> en-us /htdocs/site/boost.png https://svn.boost.org/trac10/ticket/8342 Trac 1.4.3 alexander.lamaison@… Wed, 27 Mar 2013 10:52:55 GMT