I am sure prior to C++98 was a problem back before 1998. How, it is still
not possible nowadays to read or write 3rd party string directly.

I made a video on criticising all the problems here:
https://youtu.be/CefgZlXeMUg?si=QOihSud-QAcB_rAj

Yes. My library can read QString from C's stdin directly or even read
winrt::hstring from QTextStream, or read QString from OpenSSL's BIO:

https://github.com/cppfastio/fast_io/blob/master/examples/0011.qt/qstring_concat.cc
https://github.com/cppfastio/fast_io/blob/master/examples/0011.qt/construct_qtextstream_from_syscall.cc


As this library is founded on the principles of concepts, it maintains a
consistent approach across all its routines. An illustration of this can be
found in the following example, which demonstrates the reading and writing
of QString.
https://github.com/cppfastio/fast_io/blob/master/examples/0025.winrt/hstring_get.cc
Observe that the API closely mirrors that of winrt::hstring.

Since they all use strlike concepts to implement.

https://github.com/cppfastio/fast_io/blob/master/include/fast_io_freestanding_impl/serializations/strlike_get.h


This reads from C's stdin, and I hacks every libc's FILE* to enable users
to read QString or winrt::hstring. They can read QString from fstream as
well.
On Sun, Sep 3, 2023 at 10:13 PM Thiago Macieira via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> On Sunday, 3 September 2023 18:29:16 PDT unlvsur unlvsur via Std-Proposals
> wrote:
> > Absolutely, QtCore! I contend that the root of this predicament can be
> > traced back to the calamity that is iostream. Why is there a need for Qt
> to
> > reinvent QFile? The core issue lies in the undeniable fact that iostream
> > has proven itself to be a resounding failure, forcing people to actively
> > seek out alternatives.
>
> That one is easy: because QFile predates the widespread deployment of
> iostreams. Remember that Qt actually predates the C++98 standard being
> ratified. Back when it was first coded and for much of its early years,
> the
> Standard Library (iostreams included) was too unstable.
>
> It wasn't until Qt 5.0 that I removed the "-no-stl" option. Until then, we
> could say Qt could build with an ostensibly freestanding C++ compiler.
>
> Why does Qt have QAtomicInteger? Because we needed atomics in 2005 and
> we're
> now slowly moving over. Why does Qt have QMutexLocker? Same reason, though
> today we internally only use a Standard Library lock. Why does Qt have
> QScopedPointer? Ditto again, but we have also ruled that it is a *scope*
> lock
> and shall not gain movable properties; just use std::unique_ptr if you
> need
> those features.
>
> > Here's the crux of the matter: It appears nigh impossible to introduce
> any
> > new functionality without being ensnared by iostream's inherent
> > shortcomings. Take, for instance, the endeavor to incorporate a "linear
> > algebra" library. It inevitably leads to the tangled web of operator
> > overloading for iostreams, a necessity just to output your matrix.
> > Additionally, I require this linear algebra to be freestanding;
> otherwise,
> > it becomes utterly unusable. Clearly, iostream renders the situation
> > untenable for freestanding applications.
>
> I could say similarly of <random>'s ability of saving and restoring state:
> it's tied to iostreams. I just want to get the bits out of the generator,
> not
> encode them to text!
>
> But referring to Qt again: why do we insist on QByteArray and QList
> instead of
> std::string and std::vector? Because that's what users are familiar with
> and
> expect. (I also happen to think Qt has a superior API naming convention)
>
> > My proposal stands: We should embrace an entirely new IO library, one
> poised
> > to supersede the current IO facilities. It's high time we consigned
> > std::locale, iostream, ctype.h, format, charconv, filesystem, and their
> ilk
> > to obsolescence. Failure to do so will merely perpetuate the
> complications
> > that accompany each new feature addition.
>
> Not so sure about filesystem, since it's new and mostly separate from
> iostreams.
>
> On the rest, I agree. Where's the proposal for this new library? Have we
> got
> implementations for it? How well has it fared on cross-platform support,
> namely that of naming files on Windows versus Linux? Has it got
> trial-by-fire of
> actually producing internationalised applications?
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Software Architect - Intel DCAI Cloud Engineering
>
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>