17.01.2013 19:08, Max Kellermann пишет:
I'm not sure. This missed chance for optimization is annoying, but
the advantages may outweigh that.
OK. Just let me know if you're willing to adopt this approach.
If not I'll think about other possible solutions for improving Unicode
support on Windows
On 2013/01/18 12:30, Denis Krjuchkov de...@crazydev.net wrote:
OK. Just let me know if you're willing to adopt this approach.
If not I'll think about other possible solutions for improving
Unicode support on Windows port.
I'm ok with it. Please review my patch, and if you think it's
correct,
On 2013/01/18 12:30, Denis Krjuchkov de...@crazydev.net wrote:
17.01.2013 19:08, Max Kellermann ??:
I'm not sure. This missed chance for optimization is annoying, but
the advantages may outweigh that.
OK. Just let me know if you're willing to adopt this approach.
If not I'll think
18.01.2013 20:51, Max Kellermann пишет:
I have improved and pushed my Path patch. I guess there's still a lot
of room for improvement. You are welcome to work towards using
wchar_t for Path::value_type on Windows.
Good.
Here is my plan:
1) Further push usage of Path class instead of raw
19.01.2013 0:36, Max Kellermann пишет:
Yes, why not. OTOH, we could pass Path to our readlink() wrapper,
and let the wrapper copy the result into the object. Or make it
return a Path. That would be most convenient to use. Adds some
overhead, but acceptable for me.
If you don't mind some
