Re: [boost] [filesystem] home_directory_path

Subject: Re: [boost] [filesystem] home_directory_path
From: Bjørn Roald (bjorn_at_[hidden])
Date: 2010-10-22 17:28:57

On 10/22/2010 01:11 PM, Stewart, Robert wrote:
> Bjørn Roald wrote:
>    
>> I try to rephrase my intended message:
>>
>> Finding a perfect solution is impossible, so we should just
>> give up.  Or --- maybe, if we can find something that is very
>> valuable and useful for boost::filesystem users, then we can
>> accept a few scratches in the paint.
>>      
> Ah, I understand you now, but I consider that a false dichotomy, presuming you mean abandon home_directory_path() in frustration by "give up."  There are two additional choices, at least.

Yes there are possibly many choices.

> One is to determine a thing as too little generalizable as to be the purview of Filesystem, which isn't the same as giving up.

valid choice, yes.  But is sounds a lot like giving up even if I have no 
need nor do I see a purpose of making an argument about it.

> Another is to decide that there is no good default behavior on which people can agree, so the right behavior is to require that the value be supplied by the user so that Filesystem is merely the vehicle for vending that value.
>    

valid choice, yes.  But it is in the subset of choices that are 
potentially very useful but less than perfect -- it has some scratches 
in the paint.

> As to the latter approach, note that Filesystem could even offer several functions a user can call to establish the values it vends.  For example, there might be a function for POSIX systems that discovers the user's home directory, validates it, and then sets it as the Filesystem home directory, configuration directory, etc., according to your notions.  There could be another that establishes some other common convention used on certain Linux distributions, for example.  There could be a function that establishes WinXP conventions, another for Win7, and yet another for WinCE conventions.  Thus, the user can take advantage of prepackaged code, if appropriate and available, or write custom code to set the Filesystem values according to some local convention.
>
> Given that approach to establishing the values vended by Filesystem, all other user code can simply query Filesystem for the values when needed, being thus ignorant of what convention was set during initialization, while Filesystem avoids encouraging any given convention over another.
>    

I am not sure I follow all this.  How does this provide the ability to 
write simple, straight forward, and portable C++ in the spirit of 
boost?  When I refer to giving up, I refer to those goals.

-- 
Bjørn