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,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,f51e93dacd9c7fca X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-06-19 23:50:26 PST Path: archiver1.google.com!postnews1.google.com!not-for-mail From: 18k11tm001@sneakemail.com (Russ) Newsgroups: comp.lang.ada Subject: Re: status of Ada STL? Date: 19 Jun 2002 23:50:25 -0700 Organization: http://groups.google.com/ Message-ID: References: <4519e058.0206170753.599fd771@posting.google.com> NNTP-Posting-Host: 63.194.87.148 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1024555826 24150 127.0.0.1 (20 Jun 2002 06:50:26 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: 20 Jun 2002 06:50:26 GMT Xref: archiver1.google.com comp.lang.ada:26461 Date: 2002-06-20T06:50:26+00:00 List-Id: Dmitry A. Kazakov wrote in message news:... > On 18 Jun 2002 22:32:12 -0700, 18k11tm001@sneakemail.com (Russ) wrote: > > >Dmitry A.Kazakov wrote in message news:... > >> Russ wrote: > >> > >> > Immediately after the statement "x=3" executes, it becomes true in the > >> > mathematical sense, which is why it makes sense. > >> > >> Nope. Consider C++ having user-defined type conversions. It is very easy to > >> write a program in C++ that > >> > >> SomeClass x; > >> > >> x=3; > >> if (x==3) // false > > > >I should have been more specific. For any instance x of a built-in > >numerical type, the statement "x=3" becomes true in a mathematical > >sense immediately after it executes. (If I am wrong, please provide a > >counter-example.) > > 1. From ADT point of view there is no difference between numerical, > built-in or whatsoever types and other types. There are good reasons > why it should be so. > > 2. Try [C is a funny language!]: > > int x; > > x=1.5; > if (x == 1.5) // false > -------------------------------- > float x; > > x = 1.00000001; > if (x != 1.00000001) printf ("oops!\n"); All you've shown here is that assignment does not always work as expected in C. I agree that a non-integer shouldn't simply be converted an integer with no warning, but that's a completely separate issue from the semantics of assignment. Had those assignments worked as the programmer presumably intended them to, the tests would have evaluated to true. Let me postulate a rule of good programming practice, and you can let me know if you agree with it or not. If I define an assignment operation for a particular type or between any two types, and if I also define an equality test between them, then immediately after the assignment is executed for instances of those two types, the equality test should evaluate to true. For example: type1 A; type2 B; ... A = B; if ( A == B ) ... // true or you goofed somewhere, dude! Note that it will not always make sense to define the assignment operator and/or the equality test operator for every possible combination of types, and my rule applies only when they are both defined. Unless you disagree with this rule, you must agree that there is indeed a very close relationship between assignment and equality testing, and your earlier claim that they have "nothing to do" with each other is nonsense. And so is the notion that "=" should not be used for assignment. > >> In fact assignment (semantic of) has nothing to do with equality. You may > >> have incomparable objects which can be assigned. You may have comparable > >> objects that cannot be assigned. You may have objects which have several > >> different semantics for assignment (deep/shallow copy/reference) and > >> equality (distance/set equality etc). > > > >That's really all irrelevant to the main point here. If you have two > >different objects A and B of the SAME type, > > What is for two types to be SAME? It is not an easy question as one > might think. > > > then > > > >someclass A, B; > >A = B; > >if ( A == B ) ... // better be true! > > But then if you would insist that it should be so in strict > mathematical set-theoretic sense, I would derive from that, that also > > A'Address = B'Address -- better be true! In C++ you can define the "==" operator for any two types any way you wish. Your particular definition depends on the problem you are trying to solve, of course. But in most cases you probably would not be testing whether the two objects are actually one and the same object. > If A and B are SAME then there should be no way to distingush them. > From programming point of view it has in most cases no sense [however, > see LSP]. "==" is not equality it only models one of many possible. But I contend it should at least be consistent with your assignment operator for the type or types it applies to. > >If this doesn't evaluate to true, you have goofy code. Yes, I realize > >that asignment can be overloaded in C++ in all kinds of ways, but > >that's really a distraction. Your claim that "assignment has nothing > >to do with equality" is just plain wrong. Nothing to do with it? Give > >me a break! > > You can start to define what is equality of two fuzzy sets. What is > equality of two floating-point numbers. What is equality of two remote > servers. What is equality of two people. Go on. As I'm sure you well know, good programmers rarely test for exact equality of two floating point numbers. And if you can test for exact equality of two fuzzy sets, how "fuzzy" can they be? Perhaps I am missing your point here. Do you have one?