Path: utzoo!censor!geac!torsqnt!hybrid!scifi!bywater!uunet!microsoft!jimad From: jimad@microsoft.UUCP (Jim ADCOCK) Newsgroups: comp.lang.c++ Subject: Re: Overloaded operator dot? Message-ID: <71655@microsoft.UUCP> Date: 2 Apr 91 21:53:37 GMT References: <11152@jarthur.Claremont.EDU> <624@taumet.com> <12193@pasteur.Berkeley.EDU> <1991Mar21.032937.16534@world.std.com> <71516@microsoft.UUCP> <275@heurikon.heurikon.com> Reply-To: jimad@microsoft.UUCP (Jim ADCOCK) Organization: Microsoft Corp., Redmond WA Lines: 125 In article <275@heurikon.heurikon.com> daves@ex.heurikon.com (Dave Scidmore) writes: |In following this discussion I have noticed that most of these examples |start with the statement "I want to design some set of objects to do X and |I want to do this by using langauge feature Y in this way". It do not believe |that there is any meaning in showing that given a contrived set of |circumstances the language can not meet the needs of your program. I agree. C++ could have been done entirely without any overloadable operators. However, I think that would have made it a less desirable language. I am only asking that a "wart" -- an unnecessary restrictive case -- be removed from the language. Let's just say "all operators are overloadable" and get it over with. |To do so |is to expect the language to be all things to all people. On the contrary, people who wish to not allow overloadable operator dot wish to force all people to their point of view that pointers are preferable to references. Such people expect the language to help them restrict what other people can do. I just ask that such a simple and needless restriction be removed. People can decide for themselves whether to use pointer or reference syntax. They don't need a small group of self-appointed experts to decide that for them. |What is important |is whether their is a solution set for your problem, without any contrived |conditions or usages of language features, which maps cleanly to your problem. I disagree. I believe what is important is that the language be clean and orthogonal. Due to its "C" history C++ includes a concept of pointers, whereas other OOPLs have shown that having only references is sufficient. But, due to history, C++ has both pointers and references. Given that the vast majority of operators can already be overloaded, all should be overloadable. Why place a needless non-orthogonal restriction on the language? Why not allow programmers to choose whether to use pointers or to references? Why not allow programmers to choose what operator overloadings are appropriate for their programming? Why allow 40 operators to be overloaded -- but not operator dot ??? |I believe that with some effort a clean approach that does not require |modification of the language is possible for every one of the examples given |so far. That solution starts with rethinking how you want to achieve the end |result and picking an approach that is a good fit with existing language |features. Agreed. The entire concept of pointers in needless in C++ and could be removed. This has already been shown in a half dozen other OOPLs. But such is water under the bridge. C++, due to history, has both pointers and references. I only ask that the choice of which to use be left to the C++ programmer. Why deny this choice? -- C/C++ have historically left the choice to the end programmer to be intelligent enough to decide for themselves how to best do their jobs -- they don't need some "experts" needlessly restricting their choices in a few obscure and non-orthogonal cases. |>But, when we place all the problems |>we've found into one category which we label "smart references" some |>people argue that we're just applying a name to a category we've made up. | |Since "f.thing" and "(&f)->thing are equivilent in a sense smart references |already exist. If you think of "f->thing" as being equivelent to "(*f).thing" |then it becomes clear why "->" is was originaly made overloadable and "." |was not. Since overloading of "*" is allowed how do you overload the implicit |"*" in "f->thing" (i.e. (*f).thing). The method chosen was to allow |overloading of "->". Since "." has not implicit dereference overloading was |not needed. By such an argument operator+ should not exist because its possible to accomplish the same thing through: Matrix A = B - (-C); |>And then when we show specific short examples of the problem then people |>argue that the examples we give are academic and give hack work-arounds. | |I for one do not think using "(&f)->thing" is a hack workaround. It is |quite clear to me what is intended. Tell me which of the following you consider "quite clear" : example A: ["smart references"] Matrix a[100, 200]; Vector v = a[20]; double d = v[40]; example B: ["the 'quite clear' work-around of explicitly converting to smart pointer"] Matrix a[100, 200]; // .... Vector v = (&a)->operator[](20); double d = (&v)->operator[](40); example C: ["smart pointers" used instead of "smart references"] Matrix a[100, 200]; // .... Vector v = (*a)[20]; double d = (*v)[40]; |One reason I have seen given (you must have missed it) is that it alters |the syntax of the language in ways that make it hard to predict the outcome. |Currently "expression.expression" is not allowed, your change would make |it allowable. If this creates side effects then its removal will be far from |easy. I believe you misunderstand me: My proposal is for unary operator dot, just as today there is unary operator->(). Neither allows an expression for the selector. My proposal only requires that which is already required because of opeartor->(). The only change to the language is to allow programmers to choose between writing smart reference classes or smart pointer classes. Expression.expression is not allowed, neither today is expression->expression allowed. The only change is adding the appropriate syntax to allow programmers to program smart reference classes if they so choose, just as today we allow programmers to program smart pointer classes, if they so choose.