From my application developer point of view, the preferred() observer is neater/better. I don't care and don't need to know what the underlying path format is. I have no desire to change it. All I am bothered about is that I can store it to a string (perhaps in an external file), and reconstruct the path from the same string. There are a few points in the application however where I need to present
Hello, I have built up a path in which the underlying string has a mixture of slashes and backslashes. I'm passing my_path.string().c_str() to a Windows API function which is getting confused because the string is being provided verbatim. I'm therefore looking to convert the string. According to the Filesystem tutorial (http://www.boost.org/doc/libs/1_44_0/libs/filesystem/v3/doc/tutorial.html), I can use the preferred() observer method to get the string that is suitable for the current (Windows) platform. This sounds like quite a nice design. However, it seems the preferred() method doesn't exist (i.e. the tutorial is wrong). There is a make_preferred() method which is non-const because it *changes the underlying representation* to the format preferred by the operating system. the path in a particular way, and it'd be nice to just throw a call to preferred() there. e.g. listBox_.AddString(my_path.preferred().c_str()); I've now got to do: bfs::path pref = my_path; pref.make_preferred(); listBox_.AddString(pref.string().c_str()); because the function that does the rendering of the string to the list box accepts the path as a const boost::filesystem::path& and therefore cannot change it. Wanted to point out the mismatch between the tutorial and the source code, and am wondering on the rationale behind make_preferred() over preferred()? Always possible I'm missing something! Thanks, Pete