On Mon, 4 Sept 2023 at 14:49, coshvji cujmlqef <oyzawqgcfc_at_[hidden]> 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.
>
> 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.
>

So since you've pivoted to "why isn't I/O freestanding anyway?" I assume
that's your twisted way of admitting you're completely wrong about linear
algebra being held back by iostreams?

Nice attempt at deflection, but you're still wrong.


>
> Incidentally, why do you consider it acceptable to have three APIs
> essentially performing the same task?
>

Ah, more deflection that has nothing to do with the topic of allocator
being freestanding. You're just ranting again.


> Let's take the networking proposal as an example. Both the ipv4 and ipv6
> classes feature three functionalities that serve identical purposes: the
> to_string method, iostream overloads, and a formatter. First and foremost,
> it's worth noting that none of these options are particularly efficient,
> primarily due to the creation of std::string. Secondly, why is the issue of
> API duplication being overlooked? It's reminiscent of the situation with
> std::filesystem, where we have both error code and exceptions serving as
> dual APIs. However, in this case, it appears to be even more problematic.
> 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? It's worth
> mentioning that this approach doesn't lend itself well to the
> implementation of third-party libraries, such as QString or other
> languages' string types like PyObject, which are not freestanding either.
>
> "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.
>


So why do you keep being banned/muted in various communities? Funny how
that doesn't happen to other credible people.



> However, you seem to disregard this fact and choose to criticize me in
> this context. I align with the scientific perspective by consistently
> adhering to the historical materialist viewpoint, which is rooted in the
> principles of scientific understanding.
>


That doesn't excuse you acting like an entitled brat and abusing people for
not doing what you want.

I'm sick of you attacking and abusing members of WG21 for not following all
your suggestions. Stop acting like a child.

For anybody who thinks I'm overreacting, I've been putting up with this
clown for years, including things like "DEATH TO WG21":
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100057#c36





>
> 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
>>
>