|
Boost : |
From: Yakov Galka (ybungalobill_at_[hidden])
Date: 2019-12-03 16:25:44
On Mon, Nov 11, 2019 at 4:19 AM Alexander Grund via Boost <
boost_at_[hidden]> 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/
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk