On 01/03/2025 02:13 AM,
Muttley@DastardlyHQ.org wrote:
On Thu, 02 Jan 2025 13:58:34 -0800
Keith Thompson <Keith.S.Thompson+u@gmail.com> wibbled:
Muttley@DastardlyHQ.org writes:
On Thu, 2 Jan 2025 17:54:18 +0100
David Brown <david.brown@hesbynett.no> wibbled:
On 02/01/2025 15:07, Muttley@DastardlyHQ.org wrote:
Overloading << and >> was unnecessary and confusing.
>
Disagreed. I really don't think it was problematic. Nor did any of the
/many/ people who were involved in the design of C++. Remember, the
language and library has always been discussed, prototyped, and tested
by lots of people before being released. Stroustrup was the main
language designer, but he was far from alone.
>
Committees often don't come up with optimal solutions. Using the same
operator
for 2 entirely different operations unrelated in either concept or function
when there was no need to was illogical and perverse.
>
Like "*" for multiplication and pointer dereferencing? Like "&" for
bitwise "and" and address-of? Like "-" for negation and subtraction?
>
As you well know they derived from C and couldn't be changed. However I don't
believe using "&" for references was the best choice but at least it sort of
makes sense in context.
>
I would expect all mathematical operations to work in EXACTLY the same way
in an output stream.
>
I would expect << and >> to have their usual precedence whether
overloaded or not.
>
You're missing the point.
>
Eg I expect the output to be 256 here:
>
std::cout << 255 + 1 << std::endl;
>
Which it is.
>
No shit.
>
std::cout << 255 << 1 << std::endl;
>
Thats perverse.
>
Apparently your expectation was incorrect.
>
Don't be obtuse for the sake of arguing.
>
std::cout << n = 42 << "\n";
>
and it won't compile, but parentheses are an easy fix and a good idea
anyway.
>
How often has it really been a problem for you?
>
Given I do a lot of bit twiddling low level code, more than you might
expect. And its not a problem per se as it can be solved with brackets, I'm
simply saying it was a daft design decision to overload << and >> when Bjarne
could have easily created new operators at no cost. There was NO requirement
in this case to be compatible with C because streams were C++ specific
functionality.
>
>
(I think the @-sign is kind of like a constant for null,
graphically, sort of like '~' itself and empty string,
with regards to constants and operators. Yet, it's
usually innocuous in lots of things like filenames,
that though I think of @-sign intead of like ""NUL"
the character, for void or null, and empty-string as
the tilde sort of has there's empty set up in math symbols,
yet, tilde and @ are on the keyboard.)
Some kind of idea that friend ostream functions would
make for a slightly different idiom that happened to
use the same otherwise output formatters, is a sort of
idea to make a sort of "slightly-less-featureful"
streams, as with regards to the idea put here about
for example "it's always UTF-8" or "don't bother sorting
except by the codepoint", with regards to locales,
and NLS strings, (non-language-strings?), and with
regards to "2024 world locale" that's sort of en_US,
and usually in UTC and where the euro has been in
ISO-8859 since ISO-8859-15, or along these lines,
here there's a consideration that there's no changing
all the friend ostream functions or as it were, while
still having an idiom that takes the formatters as
with regards to only having value expressions in the
output line, those being terms on the statement.
Then, about lazy evaluation, with the idea of
"pass this function pointer down to the emitter
before bothering to evaluate it in case it's discarded",
is about appenders pretty much, though as with regards
to going ahead and flushing out to the character stream
sort of whether there's a character stream or builder,
to have the same sort of output lines, that accept
either a character stream, a builder, or, a builder-builder.
Then it's sort of like these same functions or sources
could be compiled multiple times, hopefully without
changing how they're written, resulting a repurposing.
It meminds me of testing JavaScript or something,
and it was like, "just point the include dir at
a different lib and run it against the source-compatible
emulator and diagnostic device".
We have a new standard!
Re: We have a new standard!
