Re: [External Email] Re: PR: std::allocator<T>::allocate is not freestanding

[Jason McKesson]

On Sun, Sep 3, 2023 at 9:49 PM unlvsur unlvsur <swan...@binghamton.edu> wrote:
>
> LLVM has the capability to generate WebAssembly (wasm) binaries, and there exists a project known as wasm2lua that can compile wasm code into Lua. Consequently, this allows for the compilation of C++ into Lua code. https://github.com/SwadicalRag/wasm2lua
>
>
>
> The process involves compiling C++ code into Lua using wasm2lua. You can find a detailed demonstration of this process in the following video: https://www.youtube.com/watch?v=_1Dob0kb8pw
>
>
>
> This approach proves immensely valuable, especially for game addons, including those for games like World of Warcraft, which are often written in Lua. However, there is a need to employ C++ for implementing features like cryptography or dragonbox to achieve superior performance compared to Lua alone, much like how people compile C++ into JavaScript.
>
>
>
> Now, let's delve into the shortcomings of charconv:
>
>
>
> charconv doesn't handle non-characters such as wchar_t, char8_t, char16_t, and char32_t, nor does it deal with the EBCDIC execution charset.
>
>
>
> It lacks constexpr and noexcept support.
>
>
>
> Its interface is excessively redundant, particularly in terms of bounds checking.
>
>
>
> std::to_chars_result
>
> to_chars( char* first, char* last,
>
> /* integer-type */ value, int base = 10 );
>
>
>
> For example, the std::to_chars_result interface could be simplified as follows:
>
>
>
> char* to_chars(char* first, /* integer-type */ value, int base = 10);
>
> This simplification stems from the fact that the maximum output size is known at compile time, and the API should ideally not return errors in any circumstances. This complexity poses challenges when implementing efficient formatting.
>
>
>
> charconv lacks a state machine model to handle non-contiguous data, which is crucial when dealing with input from an IO buffer where data is received in chunks.
>
>
>
> It doesn't integrate well with C++ containers and std::string, making it challenging to efficiently format std::string within the confines of standard C++. This can also introduce potential vulnerabilities.
>
>
>
> Moving on to std::format:
>
>
>
> The author frequently adds defect reports (DRs) to extend std::format, indicating its inherent issues, and this can lead to ABI breaks.
>
>
>
> There's no foolproof way to prevent format string vulnerabilities, even with compile-time enforcement, as developers can still introduce them through code generators and other means.
>
>
>
> std::format doesn't interact well with macros.
>
>
>
> Its implementation is complex, potentially introducing security vulnerabilities and causing significant performance overhead. In some cases, std::format has been shown to perform even slower than C++ streams on libraries like libstdc++.
>
>
>
> In essence, both charconv and std::format are essentially variations of the iostream concept, attempting to address the wrong set of problems.
>
>
>
> In summary, these components represent historical mistakes in C++ design and implementation.

If you think of these tools as "essentially variations of the iostream
concept," then that might be a reasonable conclusion. But if you
assess them for what they are rather than for what they are not, then
you can arrive at very different conclusions.

Neither of these tools is meant to do everything. They're not trying
to replace iostreams. They're not intended to solve every single
problem with regard to string formatting. So it seems wrongheaded to
talk about their deficiencies in problem domains that they're not
trying to play in.

Charconv in particular is for *elemental* string conversions. You have
a number and you want to turn it into a contiguous sequence of
characters. Or you have a contiguous sequence of characters and you
want to turn it into a number. And you want to do this as fast as
possible (and without opening yourself to buffer overruns; that's why
it uses a range-based interface), as well as providing some round-trip
guarantees even with floating-point conversions.

This is not a tool that's meant to play in the domain of Unicode. It's
not meant to deal with locales. It's not meant to deal with
non-contiguous strings. Etc.

If you always judge a feature based on what you want it to be instead
of looking at what it is *trying* to be, you'll find innumerable
deficiencies. The real question is this: is it useful? Is it a tool
that people can use to solve legitimate problems they have in an
efficient and effective way?

If you have a better idea, feel free to share it. But simply saying
"we should make better iostreams!" doesn't actually make "better
iostreams".