On Mon, Nov 11, 2019 at 4:19 AM Alexander Grund via Boost < boost@lists.boost.org> wrote:
I just noticed that it is very unfortunate, that this didn't happen 3 years (or so) ago. Now not only `boost::filesystem::path` is using `wchar` but also the C++17 `std::filesystem::path` does so. So we now have costly conversions and wasting half the space on windows for no gain :/
I raised this issue many years ago. In fact boost filesystem v2 was better in this respect, because it followed the established convention of having a templated basic_path<char>, thus not committing to a specific char type. Alas, v2 was deprecated and v3 was lobbied into WG21 for standardization. It was an unprecedented case of introducing a "char on some platforms, wchar_t on others" interface into the standard, which is a bad decision from portability stand point. While we are at it, I would like to say that boost filesystem should have never introduced a path class in the first place. filesystem::path is just a glorified string with no extra invariants. Any string -> path conversion copies the data, even if it's already in the right encoding, even on operating systems that don't need any conversions at all. There goes your "don't pay for what you don't use" principle. Most can agree that C++'s spirit is to separate containers from algorithms. A proper design would introduce path manipulation functions that work on any string types, and let users use std::string or even char[] for storage. -- Yakov Galka http://stannum.co.il/