Path: csiph.com!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c++ Subject: Re: We have a new standard! Date: Fri, 03 Jan 2025 11:22:09 -0800 Organization: None to speak of Lines: 79 Message-ID: <87h66fsnxa.fsf@nosuchdomain.example.com> References: <20250101182527.00004b2f@yahoo.com> <87pll4sws5.fsf@nosuchdomain.example.com> MIME-Version: 1.0 Content-Type: text/plain Injection-Date: Fri, 03 Jan 2025 20:22:10 +0100 (CET) Injection-Info: dont-email.me; posting-host="effc54326606164512e5c838bb1e0c9c"; logging-data="47228"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1847LALUmgbGH74LUNwK9/Q" User-Agent: Gnus/5.13 (Gnus v5.13) Cancel-Lock: sha1:+HjaUlZ6tSezdtxgurC8WyHHbvQ= sha1:0V29OTpR4Zn/xJO85Un9obV7ke8= Xref: csiph.com comp.lang.c++:121401 Muttley@DastardlyHQ.org writes: > On Thu, 02 Jan 2025 13:58:34 -0800 > Keith Thompson wibbled: >>Muttley@DastardlyHQ.org writes: >>> On Thu, 2 Jan 2025 17:54:18 +0100 >>> David Brown 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. No, I get your point. I just disagree. >>> 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. You used the word "expect". I think you meant that you *want* it to behave in certain ways. You know the existing rules, and you strongly dislike them. >> 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 you overstate the problems introduced by overloading << and >>. I accept that you dislike them, and I'm not going to change your opinion. I suggest that there's probably not much point in discussing it further. -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com void Void(void) { Void(); } /* The recursive call of the void */