On windows, the path internal representation is wchar_t, and
input/output often goes through utf8 inbetween, which causes extra
allocations.
MS STL does the same, so this shouldn't be a standards compliance
issue.
This is a more targeted and precise solution, as an alternative to
D97497.
Aren't there cases where it won't allocate? Even if CharT is path::value_type? Looking at the code the answer is negative, but I'd like your confirmation.
On a different note.
I've been looking at operator/= to which append delegates, and we seem to miss an optimization when calling substr.
At https://github.com/llvm/llvm-project/blob/main/libcxx/include/filesystem#L1029 and https://github.com/llvm/llvm-project/blob/main/libcxx/include/filesystem#L1034, __p.__pn_ is a string (string_type), so .substr() returns a string.
This string gets appended to __pn_ and immediately discarded.
I think we should do string_view_type{__p.__pn_}.substr() and so avoid this temporary string. WDYT?