Subject: Re: [boost] [filesystem] temp_dir_path()
From: PB (newbarker_at_[hidden])
Date: 2010-10-09 13:21:47
On Sat, Oct 9, 2010 at 5:36 PM, Jeff Flinn
> The need for portably obtaining 'the' temporary-directory-path has been
> brought up a few times(but never addressed AFAICT), and I am now in the need
> for this as well.
> Windows has the GetTempPath, which follows a specific order of looking for a
> temporary directory path. If GetTempPath returns 0, GetLastError provides a
> system error.
> Posix relies on getEnv("TMPDIR"), which returns 0 if the environment
> variable does not exist.
> The following windows and posix implementation would be in the detail
> path temp_dir_path(system::error_code* ec)
> # ifdef BOOST_POSIX_API
> const char* val = getenv("TMPDIR");
> return val? path(val) : path();
> # else // Windows
> std::vector<Path::value_type> buf(GetTempPathW(0, NULL));
> if(GetTempPathW(buf.size(), &buf))
> return path(buf.begin(), buf.end());
> int errval(::GetLastError());
> if (ec)
> ec->assign(errval, system_category());
> return path()
> # endif
> - should Posix return an empty path or an error when empty?
> - should Windows provide a more 'temp-path' centric error?
> - should both verify the path exists?
> - if the path does not exist should one be created?
A temporary directory getter withing Boost.Filesystem would be a "nice
to have". In my application, I created a function called
GetValidatedTempDir() which does the get and validate, so my
suggestions/comments would be as follows:
- both flavours should verify the path exists.
- a more 'temp-path' centric error might be good. I must confess to
not knowing a great feal about the error codes. I usually have an
outer catch for const std::exception& and expect that calling what()
on that would give me something meaningful. If the temporary directory
getter threw an exception if validation fails, and if calling what()
on that gave me some idea about a problem with the temp path, then I'd
- I don't think the path should be created.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk