From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail From: Ben Bacarisse Newsgroups: comp.lang.ada Subject: Re: Top 10 Worst C# Features Date: Thu, 15 Oct 2015 14:59:51 +0100 Organization: A noiseless patient Spider Message-ID: <87si5c8c6g.fsf@bsb.me.uk> References: <5cb5c989-4d12-41d8-88df-ab45988ba8a1@googlegroups.com> <87mvvla5ma.fsf@bsb.me.uk> <8f252b53-4d99-4d4c-893c-66ec29ec38d6@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: mx02.eternal-september.org; posting-host="017616aa25f81ec581c44d76d61ba2f3"; logging-data="23503"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/p8gXvonxFcaAvcevl6qDS17z4JfGE2QI=" Cancel-Lock: sha1:72maOmm6BtgOn5frEm0lE073BXE= sha1:9X5WotlOyBygrIQVqZjKZAjzv/Q= X-BSB-Auth: 1.e58b4d1b137142583b8b.20151015145951BST.87si5c8c6g.fsf@bsb.me.uk Xref: news.eternal-september.org comp.lang.ada:27983 Date: 2015-10-15T14:59:51+01:00 List-Id: Maciej Sobczak writes: >> Do you mean that there are reasons to permit !(a == b) and a != b to >> have different values in some cases? > > Why not? We are already talking about the language where a+b is not > necessarily equal to b+a (hint: strings). ;-) I asked because I wanted to know the context for the remark that prompted my reply. That remark was In this case [when there is a hash or signature], our operator!= can be much faster than operator== and we are willing to benefit from the optimization opportunity here. >> I don't see why >> >> bool operator!=(const T &other) const noexcept >> { >> if (this.hash != other.hash) >> return true; >> return !this.long_slow_equality_test(other); >> } >> >> is any more or less efficient than >> >> bool operator==(const T &other) const noexcept >> { >> if (this.hash != other.hash) >> return false; >> return this.long_slow_equality_test(other); >> } >> >> but I may have missed the point you are trying to make. > > No, but you have missed the point that I tried to address. Your > example is OK with regard to performance, but for some reason you have > still used *distinct* implementations of these operators, instead of > calling one from another. No, I've just given an example of both because I disputed this remark: In this case [when there is a hash or signature], our operator!= can be much faster than operator== and we are willing to benefit from the optimization opportunity here. There is no reason at all to use both, but the easiest way to explain why I find the claim hard to accept is to show both. In practice, either one will do with the other implemented as the negation of the one chosen. You claimed that the case you gave (where the objects have a hash or signature that allows for rapid non-equality testing) was an example where separate implementations of != and == would be advantageous, but what you described is not enough for the conclusion to hold. That's why I asked about !(a != b) == (a == b). -- Ben.