enum os_path_t
{ path_temp, path_home, path_windows_my_documents, // Or is this too ugly? };
namespace filesystem { path get_os_path(os_path_t) }
os_path might not the best name, but you get the idea..
I was thinking of something similar: indicate which directory is wanted by a discriminator. As for names, I'd definitely avoid "windows." In your example, "path_windows_my_documents" could be "path_documents" and still serve just as well.
Sure, but the documentation must state clearly on which platforms it can be expected to have a default implementation.
Given that there is no specific My Documents equivalent on POSIX systems and no specific home directory on Windows, perhaps the better approach is to have calls for those throw an exception unless the application first defines their location. That is, Filesystem could offer a standard API for accessing such paths but require the actual path be specified -- once per run -- when there's no OS default. The advantage is that most code can use the common API and only initialization code must set the ambiguous paths according to some local policy and the current platform.
Therefore:
namespace filesystem { path set_os_path(os_path_t, path const &);
path set_os_path_from_environment(os_path_t, std::string const &); }
This I like, but do you need set_os_path_from_environment? set_os_path(X, boost::getenv("Y")) would suffice IMO, surely boost must somewhere have a string getenv(string) (?)
What's missing is the ability to set a policy that indicates Filesystem should try some particular e-var and, if that's not set, check for a particular directory, and if that doesn't exist, throw an exception. That would be the most useful. Perhaps the right behavior is to simply install a function that Filesystem can call to provide the path when needed.
with set_os_path I think users can do that themselves. Installing a callback function seems a little over-engineered, what would be the benefits?
It may be handy to provide a feature query function, too:
namespace filesystem { bool is_os_path_available(os_path_t); }
If get_os_path() calls a user-installed function, then is_os_path_available() would have to call the former in a try block, of course.
I thought you were aiming at having filesystem configured at initialization with set_os_path. get_os_path() should IMO throw if there's no platform specific implementation for the discriminator and the user has not explicitly set the path. Do you have a particular implementation of such a user-defined function that would benefit from lazy evaluation? I have a feeling I'm missing your point. Christian