On 08/07/2019 11:37, Lyberta wrote:
> Niall Douglas:
>> That's in path_view::c_str, not in path_view. Path views are trivial types.
>
> Can't we not expose c_str and use native_handle to open files similar to
> std::thread? c_str is ugly and only used in platform-specific code as
> far as I understand.

path_view::c_str produces a ready-to-use-for-this-platform filesystem
path. It is instanced just before the syscall, and destroyed immediately
afterwards. This is why I think I can get away with making it many Kb
large, because the optimiser will elide the stack consumption if the
in-class storage is not used.

It is exposed publicly for the exact same reason as why std::string or
std::filesystem::path expose .c_str() i.e. all C++ programmers have need
of calling platform-specific code.

In terms of using native handle to open files, that is literally what
P1031 LLFIO's path_handle does. It race free tracks an inode on the
filesystem, impervious to its path changes.

Niall