I've adopted the strategy of 'gently-does-it' in adapting the graphics
code to use boost::filesystem::path. This has lead me to introduce
path versions of functions in src/support as and when I need them.
Obviously the aim is to eventually remove the std::string versions.
For example, the std::string and boost::filesystem::path versions of
unzippedFileName currently coexist:
string const unzippedFileName(string const & zipped_file);
fs::path const unzippedFileName(fs::path const & zipped_file)
{
return fs::path(unzippedFileName(zipped_file.native_file_string()),
fs::native);
}
These are exactly equivalent. The only function whose signature I
would like to change is lyx::support::tempName. The std::string
signature is:
std::string const
tempName(string const & dir = std::string(),
std::string const & prefix = std::string());
I would like the boost::filesystem::path signature to be:
boost::filesystem::path const
tempName(boost::filesystem::path const & dir,
std::string const & prefix = std::string(),
std::string const & suffix);
(I can't use a default value for 'dir' or else the compiler will be
unable to distinguish between the two.) I would also like to add a
suffix arg so that I can generate files like
<some dir>/foo<random stuff>.eps
However, the real change I would like is in the implementation. I
would like to 'unlink' the generated temporary file. It's a royal
PITA in my view and the function name offers no suggestion that it'll
generate a file; that's just an implementation detail in my view.
So, my fs::path version of tempName is:
fs::path const tempName(fs::path const & dir,
string const & prefix, string const & suffix)
{
string const temp = tempName(dir.native_file_string(), prefix);
// Remove the temp file, we only want the name...
unlink(temp);
// Append the suffix;
return fs::path(temp + suffix, fs::native);
}
Is anybody unhappy with this change?
--
Angus
