[Filesystem] v3: preferred() vs. make_preferred()
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
On 14.09.2010 13:10, PB wrote:
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.
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 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!
Just make a local mutable copy of your const path & parameter and change that. :) I am also using v3, but I use string< basic_string<TCHAR> >(), which in my projects turns to wstring instead of string, and it works for me. Note that on Windows the path string type is wstring, unlike most POSIX systems which can use string with an UTF-8 encoding. And also, from what I know, Windows API functions work with either slashes '/' or backslashes '\'. It is Windows explorer and the command prompt cmd.exe that do not accept them ... Cheers Timothy Madden
participants (2)
-
PB -
Timothy Madden