WIP: Implement Filesystem TS

[Ed Smith-Rowland]

On 08/04/2014 01:11 PM, Jonathan Wakely wrote:
> On 04/08/14 14:50 +0100, Jonathan Wakely wrote:
>> This is a 99% complete implementation of the Filesystem TS as defined
>> by the N4099 draft,
>> http://open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4099.html
>
> The missing 1% relates to code conversions from wide character
> strings, which will be easier with the C++11 codecvt facets.
>
> And that 99% only refers to POSIX systems, there are large chunks
> missing for Windows, but as I don't have access to a Windows PC and
> don't know the API someone else will have to provide those missing
> pieces. I hope no major redesign will be needed to add Windows support
> though.
>
> I plan to document the design, but I'm not sure when that will happen,
> so for now:
>
> * filesystem::path is implemented as a basic_string containing the
>  native path, an enumeration describing the type of path represented
>  (either an individual component such as root-name, root-dir,
>  directory, filename, or a composite path of multiple components) and
>  a std::list containing the separate components of a composite path
>  (which is empty unless the path has multiple components). The list
>  exists so that dereferencing a filesystem::path::iterator can return
>  a reference to an object that is stored somewhere outside the
>  iterator, as required for forward iterators.
>
> * It might be possible to optimize path by lazily populating the
>  std::list, so that copying paths and passing them around by value
>  just copies the basic_string containing the native path, and it only
>  gets parsed to find the individual components as needed.
Interesting, I also parsed the path on creation - I felt weird about it 
and wanted to lazily parse later on.
OTOH, I guessed that mostly we'd want the whole sequence most often.
Actually, I parsed it on creation of path::iterator (I had forgotten the 
requirement of forward_iterators, so I had a vector of string_views 
inside the iterator.)
>
> * directory_iterator holds a shared_ptr<_Dir> where _Dir is a pimpl
>  class containing a DIR* returned by opendir(), a path object
>  containing the path the dir was opened with, and a directory_entry
>  object that gets returned by dereferencing the iterator. It also
>  contained a file_type enumeration, which gets used on GNU and BSD
>  platforms where the dirent struct contains the file type, which
>  means no stat() system call is needed to find out whether the
>  current entry is a directory and should be recursed into.
Why not unique_ptr?
>
> * recursive_directory_iterator holds a shared_ptr to a
>  stack<pair<_Dir, directory_iterator>> representing each directory
>  recursed into and the position within that directory. The
>  shared_ptr<_Dir>s belong to the directory_iterator objects in the
>  stack alias the shared_ptr held by the parent
>  recursive_directory_iterator, so the reference counts are shared by
>  the whole stack.
>

Tidbit: Explicit return bool in create_directories (ec version)? I'm not 
sure when true should be returned though.