Date: Mon, 04 Sep 2023 08:32:10 -0700
On Monday, 4 September 2023 06:47:02 PDT coshvji cujmlqef via Std-Proposals
wrote:
> Why is iostream omitted instead of simply making it freestanding? Well, it
> relies on locale, and this reliance tends to increase its size
> significantly. To be frank, it can be considered a design failure.
Or not.
For those of us who write internationalised applications, having support for
locale-based formatting of content is a must.
I may agree that the implementation of that in iostreams is flawed, but not the
principle of it. I may agree that iostreams is overengineered too to the point
that some of its design requirements are a flaw (diamond inheritance, to name
one thing), but that's not caused by locales. And moreover, removing locales
doesn't make immediately make iostreams able to wok on freestanding
environments.
> From my perspective, I fail to see any valid reason why IO cannot be
> freestanding if it's designed correctly. In fact, I find it to be a less
> challenging task compared to making dynamic memory freestanding.
I actually agree: there's no reason it couldn't be freestanding.
Where's the paper analysing this, though? Where's the paper discussing what
would need to be excised or redesigned so that a freestanding implementation
would work? Maybe this paper shows that iostreams is irredeemably convoluted
and can't be made with simple omissions, and that we need a different design,
whose goals this paper proposes. Where is it?
> Incidentally, why do you consider it acceptable to have three APIs
> essentially performing the same task?
I don't think it's good, but good and necessary are different things. The fact
is we have different needs and different legacies. The example of filesystem
having exception-throwing and exception-free APIs is because both camps have
their valid reasons and unfortunately there was no common ground, not at that
level at least. It was better to have both functionalities so both camps could
use the API rather than it being entirely dismissed by one or the other (if
not both!).
> Why can't we aim for an
> API that's not only fast and versatile but also directly applicable for
> both I/O and string operations?
I seem to have missed a paper that analysed those failures and proposed a
different approach. Care to provide a link?
> "That's not a proposal. In fact, nothing you ever suggest is a proposal,
> just ranting. You have very little credibility on any C++ topic as far as
> I'm concerned."
>
> I have earned the trust and credibility of many individuals. However, you
> seem to disregard this fact and choose to criticize me in this context.
Maybe you have, but it's hard to say in this thread. No one has so far
supported you. Any credibility you may have had, you squandered by attacking
others.
Anyway, it's simple to ascertain and confirm that credibility. First, stop
insulting people. Completely. Second, provide links to your papers or
implementations or research that support your assertions.
wrote:
> Why is iostream omitted instead of simply making it freestanding? Well, it
> relies on locale, and this reliance tends to increase its size
> significantly. To be frank, it can be considered a design failure.
Or not.
For those of us who write internationalised applications, having support for
locale-based formatting of content is a must.
I may agree that the implementation of that in iostreams is flawed, but not the
principle of it. I may agree that iostreams is overengineered too to the point
that some of its design requirements are a flaw (diamond inheritance, to name
one thing), but that's not caused by locales. And moreover, removing locales
doesn't make immediately make iostreams able to wok on freestanding
environments.
> From my perspective, I fail to see any valid reason why IO cannot be
> freestanding if it's designed correctly. In fact, I find it to be a less
> challenging task compared to making dynamic memory freestanding.
I actually agree: there's no reason it couldn't be freestanding.
Where's the paper analysing this, though? Where's the paper discussing what
would need to be excised or redesigned so that a freestanding implementation
would work? Maybe this paper shows that iostreams is irredeemably convoluted
and can't be made with simple omissions, and that we need a different design,
whose goals this paper proposes. Where is it?
> Incidentally, why do you consider it acceptable to have three APIs
> essentially performing the same task?
I don't think it's good, but good and necessary are different things. The fact
is we have different needs and different legacies. The example of filesystem
having exception-throwing and exception-free APIs is because both camps have
their valid reasons and unfortunately there was no common ground, not at that
level at least. It was better to have both functionalities so both camps could
use the API rather than it being entirely dismissed by one or the other (if
not both!).
> Why can't we aim for an
> API that's not only fast and versatile but also directly applicable for
> both I/O and string operations?
I seem to have missed a paper that analysed those failures and proposed a
different approach. Care to provide a link?
> "That's not a proposal. In fact, nothing you ever suggest is a proposal,
> just ranting. You have very little credibility on any C++ topic as far as
> I'm concerned."
>
> I have earned the trust and credibility of many individuals. However, you
> seem to disregard this fact and choose to criticize me in this context.
Maybe you have, but it's hard to say in this thread. No one has so far
supported you. Any credibility you may have had, you squandered by attacking
others.
Anyway, it's simple to ascertain and confirm that credibility. First, stop
insulting people. Completely. Second, provide links to your papers or
implementations or research that support your assertions.
-- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel DCAI Cloud Engineering
Received on 2023-09-04 15:32:12