Re: [boost] [filesystem] temp_dir_path()

Subject: Re: [boost] [filesystem] temp_dir_path()
From: Jeff Flinn (TriumphSprint2000_at_[hidden])
Date: 2010-10-13 14:03:02

John B. Turpish wrote:
> On Tue, Oct 12, 2010 at 8:49 PM, Stewart, Robert <Robert.Stewart_at_[hidden]> wrote:
>> John B. Turpish wrote:
>>> 'directory.in.output' provided me with nothing. So I do not
>>> know where it got the directory for tmpnam(), but not from any
>>> env var.
>> According to <http://linux.die.net/man/3/tmpnam>, one should not
>> use tmpname(3) but should instead call mkstemp(3) or tmpfile(3).
>> The former makes a unique filename from a supplied template, so
>> it is the caller's responsibility to select the directory.  The
>> latter creates a file which is deleted automatically when closed
>> or when the process terminates.  Neither mentions e-vars as
>> influencing their behavior.
> 
> What I was getting at is there's already a function in the standard C
> library that needs to determine where to put temporary files - and in
> my mind that would be what the temporary directory is - and its result
> disagrees with what's being discussed here. mkstemp() doesn't have to
> come up with directory itself - as you pointed out. tmpfile() would,
> but printing the result of the decision not as convenient for a simple
> test as with tmpnam(). Besides, if the use case (not positive what it
> is, actually) was covered by tmpfile() then there would be no need for
> the function being discussed.

My primary use cases are in interacting with legacy 3rd party apps that 
read/write from/to the users temp directory with advertised file names, 
and an historical place to direct users if they want to see intermediate 
level logged data.

Qt was previously used for this, but it interferes with legacy code when 
run on a mac under rosetta, causes false memory leaks from boost unit 
tests due, I think, to caching in static data members the path's after 
the first call, and appears to bring in a lot of extraneous code that 
doubles my executable sizes.

Jeff