C++ Logo

std-proposals

Advanced search

Re: [std-proposals] PR: std::allocator<T>::allocate is not freestanding

From: coshvji cujmlqef <oyzawqgcfc_at_[hidden]>
Date: Mon, 4 Sep 2023 10:13:25 -0400
It's not a matter of speaking in void; it's about consistently adhering to
dialectical materialism and historical materialism. Truth, as an objective
reality, remains unchanged regardless of whether one acknowledges it or not.
I know people like you refuse to admit human society can be scientifically
researched which is exactly why you are wrong.

On Mon, Sep 4, 2023 at 5:35 AM Jonathan Wakely via Std-Proposals <
std-proposals_at_[hidden]> wrote:

>
>
> On Mon, 4 Sept 2023, 02:31 unlvsur unlvsur via Std-Proposals, <
> std-proposals_at_[hidden]> 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.
>>
>>
>>
>> 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.
>>
>
> You do like to talk in absolutes, even when you're out of your depth and
> wrong.
>
> Where in P1673 or P1385 (or P1166 or P1891) does it say the proposal
> depends on iostreams? Where are the operator overloads for outputting a
> matrix described? Can you explain why that iostreams functionality couldn't
> be omitted for freestanding implementations, leaving the rest supported,
> just like we did for the iostream-dependent parts of <iterator> and
> <ranges>? Are you just spouting rubbish without understanding the topic
> properly, as I've seen several times in the past whenever you wade in
> somewhere and start attacking people?
>
> There is an issue with <random> requiring iostreams, but the same
> "partially freestanding" principle applies there, it could all be optional.
> Somebody just needs to propose it and do the work to get it approved for
> the standard. That doesn't happen by being a blight on the C++ community
> and attacking the people who are actually trying to do that.
>
>
>
>
>>
>> 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.
>>
>
> 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.
>
>
>
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>

Received on 2023-09-04 14:16:05