From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 26082 invoked from network); 14 May 2020 18:42:26 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 14 May 2020 18:42:26 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id B5FD69C974; Fri, 15 May 2020 04:42:24 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id C57B99C962; Fri, 15 May 2020 04:42:02 +1000 (AEST) Received: by minnie.tuhs.org (Postfix, from userid 112) id DB3AE9C962; Fri, 15 May 2020 04:42:00 +1000 (AEST) Received: from mail.cs.dartmouth.edu (mail.cs.dartmouth.edu [129.170.212.100]) by minnie.tuhs.org (Postfix) with ESMTPS id 3C9AA9C95E for ; Fri, 15 May 2020 04:42:00 +1000 (AEST) Received: from tahoe.cs.Dartmouth.EDU (tahoe.cs.dartmouth.edu [129.170.212.20]) by mail.cs.dartmouth.edu (8.15.2/8.15.2) with ESMTPS id 04EIfwV63239206 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Thu, 14 May 2020 14:41:58 -0400 Received: from tahoe.cs.Dartmouth.EDU (localhost.localdomain [127.0.0.1]) by tahoe.cs.Dartmouth.EDU (8.15.2/8.14.3) with ESMTP id 04EIfw5I063532 for ; Thu, 14 May 2020 14:41:58 -0400 Received: (from doug@localhost) by tahoe.cs.Dartmouth.EDU (8.15.2/8.15.2/Submit) id 04EIfvEZ063529 for tuhs@tuhs.org; Thu, 14 May 2020 14:41:57 -0400 From: Doug McIlroy Message-Id: <202005141841.04EIfvEZ063529@tahoe.cs.Dartmouth.EDU> Date: Thu, 14 May 2020 14:41:57 -0400 To: tuhs@tuhs.org User-Agent: Heirloom mailx 12.5 7/5/10 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [TUHS] v7 K&R C X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" > o operator overloading > > I never could figure out why Stroustrup implemented that "feature"; let's > see, this operator usually means this, except when you use it in that > situation in which case it means something else. Now, try debugging that. Does your antipathy extend to C++ IO and its heavily overloaded << and >>? The essence of object-oriented programming is operator overloading. If you think integer.add(integer) and matrix.add(matrix) are good, perspicuous, consistent style, then you have to think that integer+integer and matrix+matrix are even better. To put it more forcefully: the OO style is revoltingly asymmetric. If you like it why don't you do everyday arithmetic that way? I strongly encouraged Bjarne to support operator overloading, used it to write beautiful code, and do not regret a bit of it. I will agree, though, that the coercion rules that come along with operator (and method) overloading are dauntingly complicated. However, for natural uses (e.g. mixed-mode arithmetic) the rules work intuitively and well. Mathematics has prospered on operator overloading, and that's why I wanted it. My only regret is that Bjarne chose to set the vocabulary of infix operators in stone. Because there's no way to inroduce new ones, users with poor taste are tempted to recycle the old ones for incongruous purposes. C++ offers more features than C and thus more ways to write obscure code. But when it happens, blame the writer, not the tool. Doug