Date: Sun, 03 Sep 2023 19:13:46 -0700
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?
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
Received on 2023-09-04 02:13:48